From Capabilities to Clarity: Aligning IAM with the Identity Fabric at Scale

So, yeah, first question first, who attended the EIC morning run this morning? Hands up, yeah, saw a few, yeah. And Oliver just came with this nice metaphor in the preparation or just some minutes before and said, IAM programs are a bit like a marathon, yeah, and we today did just five kilometers, yeah, and the five kilometers we did with the project together... Settling the pace, exactly. This is what we are doing, what we did the last year together with Erste Group, and I was from the outside there from KuppingerCole, and maybe Oliver, you?

I'm the product owner for Identity Access Management in Erste Digital, which is the central IT provider for the whole Erste Group, but let's look into it. Sure, so we are a group of banks operating in Central and Eastern Europe, around 20 million customers, around 50,000 employees, plus, minus.

We are now in a situation that, for historical reasons, our landscape got into, well, let's read it in a way like diversity, I would read it in that way, which means that we asked KuppingerCole to support us to deploy a strategy, to develop a strategy, coming to a point where we can then nail it down, go to interproduction life, and we want to give some insights to you how we raised this challenge from the very first beginning. So we will talk today a bit about the structure.

So I'm not trying to sell you a product today or something, product functionality, but how we get the product into the organization, what to consider beyond this. So now we talk about how did we start. So you see four steps here.

Of course, the first thing, before we start to say let's do everything we have, we listen first. We listen to all the stakeholders that are then the organization that have to do with IAM and identify the core one. We utilize our frameworks that we have at KuppingerCole then to set this all together and to understand where is the group actually, what are the capabilities that are deployed there. We tailor then the results that we had to, or the specific concepts to the needs, and, yeah, then we validated them again and see did we achieve what we wanted to achieve.

And, yeah, at the end it was the case. So at the bottom I will not read them out. There were seven deliverables that we had. So starting from the assessment really, root cause analysis to go a bit deeper, and then strategy, rollout plan, and so on.

Yeah, but now let's have a look first how did we approach it. So the reference architecture, and I can just, yeah, refer you to the talk by my colleagues Christopher, Philip, and Rainer from Monday to the workshop. There you have how we approached it. But just to see how we did it here, we used a reference architecture and understand where are we today, the status quo, then talked about where do we want to go, what regulations need there in terms of IAM, and also what does the customer want at the end, yeah, where they want to go.

And then we were talking about the gap, what lays between these states, to understand what are the necessary steps to get this into play. However, we were surprised about your enormous capabilities of the reference architecture. So this means if you present this to your board members, which then finally decides whether you go for an approach like, oh, well, let's just do choice and that's it, it was definitely the wrong approach. So from that perspective, we slice it a little bit more into smaller pieces, which are understandable on a higher level.

So it makes more sense that the technician explains basically, oh, well, this is an IGA, we monitor our identities, there must be added value for the business. Regardless whether you have gaps from an audit or you want to shape your identity and access management landscape, you nail it down in three different areas on an organizational, functional, and technical level, basically. So now we look at the results, what we saw on the organizational level. So the problem was not to less activity.

It was more the case that we had a lot of stakeholders in different levels and they were approaching individual solutions. They were then implementing somehow IAM, but in different flavors, in different ways, and so on. So the alignment was missing at the end and every island was operating on its own. You wanted to make a comment about the solution, how to understand it.

Yes, as the digital operates, 2,500 solutions. A solution means a line of business application. It's either one application or a set of applications, one from authentication, authorization perspective, you have different challenges. As mentioned before, we are a group of banks. This means coming from a point of governance, you have to align with different stakeholders. You have to fulfill regulatory requirements in different entities. It doesn't look like in a way that you see the law in Austria is comparable to the law in Czech Republic.

This means you have to consider each and every solution in the context of the existing entity and the regulative behavior there. Well, I mentioned it already. So multi-tenancy, and this was at the very first beginning, a very crucial part that we discussed a really long time. It is the lesson part, actually. Multi-tenancy for us means that you really switch as an employee having a service provided to an entity into the environment of the entity. This is a regulative requirement we have to fulfill from IT perspective.

So this means an employee working in a banking institute needs to fully switch with his capabilities into the target environment. Not all our business applications support this capability, which means that if you look into Office 365, for example, there are not such capabilities if you aim for a single-tenant environment. So you need to apply different methodologies like filtering or something like that in order to fulfill these requirements, at least on a very low maturity level.

What turns out is that basically we have to run two different identity and access management systems, even from a historical perspective. So this is the tricky part once it comes to Erste Digital and Erste Group, that we have to consider multi-tenancy in a way like banking operations from IT perspective, but also if it comes to cloud solutions. As we mentioned, in reality we did a mapping of your reference architecture to our daily life business, create the gap, and the journey there. There are root causes. I won't say we fail or we have problems. Definitely not. It's diversity.

Let's put it that way. I guess it's the best approach. Identity and access management is, or was in our world, technically driven. So even on a token level, we had discussions with our developers how to design the token, how to work with multi-tenancy approaches.

So yes, it was technically. This creates a gap once you need to increase the level of governance on a higher level. So if your auditor asks you whether your roles are designed properly, you will definitely not talk about an operational stuff in identity and access management. You have to prove that, oh, well, in this given point in time, an employee had the right to approve transactions larger than 100k. Another problem we had, and this is due to the nature of a group of banks, is responsibility, accountability, and support. It is tricky. There are institutes which are owned by holding.

They are legally independent institutes. So it's a mix of different organizational behavior. We need to somehow tackle common childhood.

Finally, it's yes, driven by IT, by speeding up things, time to market, must be slow, fast. Sorry, fast. We saw that we need a strategy. This is why we reached out to Kupinger Coal one and a half years ago. The other part we were talking about was the redundancy in core capabilities. Redundancy as it is or managed redundancy is not a problem, but unwanted redundancy that leads to different results, although you want to achieve the same, is a problem. So we had to identify this as a problem and flag this. The next thing was missing access governance framework in the organization.

Not missing access governance. As I said, missing activity was never the problem. But alignment through the whole group, that was the issue. So setting a frame in which each entity can operate in terms of their legal requirements, their individual requirements. And last but not least, a sound foundation is needed when you want to do access governance. So you need the proper information about users and their entitlements. They need to have a sound description at the end. So once Kupinger Coal reached us with their results, my first question was, Patrick, who?

Please, elaborate on this topic a little bit more. Sorry, I was really flashed by the enormous amount of information you provided to us. So Patrick, please, who? Assign responsibilities. Find the right people to do the right things. Doing a central IAM owner team which maintains all roles and information and users and is like babysitting every user, that is not the solution. Distribute in the organization to the people that are needed. And what?

So get away from the local solutions that no one can manage, the individual implementations of requirements, but understand what are the overall requirements, where are the differences in the organization, and then design a blueprint which can be adapted by the organizations but still can be governed from a central point of view. But at the very end, both of these questions can be answered in a way like it's an organizational change. Now let's come to the fun stuff. How? Technical.

Yeah, of course, you need a solution. Although it's not all about the tools, at the end you need a tool, right? So the right tooling, standard solution which implements these standards and can be used by the organizations, but gives them still the opportunity to adapt where it is needed, but still with a strict governance. Sounds great. So now let's have a look at the organizational part. The roles that would be needed. And of course, many things beyond are needed. We tried to nail it down for this presentation.

So this is what you see here in the core three roles that we proposed that should be fined in the organization with the proper knowledge and the proper responsibility to fulfill their duties. How did you do this now?

Well, actually, it's about accountability, responsibility, and supporting. Let's start with the two easier parts.

Yeah, it's not that easy to find one accountable, but it was clear from the very first beginning we need to nail it down on a very high level. So we define a group IAM owner, which is located in a group. They can care about all the governance stuff. They can care about collecting requirements from different entities, bring it down to a target operating model, which is then implemented by – it's also that – I would say it's easy to define an IAM platform owner. So regardless which tool you consume, it's now combined in a single IAM product team. The more tricky part was the local IAM owner.

So we searched for pushing back the responsibility of designing roles, of approval processes, of doing things in identity and access management with little entity. Those guys need and know how their business processes are working. So the idea is not that IT pushes towards their tool stack and approval process. It's more the other way around. We ask the customer in that way, a legal entity, please define a locally responsible guy. You can definitely outsource the role design stuff to a central division, to a central unit.

However, it's the responsibility of the legal entity to taking care about things like, oh, well, this is an SOD matrix. I have 100 employees. I cannot fulfill this segregation of duties. And what should I do to implement it?

Now, let's move further at the functional view, kind of. So we had to propose some central components, some parts of the blueprints that are then reflected in the solutions. We started with a global ID. That sounds quite easy, but on a strategic level or on a group level, to find the unique identifier and to map everything that is happening in the organization to one ID, I have to tell you, this is the first thing. You have nine SAP instances, imagine.

We had to define a process framework from which we actually define what is centrally defined, where do we have still the opportunity to locally adapt and kind of configure in the local needs, and also to find a governance process if they are violating, for example, this process framework or need adjustments, how to handle this. As I already said, the access governance and SOD framework, which is put together from the group level and gives the different entities guidance on how you do this, but still aligned with the group level. So everything works together like charm.

And the template tenant, talking about authorization. So giving the guidance also in the authorization aspect. So that central solutions, we have a role model, which is actually supporting the organization, and beyond role model, of course, that they can use in the local organization and then adapt to the needs. And you will say something about this?

Well, actually, it sounds really, really crazy when I talk. Like, it's that easy to find the global identifier, to establish an IAGE framework, which is now being, well, we try to implement it since six months right now. We do it in waves. So there is a different level of maturity we want to reach out in the next couple of years.

Basically, as I said before, the materialization of identity and access management is then on a per-tenant environment. This is crucial for us. We need to support each legal entity, depending on their requirements, whether it's a full managed tenant, which means that the role design, role management, approval process is done centrally. It's a standard tenant where a delegated administration can adapt things.

However, for our biggest customer, like Austria or Czech Republic, we have a custom tenant where they are fully responsible for what they're doing there. Now, please find a tool supporting this stuff because a tool will not change your province landscape.

So now, I warn you upfront, this is now one of the heavier slides. It just should give you an impression how it translates. I will not go through everything, but it should be. I have dreams about this slide, really. That was a long discussion. It's a nightmare. It's really a nightmare. Not to really give you the full understanding.

Now, of course, when we discuss with each other, you will find things where you say, ah, we would need this and that, but it should act, or for us, it was the methodology to find a common understanding before we talk about tools, but to understand the logical components, what we have and what they should do, and now bring it together from just the requirements list, how we imagine, how we propose that it should work to get a better discussion with vendors, but also with the organization, how it would change. And then, you see the coloring. That's a lot of colors, I understand.

Yeah, but I love colors. But it also reflects the organizational aspects.

There, you see the group, the platform owner, which is like colored, and this follows the structure. So, they have their logical components in which they are working, and this also defines what they have to do in the next thing, the operating model.

So, now let's jump. How do you get this into the organization? Yeah. We went away from fixed dates. It isn't working.

So, we are an HR company, so we are milestone-based in sprints, and we try to start very simple. Policy and process framework. We need to find or build the foundation and the conceptual foundation before we rush to the implementation. We have the access governance and SOD framework, so much told now, that needs to be ready before you start to actually implement, to have understood what you want to achieve. SOD framework. It's actually to be implemented in the identity and access management.

Access management, however, we don't know whether you need to segregate certain functionalities across a business process. So, this means we need to involve additional stakeholders, but we need to be ready to support it once it's defined. In the build phase, we talked then about the global ID, the implementation, the pilot implementation of the global ID as the first step, and then the IGA pilot to find the first entity to work with and to roll out this solution. Role concept and rollout. To be very honest, it's the most trickiest part.

If you change your IGA, normally you can't reuse the way roles design. I'm honest. We don't have a multi-tier role design, which is nice and pretty in your reference architecture.

So, we need to redesign each and every role, saying that 2,500 solution more than 500,000 entitlements, it's a lifetime job. No, it isn't. It is an iterative approach. Once you onboard an entity, once you onboard the solution, you design the roles in a new way. The organizational setup, as I see the time, we need to speed up a bit. Organizational setup, find the right roles, find the right people to implement this, to get this all running and to get it deployed. IGA architecture.

So, let's find a vendor. We know that you will not find the vendor fulfilling all your architectural stuff. It's a process. We are close to signing the contract, hopefully in June. Let's see what happens. And the last one, privileged access management. You have not seen it before, but we want a sounder foundation that interacts with each and everything, but this needs to also uplift it.

So, what do we have to... The final slide. The final slide, yeah. We are done. Six things you should remember when you get out here. Strategy first. IAM is not now only infrastructure. Think about where you want to go, write it down, get your stakeholders onboarded and communicate it to them to then get the proper funding and attestation. Foundation before features, the proper information needs to be there to really get it working and the architecture needs to fit your organization. Don't go the standard approach if it's not working for your organization.

Just enough, the tool will not fix your problem. That's for sure. You need a clear RAS symmetric. Who is doing what and why. Capabilities before tools. Start with classical requirements engineering.

Thank you, Patrick. And just on time. Thank you. It's just in time.