Designing your Future Identity Fabric: Operationalizing the KuppingerCole IAM Reference Frameworks

Very warm welcome to our first day at EIC, to our pre-conference workshop, Designing your Future Identity Fabric, Operationalizing the KuppingerCole IAM Reference Frameworks. Nice to see you here in Berlin. So we are starting right away because we have a packed workshop planned. And before we take a closer look to the agenda, I would like to introduce our moderators for today. So in total, we have four moderators. Cami and Fabrice are sitting in the first row for now. They will introduce themselves later after the break.

With me on stage, Matthias Reinwarth, my colleague, and I am Phillip Messerschmidt of KuppingerCole. So we are our moderators today, leading you through the workshop. The idea for today's workshop is the identity fabric and understanding how the identity fabric works, how the reference architecture works with the identity fabric together, how you can operationalize all of that, and how you can apply that to the real world and understand the real world experience that we have prepared here.

And last but not least, the idea is to give you more options to operationalize both frameworks, either the identity fabric as well as the reference architecture. And this is how the agenda works as well. So we had the general introduction. This is what I've just done. And then we explain the frameworks, the two frameworks that we have prepared for today. We deep dive into the capabilities of the reference architecture. After three, we will have a short break of, I think, 30 minutes, right? Before the break, there will be some time to answer questions, if there are some.

And after the break, we start with four, the real world experience, where Cami and Fabrice will present their experience. And the points five to seven are the operationalization alternatives that we have for the identity fabric and the reference architecture. So we show you basically how you can apply the two frameworks to reality for different cases. Eight is wrap up and closing statement and a short question, a round of question. That's the idea for today's workshop. And then I would say we dive directly into the frameworks.

To kick that off, I would like to talk a little bit about the development of the identity fabric and the reference architecture, which is not easy, as long as you don't know the frameworks. We recognize that today. So the idea of the identity fabric and the reference architecture as frameworks is that you get a structured approach for your identities and the capabilities that come with the identity space. We have designed the identity fabric and the reference architecture as flexible frameworks, meaning that you can expand it. You can apply that to other areas.

You can even use it for different types of identities for the reference architecture, for example. So the idea is, in whatever organization you are in, whatever industry you look at, you can use the identity fabric and apply it to that industry, to that type of organization, even to that team, if you like. It is a very flexible framework. Both are very flexible frameworks. And that makes it very valuable when you go away from the framework, from the template that we provide, and individualize that for your own organization.

And here we have the idea of a level one, a high-level template that you can start with, and the level two templates for the different industries, or in the case of the reference architecture, the different types of identities. So for the identity fabric, we are focusing more on the business model, the sector, the industry, the area. And the examples, as you can see, are for cloud native, for banks, for mature industry organizations, for highly regulated areas, as you like. These are just examples, so you can get more and more examples.

The level two reference architectures, they focus at least from the examples more on the different identity types. So we have the reference architecture here for the consumers, the SIEM, the B2B, the PAM area, and an IGA reference architecture, if you like. What we will show today are just the high-level versions, the high-level templates, frameworks that you can start with. Then let's get to the fabric itself. So this is the Identity Fabric 2025 that we have released in January. By the way, all the slides are available online.

You can probably already download them, so you don't need to take a picture of every slide. They are freely available for you. This is the newest version that we have released in January. We have updated a lot, but the general structure remains more or less the same. The idea of the Identity Fabric, as said, is to provide you and your different identity types a structured approach to ensure that every kind of identity that you can find on the left side, the different identity types, can access a certain type of application or target system. So this is on the right side here.

Everything in between the right and the left sides, obviously the middle, ensures that a certain identity can access a certain target system. And the good thing about that, as you can see with the identity types and the target systems, we have tried to cover pretty much everything, but you are still flexible to apply that to that certain example that you are looking for. So you can see we have the human identities and the non-human identities. For the human identities, we have the B2E workforce, the B2E contractors, partners, and so on. For the non-human identities, we have also some.

So the machine identities, we have the workloads and some autonomous agents and bots. So depending on the different identity type, these capabilities, services, and tools that I will explain shortly will change, will adapt to the case that you are trying to display. So how does that work with the capabilities, services, and tools? The idea of the identity fabric, the middle part of the identity fabric, is to explain the very functional details, the capabilities that you require so that one identity can access a target system.

For the next step, after you have identified all the capabilities, you try to summarize them or to put them together into a service. So when you see here in the administration part, the identity repository, onboarding, proofing, user lifecycle management, you can all combine that into a service that you then call, for example, identity management service. And services are not yet tools. So for now, we have not talked a single second about a specific vendor, a specific tool. These are our capabilities, so functional features, and services that you can offer.

If you try to implement that, you get to the tools. And this is what you can see here on the right side. So the tools are there to implement the different capabilities as services that you offer. And there you can find the classic vendor categories like IGA, the PAM category, the SIAM category. This is the idea that you, at the end of the journey, talk about the tools, not at the beginning. So this is a functional framework, not a technical one. On top and the bottom of the middle, you can see the, let's say, integration layer. So we never find a green field in an organization.

Something is always there. Something is around. You need to connect with other services as well. This is what you do with the connectors. So you have connectors at the bottom that focus more on the legacy part of the organization. You have connectors above that focus more on the cloud content and the cloud applications, the digital services, software as a service, whatever else you have when it comes to connectors. This is the idea how you bring all of that together and connect it from an identity fabric perspective.

As said at the beginning, the most important part about the fabric is the flexibility. When you now focus on one identity type, these capabilities may change. So you have different capabilities for workforce identity than you have for machine identities, for example. So bear that, please, in mind because that will change the identity fabric depending on the identity type that you're looking at. And that will also change the tools, of course, and the services that you offer. So in one organization, you may end up with more than just one identity fabric. Okay?

So before we come to the reference architecture, I would like to highlight the timing aspect of capabilities, services, and the implementation and tools. What we have discussed by end of the last year and we have seen in the area of IAM being discussed also by other experts is the timing aspect of these capabilities. What we were all aware of is the admin time and the real-time aspect. So stuff that you do before the login, before having the access, and whatever happens while you access. So the real-time aspects. These concepts are very well known.

The discussion by end of last year, mid of last year, introduced also the post-event time as an own timing aspect. We all knew that before. We had examples for that. For example, monitoring or reporting. All of that happened post-event most of the time. But it was not an own category, so to say. We have focused more on the admin time and real-time in the industry. With real-time now also being more in the discussion, we figured out that just having the category of real-time is not enough anymore, but that we also need some differentiation within the category of real-time.

So that basically means we have split it up into a session initialization and a session management, which are two different parts of your access process. That makes, in total, four different timing aspects that we need to figure out for our capabilities, for our functional features when we implement them. So the admin time, I explained them briefly. The admin time is everything that you do in advance of your access. So that means if you are creating AD groups, if you are creating roles, if you create an identity, that does not happen at real-time.

This is something that happens in advance, that you prepare for the time when you access to be available. The real-time aspect, this is what happens when you try to log in. For example, authentication is a good example for a real-time feature, a real-time function that you have. Being asked for a password, of course, we are on a passwordless world, but as an example, for those that still have passwords, or being asked for a second factor, these are real-time aspects that trigger when you try to initialize the session. So this is the left part of real-time.

So what happens in the session management part is something that you sometimes don't recognize as the user, as the end user, because that is where your session is being tracked, where your tokens are being updated and checked if they are still valid. Your context information is checked, and if something changed and the system says that is weird, they might ask for another second authentication, or another factor, to make sure that you are still you. So this is something that happens while you are logged in, and you are verified at that time. Good.

Post-event, I've explained that already briefly. That is everything that happens after you have logged in. So the reporting, for example, that you check after somebody has logged in, was that valid, or what did he do in the logs, for example, this is happening after the access happened. And when you now take a closer look to the capabilities, you can apply all these four timings to potentially all of the capabilities. Maybe some not, but most of them have features in all of the time zones, I would say. And we need to differentiate that when we think about the implementation later on. Good.

The reference architecture. The reference architecture contains a lot of capabilities. The idea of the reference architecture is to drill down a little bit more into detail from the identity fabric. So how are they connected? The identity fabric had that middle part when I was talking about the capabilities that are gathered into services and implemented via different tools. These capabilities can be exchanged depending on the identity type. That's what I said earlier today. And this is how it could look like.

So the reference architecture gives you more details on the capabilities of the identity fabric. And this is the high-level reference architecture that we offer you as a template to start with. And it displays a lot of the capabilities that And it displays a lot of the capabilities that you might want to think about when you come up with an identity framework for your identity landscape. So how can you read it? How can it be understood? If you want, you can see that as a matrix. You have some rows, you have some lines, some columns.

And in the rows, you can find core, you can find privileged, extended integrations, API, and foundation. These rows show you how important or how close the capability is to IAM. So obviously, we expect the core capabilities to be part of every IAM landscape. In the columns, you can find the four A's. Administration, analytics, and risk. Authentication and authorization. These are the known functional categories that you have within IAM and help us to structure the reference architecture.

The idea is to go line by line, column by column, through the different capabilities, understand the functional capabilities, and think about what you need of them, how mature you are in the end, and what you need for implementation. And this is exactly what we will show in the next chapter. But before we get there, I want to explain for the reference architecture the different levels. So we have on the high-level version that we have here also a line that is called privileged, so that we cover also some capabilities of the privileged area.

We have the foundations that should be available in every organization to support IAM. And the integrations part that are not core IAM, so most of the IAM teams are not responsible for these integration, sometimes tools, sometimes capabilities, but we deliver or consume data from these areas. So that is the idea of the integrations. Good. That should give you a short overview over the reference architecture. And to close that chapter, again, I would like to highlight that the reference architecture can also be exchanged based on the identity types.

So this is the high-level one, the level one reference architecture. On level two, you could change that and create one for consumer, one for privileged access, one for B2B, depending on what kind of identity type you're looking at. Good. Diving deeper into the details, we get to chapter three, and I hand over to Matthias. Maybe that's a good time also for the team below there. If you have any questions, there will be a Q&A section at the end. So I've been told that they can throw up this QR code. So if you scan that and pick the right color for this room, then you can ask questions.

We do that that way because we hope there's a huge online audience as well. So you are augmented with the team that watches this event virtually. So we can get the questions from you and from them and then gather them and answer them afterwards. So if you have already questions regarding what Philipp just explained, then please just jot them down and we can look into them by the end of my presentation. I aim at 45, 50 minutes or so, which sounds a lot, I know, and I don't want to bore you.

But we want to have a deeper first look into that before going to questions, and I think that really helps. So I'll give you 20 more seconds to scan this, and then you can hopefully, never tried it, ask your questions that we can then pick up later in this session. Just look in the room. Does it work?

Great, thank you. So then let's go back to the presentation.

Okay, as Philipp explained what these frameworks are, they are a language that we can all use to formulate identity and access management in architectures, infrastructures, etc. That's the idea behind that. It's not that we are the real smart analysts that tell you how the world looks like. It's a framework that we can structure things within. So we can get from capabilities in the fabric towards a service, and think of that as a service that you would hand over to a service owner within your organization.

And then you need to find a tool that implements that service that the service owner maybe has to handle. That's the idea getting from capabilities to services to tools in the end. And now that we are at the reference architectural level, we are now down at the individual capabilities. So if we look at that picture again, and this is something that all, these are IAM experts in that room, I know that. These are things that you have heard already. So administration, analytics and risk, authentication and authorization are the terms that you are usually dealing with.

And if you look at that, usually the two rows or columns to the right, this is access management. The two to the left, they are closer to admin, to analytics, to IGA. And for the limited time that we have for this workshop, we decided to dive deeper into one subcategory of what you can combine out of these building blocks. We want to look into IGA. And that was our throw at what constitutes IGA, what can be considered as an IGA solution. I want to briefly walk through these individual blocks, really very briefly, just to tell you what they are in our opinion. You can disagree.

What are typical functionalities and what are examples of that. And if you look at the picture, so you see, we think that in IGA, typically there are identity repositories, information quality management and on and on and on. And I hope you can decide what is in the red box and what not, so that we can really dive deeper into those. And Philip left the stage because we didn't think of, you cannot click on a box in that slide with a clicker. So he's now back there and he tries to support me in doing the animation part, which is nifty.

So, yeah, if you click on identity repositories, I hope you, yeah, here we go. You see the structure that we're using.

And again, you don't have to take photos. This is published material. This is an advisory note that Philip and I have written late last year. This is available and it's more or less the same text that you can really then dig into later. What can you use it for? You can use it for analyzing how your infrastructure looks like. You can use it for defining what's missing, gap analysis. You can use it for identifying your maturity and you can identify what of your tools fall into that area. And maybe too many of those will fall into one single area.

So maybe there's a chance for a portfolio analysis. So if you look into identity repositories, one sentence definition, I don't read it all out loud. So otherwise that would be boring. So you can read it while I'm talking. So the idea is what are the boxes where identities are? Where are they authoritatively?

Maybe HR, not really an identity repository, but a data source. IGA with its data store.

And then, of course, account management systems, Entra, AD, Google Cloud Platform, whatever, where you have your identities. A detailed description is then the question, what do these identity repositories do for you and what are the key aspects? And you see those are from the old ones, the really old ones, LDAP, X500, up to cloud-based infrastructures that provide this as a service, Entra ID, or just proprietary databases that you use. So this would be one first building block of identity repositories and ideally, in the back of your mind, you map that to what you have. That's the idea.

You have a common language. That's what we're at. So if we go back, I can click.

Okay, then let's do it that way. Otherwise, I can jump back. Sometimes that might be a bit irritating, but at least we can see where we are. We are in admin. We are in core. And that is exactly also what is stated on the slide. And if you look at the sub-headline, there's core, administration, and admin. And this is the core line. This is the admin column. And that is admin time. That is what is in there. So you see how you are in that matrix.

And again, if you look at identity information quality management, this is something that is far less concise described. So if you look at how do you improve your data, how do you make sure it's all similar from a structure, that it's well-structured, that it's comprehensive, that it's even maybe quality assured, there are less concise tools, but the functionality is clear and you have everything. You have everything from ETL tools that do that to tools that, I'm sorry for that, Power Script or something like that, that does some fixing of the data in transit. You shouldn't.

There are tools for that, but they live longer than us. And of course, this is also built into IGA solutions. You can have that in the connector, this identity information quality management. So all of this is something that you can really achieve in different types of tools. That's the reason why we don't look at the tools. What is the reason why we're doing that? What is the capability? Cleaning up data, making sure that bad data is removed, good data, but duplicate data is consolidated, etc. How am I running in time? Am I too slow? Good.

Okay, that would be identity information quality. Again, still, you think of the matrix in the background, we're moving one line down. Identity lifecycle management, core for IGA. I could talk about that an hour alone, but the idea is clear. You have a type of identity, and this could be a person, that could be an employee, that could be an external, could be a partner, but could be anything else. I think this EIC is much about NHIs, different lifecycle, different beast. The question is, how do you deal with that? But they will, or they must have a lifecycle.

And that is what you, in IGA, create for typically human users, employees, externals, partners, etc. So, you have an upstream system where you earn, or where you inherit lifecycle events, and then you create a lifecycle within your IGA solution.

So, you understand the identity as a representation of the entity over time, when somebody retires, when somebody goes into sabbatical, when somebody changes position. These are all signals firing into IGA, into lifecycle management, and then you create the identity within your system that is your master entry, and then is reflected later in provisioning, coming to that in the account management systems, with the proper access, with the proper provisioning. That would be key aspects.

So, it's really the user context, the user lifecycle management, this is really small over here, and the user data lifecycle that is reflected. What are the tools?

Yeah, IGA tools. Lifecycle management solutions, there are some that add on to not so strong IGA solutions, but typically it's IGA. That's what there is.

So, the question is, who owns lifecycle as a service? And that's the question, the reason why we distinguish between capability and service. This is the 2025 version of the reference architecture, and we did a lot of changes, but evolution, not revolution. If you think over to the two columns to the right, you want, we all want to use context data.

So, context data is important, so time of day, device status, et cetera, et cetera. All of this needs to be there. The question is, how did it get there? How do we have a source that is trusted? And that is what's behind context data source management, to understand, okay, to have that at runtime for decision-making processes, you need to administer that and have trust in that source, and make sure that that is all available for you.

And that's what's behind context data source management, to understand the additional non-person-related, or not necessary, person-related data sources that you want to bring into your dynamic access management decision-making processes. And that's what's behind that. You do that, usually within IGA solutions, but also within the access management solution. The examples are examples. This is not comprehensive, that is not complete. This is just to tell you what we actually want to mention here.

And this is something that has not been there before, in the previous version, but I think it's necessary that you understand what are your context data sources that you can trust, and they themselves will have a lifecycle, of course. Back to standard IGA, that has been there before, provisioning.

So, really to make sure that you take your IGA entry, the person entry that you have, and make sure that that is reflected in downstream systems through provisioning processes. Provisioning means creating an account, giving or removing access from accounts, deleting, deactivating, archiving an account. That is typically what we see in provisioning, and that can be multi-layered.

You can, if you have to, directly provision into a proprietary, homegrown application where you need to fire an account into a database, and hopefully remove it afterwards. You can use it to provision into AD, into EntroID, in larger systems, which then again act as an authentication, authorization source for applications downstream.

So, provisioning is really making sure that there is a concise chain between the IGA, lifecycle management before, provisioning afterwards, so that you make sure that you have the information where you need it. The less sources you need to provision to, the better, but you have to, sometimes.

Again, we're talking about a common language. I know you know what provisioning is. The question is, how do you slice and dice it, and that is what the reference architecture is about.

So, really to say, okay, do you know what your provisioning engine is? Do you know really what your provisioning engines are? How many you have? Is there somebody provisioning out of Entra into something else because you need to, because there was no other solution, etc., etc.? This is really making sure that you get the full picture, and that is what we're doing in advisory, but you don't need us for that. You can take that, and that's the reason for that. Take this blueprint and just apply it. That's the idea, just to tell you the story behind that.

Provisioning, actually, a bit before, but also afterwards, is entitlement management. Typically, if you think back ten years, this is creating roles, role hierarchy, entitlement management model, and that's it. Entitlement management has grown, thankfully. It has grown 15 years ago, but nobody did it.

So, in entitlement management, you have now more than roles and groups. You still have them. They won't go away that fast, although, in my presentation in two days, I'm hinting at that. But the question is, how do you really make sure that entitlements reflect your business logic?

So, entitlements are codified business logic that means access. That is what entitlements are. That could be roles, that could be groups, and that could be policies. That could be policies for assigning access, or assigning roles, placement roles, or real-time policy-based access management, decision-making processes in a PBAC system. And all of this is an admin part.

Again, we are in core administration admin still. So, we still are in that picture, in the right place.

So, creating these entitlements, and if I look at that room, I think this is something that is part of your daily business, creating proper roles, role concepts, really entitlement models that cover a lot of platforms, that is of importance. Where do you do it? IGA tools. Where do you do it? You do it in dedicated access management solutions. They are there, so you need to... Sometimes they're closer to the authentication, authorization part.

And, of course, everything that's around PBAC, you can do it there. Ideally, you have some orchestration for policies that you only have to do it once, not many times.

Again, if you have questions, that would be the point to pick out the thing where you scan the QR code. Workflow management.

Oh, I go back to the overview. Because sometimes, these pictures are not black and white. That is a gray area. If you look at workflow, entitlement management, self-service, where's the differentiation? Where's the difference? And that's what I'm going to talk about today.

So, I'm going to talk about workflow management, where's the difference? And that's the reason why I want to go back. There is one, and that is important. That's why we distinguish between the three, although they are closely related. You could have entitlement management that relies on workflows and is a self-service.

So, there's no black and white. There's a gray area, but nevertheless, capability-wise, they are different. And that's the important point.

So, go forward. Entitlement management. Workflow management. Here we go. Sorry for flicking up and down, but I think that it's really important. Workflow is everything that is implemented as logic within the IGA solution, within the IGA architecture, in your framework that you've created, in your IGA reference architecture, because that is something that does things for you. You codify it, low code, no code, ideally.

Usually, much code and lots to configure, but, hey, that's what you're doing. That's the workflows that represent business logic for you. And that could be, again, implemented in IGA tools, and that implements many different areas.

I said, yes, it could be self-service, it could be entitlement management, but it could also be, as I said here, automated user provisioning. That is something that is a policy that you implement in code that assigns access to an identity, and maybe it's then provisioned outside of the system into a target system.

Again, that's a workflow, and that is of importance. Lifecycle management, of course, is a workflow. You have lifecycle management understanding what that means. That's more a logical building block, but you need to implement it somewhere, in a piece of code somewhere, in an engine. And deprovisioning, access revocation, often forgotten, but also part of that. Where does that happen?

IGA tools, short hint to later, ITSM tools. Are they IGA? I don't know. Let's wait and see. And dedicated workflow engines.

Again, there are some workflow engines that add functionality to older, but still heavily used IGA solutions that add just a bit of functionality. And here's the self-service.

Again, as I said, they are closely related. The question is, what do I want to achieve with self-service? What is the building block self-service? So usually, we want to give our users access to functionality, because we don't want to do it ourselves. So let's make them do it.

So really, on the one hand, be more efficient, but also move the work to those who know better. That's the main idea. It's not getting rid of work. It's also. But it's really moving the work to those who know better, to the organization, to the business, to the end user who says, I need that access. Somebody confirms, and that's it. So moving this to the right people in the organization, that is why you do self-services. And that could be access request and approval. Is there an organization here in the room that does not have access request and approval within their IGA solution? There?

You all do. Okay, that's good. So you all will have self-service to be assessed in your own identity reference architecture assessment if you use that. So what are your self-services that you're using? Profile updates. I've changed my mobile number, and I share my private mobile number with my employee for reasons, and I can do it myself. That's the question. Or request a parking place for your car or something like that. That is related to the locations that you want to go to, so it's IGA-related. Loved and hated recertification and attestation.

That's a self-service usually, so that's part actually of access governance, but it's a self-service. So where does it belong? No black and white. It's gray. It's a workflow, and it's access governance. So two examples, again, where do you implement that in IGA tools?

Of course, they come usually with very good, today AI-supported, of course, self-service engines, which really help you. Password management solutions, of course, if you still have it. Password reset. Six weeks of vacation. Password forgotten. Perfect situation. But then you need to get back to your password. That's where password management solutions come into play.

And again, workflow-enabled ITSM solutions. Could that be implemented? It's a capability, not a tool. So I don't flicker back, but we're changing column. We're moving over to audit, and we want to understand what happens here. So access governance. There were some major changes also in the identity and reference architecture for the 2025 edition and evolution, because really things have evolved there heavily. So if you look again at access governance, we have an interesting thing at the sub-headline. It's core.

It's analytics and risk, and it's admin slash real slash post, because access governance covers the full range of these timings that Philipp explained. So you want to use access governance information at admin time to know, um, maybe these two access rights are toxic. You don't want to combine them. That is access governance during, for example, entitlement management.

Of course, you want to have access governance at real time. Why is Matthias working on Sundays? Shouldn't. That is real time. And post what happened here. Look at the audit logs and try to identify what was happening. And if you think of the picture with the four columns that Philip shown regarding the timing, there should also be an arrow that goes back to the admin part or to the post real time part, because you want to learn from what is happening in your system over the full life cycle.

If you understand what happened in retrospective, you can maybe prevent something going wrong afterwards by doing proper administration. And what is included?

Of course, everything that you can either do at admin time, the whole access reviews, SOD management could be live, could be at admin time. If access rights are assigned at runtime, maybe they become toxic at runtime and need to be identified then. Auditing and reporting, of course, is runtime. At least the auditing part, the reporting part could be later, could be post. And ideally, even some kind of risk mitigation at runtime. You identify that something goes wrong. You just don't say bad, but no, you just really do something and react to that at runtime.

So access governance really is a huge back and we will see that later. There is another huge back coming up. But access governance is really one important part that can be capability-wise giving you a common language for describing a reference architecture or your architecture is quite broad. We need to understand that.

And again, access governance, Philip could talk days about access governance. Coming from a regulated industry, you know what access governance means. So maybe just one slide with a bit of text might be too little, but this is the reason why we have the second level where you can then drill into an IGA reference architecture as a whole. We are just trying to identify blocks in the picture. Remember the red frames. So re-management solutions, GRC tools, they of course also play into access governance as a tooling perspective. And risk-based access review tools, these are just examples.

There are much more and we will get to more of that as well. Part of, but also well integrated and sometimes isolated, that's the reason why it's a separate capability is application risk management. So really understanding what is an application and what is the criticality and the risk of an application that is onboarded into your system. And not only knowing that, that's fine, that's the foundation, but really using it and reacting upon that within your access governance, in your audit and risk processes or analytics and risk processes, that's the importance of application risk management.

And these are dedicated capabilities. This is often done by a separate team. We talked about service owners, et cetera. So how do you map that into your organization, into a service infrastructure? We are all talking more services, which is good because we have been dedicated service owner and application risk management is often somewhere else, not in the IGA tool, the team or the IAM team, but these are peers that you deal with. And that's also the reason why that needs to be understood separately.

So it's really understanding the risk insights, comprehensive risks insight, it says that's key aspects. So really to say, okay, what can in the worst case go wrong with that application and with which entitlement or with which policy that you assign and understanding that and that feeding back into the application within the IGA system, the access governance processes, et cetera, going to SOD management, of course, coming to understanding how can I reduce the assigned access for a single person, so this over-provisioned, over-entitlement, et cetera.

And in the end, you do that, not only you do that because you want to protect your organization, but you do it also for regulatory compliance, for achieving compliance to the frameworks that you need to fulfill. So that's also something, it's doing something good and talking about it, that's application risk management in the end as well.

Not only, that would be sad. Where do you do that? Dedicated application risk management and monitoring solutions, SOD management solutions, analytics tools, et cetera, et cetera.

Again, capability versus tool, that's important where we look at. Again, back of your mind, think of where are you doing your application risk management right now, just as an exercise in the back of your mind. Access analytics, this can be something different if you look at employees and if you look, for example, at customers, then access analytics is something completely different. At least there's an overlap, there's a VAM, of course, but access analytics for customers is different. But we're talking about employees because we have the IGA capabilities right now.

So it's really understanding how access is used. Are there entitlements that are not used at all for Matthias? Does he use this and that solution? Why does he have it then? Why do I pay that license? So that could be one question that's behind access analytics before we talk about Matthias going rogue, doing things wrong, using application entitlements in the wrong, in an unexpected manner. But all of this is access analytics. It's really modern term data-driven insights into what people are doing with their entitlements and really understanding what is the risk of what I'm doing.

And the question is then, can I change something here? And that, again, as you can see, it's again admin, real and post. Access analytics can really say, okay, let's look at admin time. What does this guy have? Look at real time. What does he do with this?

And post, what the hell has he done with these entitlements? So really that you can look at it from different angles. So where do you do it? It's often built into your IGA tool. There are specific tools.

There are, we come to that in a second. There are ITDR tools that allow that. So identity threat detection and response. That was one of the buzzwords of last year and I think it's still there. ITDR is still there. So this is what we're looking at right now. Anything else to access analytics? I'm looking at Philip. Did I miss anything? Then move on. ITDR. We did a bold move and we had lots of more capabilities in the original version of the reference architecture that were called, for example, behavioral monitoring or UEBA, et cetera, et cetera.

And we did the move to move that all into ITDR because they are all combined into that. So we have one capability that's rather huge, but the reason is that it's difficult to slice and dice that ITDR capability right now. So we have access analytics as the basis and ITDR for everything that's modern AI-based, fancy, audit-oriented regarding creating reports, et cetera. And especially the R part, the response part. That is where ITDR really shines. So it's really not only understanding what is happening right now, but applying proper responses.

And that is the foundation for what we call identity security. So really understanding we have the identity, we have access assigned, we have access governance, we have analytics, and now something goes wrong. How do I react at runtime? And that is what ITDR is about.

So it's, for example, anomaly detection. First, defining a baseline of what you would expect Matthias to do. Then understanding what is acceptable delta and where is something really going wrong. Wrong time, unmanaged device, wrong source network, let's do something. And that is something that you can do at admin, real, and post.

Admin, you need to administer that. So define what is normal, define what should happen.

Real-time, actually executed, and post, providing the insight into what happened, creating reports, and feeding back into the admin part. You see there's a lot of text here, and there's more. So ITDR is a huge capability, but I think that adds the level of agility to access governance at all the different timing periods that we have. I need to flicker back, sorry for that. So just to give you a picture of where we are right now, we need to think about that once again. So we are at ITDR, so we went through column two through core at identity, threat detection, and response.

We skip authentication because we don't do that in IGA, usually. And we move over to authorization, and that is the part where at least there is a touchpoint with authorization. So I still, sorry I have to do that that way. Static access control, this goes hand in hand to the other things that we have to do. Role-based access control, this goes hand in hand to entitlement management the old way. Role-based access control. So that is really where we consume entitlements that have been created at admin time, but it happens at real-time. That's the idea here.

And we think we cannot look at that from an isolated perspective just to say, okay, we are creating roles and throw them over the fence and that's it. Let's deal with it. The question is how do we deal with that at runtime? So it's really defining roles to define the assignment of users to those roles, to these groups, whatever they are, and understand the role hierarchies at runtime as they are administered at admin time, and that we really can make sure that the access is really reflected at runtime like it is defined in admin time.

That is a combination of access governance of the admin and of static access control at runtime, and it's a bit of a unicorn because if we look at real-time, then we usually don't deal with real-time in IGA other than the access governance part, but that is of importance that we map anything that we do in admin really to the real-life perspective at session time. Anything to add?

Lots off, but let's keep going. There are just two slides left.

Right, so I could make it short. That's the same for policies. So we look at everything that we created in entitlement management at admin in core. We do the same for attribute-based access control, policy-based access control, and not extended access stands as a placeholder for all the bugs that they come up with. So there are lots around right now. TBAC will be an important thing that we look at here right now at this EIC. So there's more to come.

The question is how do we deal with what we administered in IGA regarding modern dynamic authorization schemes in terms of mapping real-time to admin time? That's what we're looking at here right now. So that's the two capabilities that we consider of being IGA as a whole. Good. And finally, we do a bold jump. You've seen that before. We go to column one, admin. We go to integrations, and we go to ITSM, because this is a topic that we see in many organizations and that we cannot usually untangle ITSM and IGA in many organizations. This is something that is closely related.

I've mentioned that before when it comes to self-services, when it comes to workflows, but in the end, ITSM is something that is often discussed within organizations, and this is where organizations live, where they represent their processes towards their users. The question is do I really want to go somewhere where I have IGA administration, workflows, self-services in the one solution, and ITSM being a separate island or well integrated or fully integrated, and how do I do that? So ITSM is an integration that we see in many organizations.

So the elephant in the room, everybody knows the products that I'm talking about right now. So these are spread in many organizations, and they are the one face to the employee, and the question is how do we integrate that? Who has integrated ITSM with IGA?

A third, a bit less than a third. Okay, that would be a discussion in itself. How did you do it? So where is the actual business logic behind an access request and approval? Where's the catalog where you can choose from? Who creates it? Who filters it? So these are the questions that we're looking at here right now, and now that this is my final slide, before we go to the questions that you've raised, I hope there are a lot. A lot. That's good.

Again, I can go back to that because this is the important picture. Sorry, I do it again. And we stay there. But this is the important part. We filtered out with the red boxes an IGA reference architecture on a high level. That was what we wanted to do. We wanted to give you definitions for what we consider key capabilities that map to each other into services and then tools when you want to select one in the identity fabric, and that you have a proper picture. And if you say, no, IGA, I'm fine. Let's do it with something else. Take it and make other red boxes. So that would be the thing.

Again, it's a tool. It's nothing, no secret sauce. It's published. It's available. You get the slides. Find a common language. And ideally, it makes all of you in this room being able to talk together about their solution and meaning the same. That would be good. Questions? Good. Then we were much faster than expected. So we have more than enough time to answer questions. Before we get to the questions here, are there any questions in the room where I need the microphone?

Otherwise, I have enough questions here, or you can state them via the QR code online. We will pick them up.

In fact, it's not on the IGA itself, but I'm wondering when you have these blocks on multiple capabilities, let's look at maybe... I mean, IT services management, or access analytics, or access governance, where these boxes fall in two capabilities, which one to choose? Is there some recommendation coming from your side on where to fit in? Because it's one of the conflicting areas when you have multiple, the IAM platform has multiple blocks, each one saying, let's put it here. Right. Do you want to answer? Should I?

First of all, it will be part of the second after the coffee break, but you're absolutely right. And the question is, how close are those building blocks functionally to each other? If you look at identity repositories, and you think of CIM, and you think of IGA, depending on whom you talk to and who the vendor is, they have multiple Depending on whom you talk to and who the vendor is, they have not much in common. They would be, CIM would be provided as a service from the cloud, and you don't have any insight. And I don't know, IGA would be 3.1 identity, whatever. And it's different.

The question is, can you unify that? Not on a platform basis. The question is, how do you unify that on an identity relationship management data model basis, which is down here, we haven't talked about that. The question is, who is an owner of a customer, for example. Then you stay with two pots of data, but you get to a common identity data model, and that is where you aim at. So it's totally fair to have more than one solution for the same capability, although it's not unifying tools. If it is possible, great. If you can get rid of one and spare the money, fine.

But it really needs to be, and that's an analyst answer, I know, it needs to be decided on a case-by-case basis, what makes sense for your organization. It's not only technology, it's also ownership. Who runs the system? Who's responsible for it? Do they want to be overruled when it comes to, hey, let's use, I don't know, my IGA for customer identities. Let's do it that way. So it needs to be decided on a case-by-case basis, and in the end, it's portfolio management. If you drill down deeper with more than one detailed second-level reference architecture, we get to that.

How do you structure that as a whole? And that's mainly what our exercise was about, to create these second-level reference architectures, because that was a question that was not that easy to answer.

It was, but it was always bespoke. I hope that answers the question a bit. Good. Anything to add? Any other questions from the audience here? Then we move to the online questions. So first online question is, is there training and certification on this? That's a good idea. We haven't thought of that yet.

So yeah, this is your training here. You all attended, you are now all certified. After the break, of course.

No, we don't have any training on this. We have a lot of material on our website. We have an advisory note that explains each and every capability in that model and the model itself. So what we present here is already available on the website. The date was 14th of January when that was posted. So there you can find the content. We have these slides online for download.

And yeah, this is basically your training. Just leverage it. That's the idea. We just use it. Good. Second question. Thank you for sharing level one overview. Do you also have methodologies to align multiple different level two frameworks instances needed in a company? I think you explained that already briefly. The idea is pretty much, when we go a couple slides back, or the question, I explained the question. So here you can add the different frameworks, the different reference architectures into. So the capabilities that we see in here are basically a reference architecture.

And you can add them based on the identity that you are looking at, the identity type. So that would basically make a big identity fabric with different capabilities for different identity types. As already explained, it can happen that you have the same capabilities, like for authentication, for different identity types in that fabric. It's up on you to combine that into an architecture in the end and implement that. But in theory, you can have a big identity fabric, multiple reference architectures within, sometimes even several times the same capability.

There you combine these capabilities into services for different identity types, and you implement that in different tools. I mean, just think about your own organization. I know at least one organization, or one person of an organization, where the organization has two IGA systems. So in this case, you potentially have two access requests. You have multiple tools that are responsible of access governance. So that would make more than just one capability of access governance, if you like to phrase it that way.

So yes, in general, there is a methodology. You can put it all into one identity fabric, and then you can combine the different levels.

However, that identity fabric can get quite huge. So it's recommended not to put too many reference architectures into the same fabric visually. Right. It's divide and conquer, but it's having the full picture in mind. And as maybe a brief teaser, there will be the opening keynote today by Martin Kupinger, and he will talk about the identity fabric of 2040, which is a bit visionary, but which exactly deals with this topic. How do you get from a hardwired architecture paradigm to a more mesh-oriented and service-oriented, even within the building blocks itself?

And that could be also a way to think of these things. For the online attendees, that won't help unless you talk very loud. How do you see glue technologies like model context protocol fitting in to tie in these identity fabric components together and expose them for consumption by more agentic-driven processes in the future? Do you see a revision of this maybe for 2026, 2027, where that's all factored in? So I could now steal Martin's keynote and explain that, or you wait until the opening keynote. The short answer is yes, I do. More in the opening keynote. I hope you will all be there.

If you go with the reference architecture, just to mention that, if we think of that, of the mechanisms that you mentioned, if you think of them as a high-level API that we can use, the API layer is here, and we will see it in much more detail later when, spoiler, I explain a CIAM second-level reference architecture, what kinds of APIs could be there. This is just more or less a placeholder to exactly say what you said. Nobody wants to use self-service anymore if I can do things by API, if I can automate it, if I can make it at scale.

That was the challenge for us, to explain core capabilities and say, okay, how do you scale it up? So we skipped that part a bit, but that's a great question, so I could mention it because we have the time. Thank you.

Yes, and there is, of course, a reason why we have this identity API layer over there, over all four pillars. So we expect more to be in there in the future, obviously, but as I said, Martin's keynote, you will remember my answer. If you're watching the recording, it will be available as well. Okay. Good. Next question. Will the Identity Fabric recommend tools which integrate well together to provide the capabilities chosen? That's you.

So, going back to the Identity Fabric, because that was the question, as you can see in the middle, we have that block capabilities are combined into services and implemented via tools. These tools are tool categories, so you can basically Google them, if you like. IGA is the, I think, the one everyone is familiar with, but also access management, so when we think about IDPs, PAM tools, SIAM tools, you can get all of that on the market. There are leadership compasses on our website, so basically, this is what you do.

When you have the Identity Fabric created, you have the capabilities that you want to implement, and you want to improve on certain capabilities, then one step could be to implement a new tool if the tool is the challenge. So, what I basically do with you is analyse the different capabilities, and this is something that we will do in the second half, so also there, a short preview. When the tool is a problem, or a challenge for you, then you can basically do a tool choice afterwards and look deeper into the different tool categories.

What we have shown on the reference architecture is that these red capabilities are mainly the ones that you look at when you think about IGA, but obviously, there are more capabilities, and that means there are also more tools in there, so we could think about an IDP that mainly is doing authentication. We can think about the privileged stuff that is covered by a PAM tool. There are different identity types, and different identity types mean more capabilities for different identity types, different tools.

The important part is how do I combine all of that in a single landscape, in the best case. So, short answer to that question.

Yes, you could do that, but that was not the original idea. The identity fabric reference architecture offers you a lot of options to go different ways. The tool selection is one of these options.

Right, and to answer the question, do we recommend something that fits well together? No, we work together with you to identify what fits well together for you, and I think that's the way to move forward. There are great products around. The question is, how do you create your own fabric? That's the question, and that's why we want to lay the foundation with this. And the products are then the end goal. Complex one? Complex one. How can we adopt a more pragmatic approach to the identity framework for non-Fortune 500 companies struggling with example licensing costs? Let me read that again.

Should I start? No, no, no, no, I don't think so. Non-Fortune 500 means medium-sized, mid-sized organization, means two people doing identity management, if at all, not having the budget to license one of the big 10 right upper corner at Leadership Compass IGA solutions. What we're talking about today is understanding what you need, and I think this exercise should be executed by everybody to understand what are my requirements, because they won't go away. If you are subject to MIS2, you need to fulfill MIS2, and you need to do it in a way that is adequate for your organization.

If you are financial services, Dora, if you are somewhere, you need to understand your requirements, and you need to understand your own organization. This exercise won't go away, and that's what this is about. Mapping that to a proper solution that is viable in terms of cost, effort, and outcome is a different game. We are currently working also to look into that market segment of these next level IGA solutions that are affordable and are delivering.

This is something that we're doing right now, but from that perspective, I know that this won't answer the question fully, but first of all, make sure you get your requirements, and maybe also to say, okay, that would be nice to have, but I can skip that, but my compliance requirements won't go away, or I will go away, and then the question is, what is the right solution? What can I get as a service? What can I get pre-packaged? Where can I earn or inherit processes that others have defined for me, et cetera, et cetera?

There are solutions for that, but please start with the requirements, because everything else will lead to, oh, let's buy that product that will fulfill all your needs, and it won't. That's maybe the problem then. That would be my first throw at things.

Yeah, maybe to add to that, it's important to understand that this is a huge framework. It gives you a structure to basically assess more or less hopefully everything in that space. That doesn't mean that you need to do all of that, and you don't need to do all of that on the automated way.

So, of course, we are talking about the fully automated high-end stuff. Everything is tooled, combined, integrated with each other.

That is, I mean, realistically seen. That is nowhere the case. If you are trying to do access governance, it's also fair to do that with the manual process or media disruption in between. That's not nice, of course, not high-end benchmarking, level five maturity in the end, but this is how it is, right? We still have a lot of legacy applications there. They are usually sometimes not connected. We have a ticketing system that you use to provide access. This is how the reality is.

So, in the end, when you use that framework, of course, you can do that as a smaller company, but then in this case, you're probably not aiming for the big solution that is fully automated. You decide, based on your requirements, based on your current status quo, on the next useful step for you. And if the next step is to connect an AD because you still have an AD, or you connect something that is legacy for you, I don't know, a core banking system that needs a custom connector, then you do that. You don't need the high-end, I don't know, SCIM connector out of the box to make that work, right?

So, for smaller companies, you just need to focus on what you really need and think about the next step that you want to take. So, again, I will talk about that in chapter seven of today's workshop, so we will get back to that later. Hope that answers the question.

If not, get back to us. So, what are the benefits of distinguishing entitlement management from ABEC, PBEC, and RBEC? Is it mainly about the granularity level of access management?

So, that is an interesting question. We have talked about that here.

So, entitlement management, the most important thing about that is why we distinguish it from static access controls and ABEC, PBEC, XBEC is the pillars that they are in. Entitlement management is in the administration is in the administration pillar, while the two others are in the authorization pillar. The idea behind that is that entitlements are something that is there based on administration, it's there in advance.

You create that like an AD group, you create a role, you create everything in advance, and this is your authorization model, where you have all of the access items, when you want to call it that way, combined. So, whether it is a role, a policy, I don't know, a token, whatever you can come up with, in a single view. The idea of static access control and ABEC, PBEC, XBEC being in the authorization pillar is that this mostly happens then at real time when you execute the information of your authorization model that is part of entitlement management.

So, in other words, we differentiate a little bit between the administration pillar and the authorization pillar, so the preparation and the execution here. In the reality, it's not that clear, so there is a little bit gray between these capabilities. They work very closely with each other. Hope that helps. In reality, it's also the case that you cannot really distinguish that clearly between static and dynamic access controls in the sense that you most often have both in your organization.

So, it's not that you do just static or just dynamic. There will be a little bit of both, and this is the case here as well. This gap or these three capabilities distinguished is more of a theoretical thing. In reality, they are more closely together. I've picked a question. Maybe we won't make all of them. This is great, this feedback, and we should come back to that, but does the distinction between ABEC and RBEC still make sense? Isn't ultimately everything HR attributes based?

So, the question is, if you are using policies to assign access to as in a role, isn't that the same as doing ABEC? Yeah, that's a very good question, and this is a question that I think the experts in the IAM landscape are discussing as well on a daily basis. We have seen that topic coming up last year, dynamic authorization as one of the trend topics, as we are able to use ABEC and PBEC much more in the area.

So, the idea of signals and context information is something that we can use much more now than we did five years ago, where we had a role, and based on our job title, we received that role, and we call that business role model, but meanwhile, we are able to use different signals, like, I don't know, whatever you can come up with, any kind of context information, so where you are, when you try to access, from what device, from what network, and we could come up with, I think, hundreds more of context information here, and this is where we still need to differentiate between RBEC and ABEC, because RBEC is mainly about the roles.

It does not really tell you how you get the access, right? It tells you what you get, so the object, and ABEC and PBEC is mainly saying how you get that.

It's not really telling you what you get, it's how you get that, and this is why, potentially, and this is what at least I expect, we need to combine both approaches in the future to say what kind of object, whether it is a role or entitlement, or however you want to call it, you get, and on the other hand, we have ABEC and PBEC that is telling you when or how I get that, when I'm accessing from the right device, when I'm accessing in the right time, and so on, so the differentiation is, I think, much more important than ever before, but that's already quite a deep dive into the topic, to be honest.

Right, and I would mention, at least, the removal of standing access rights is a good thing, so if you assign an access right based on HR attributes at admin time, and I keep it, and it's a bigger threat surface other than I just log in, and I have an empty shell as an account, and I get assigned access at runtime, I think that's a different threat surface, but that's a different topic and a different talk on Thursday. So, next question, can the identity fabric be used for both as-is analysis and for strategic decision-taking?

Short answer, yes, obviously, otherwise we wouldn't have presented it. So, the idea of the identity fabric, and then I go back to the slide again, here, is that you have the strategic picture, so you can think about what kind of identity types you have, what kind of target systems, what do I need, and this is how you get a comprehensive view of what you have and what you need on a very high strategic level.

The reference architecture helps us to drill that down into the functional features, functional capabilities, so this actually is already one level deeper when it comes to the details, and in the second half, I will explain in chapter, I think, six, how you get from a status quo analysis to a roadmap. So, this is how you can apply the identity fabric and reference architecture to make strategic decisions, and in chapter seven, we will explain how you use it for operational challenges.

So, depending on the challenge you have, there are different methods to use the identity fabric and the reference architecture as a starting point and to drill deeper into your individual challenge. That is the idea.

Okay, simple questions, simple answers. Should the four A's include audit, or is it implied in analytics and risk? Simple answer again, yes, audit is in analytics and risks. We just wanted to keep the term short and know that it is not comprehensive in the wording, but we chose analytics and risk, and audit is included there.

So, when we remember back to 2023 or 2022, we had the last update, and before that update, it was audit, and we thought about opening up the terminology, and now it is basically analytics and risk, but it basically covers audit, so the original fourth A in that sense. So, from a terminology, we have changed it, but the content is still the same, but a little bit broader than just audit.

Okay, I think we are done. We have seven more minutes. Seven more minutes. Let us try to find, okay, one API layer, but solutions are distributed building blocks. Do you recommend to build an orchestrated identity API layer, and how? Shall I give it a throw? As I said before, and with regards to Patrick, the identity API layer here is a stop. It is a representative. We expect that many of these building blocks expose APIs, and they need to be well managed, so there will be also an evolution in the use of APIs, I assume, and that is the evolution that many organisations are just going through.

First of all, having APIs at all. Second, getting a grip on the security of APIs, and managing them properly. I think that is an evolution that many organisations are just going through, and that is what I would also expect for identity API. The more concise and the more thorough the overall approach towards managing your identity APIs is, that means the stronger your identity fabric is created by those who are responsible for that, and then they feed every API into a common API layer or management platform, the better, but that would be really a high level of maturity already there.

As of now, we think just APIs to be the glue that ties this together, what we have on that picture, and that you have the access to the functionalities without using visual interfaces, but more using automation. That is the idea behind that. The answer is yes and yes. We expect that there will be different APIs, and yes, there should be a common API management layer if possible, but it depends on how your fabric looks like. I think that is, sorry for that answer, but that is the reality that we are all dealing with. Good. Next question? Final one. Final one. But there are still ones left.

We have a lot of questions, and you're still posting new questions, so we probably never run out of questions here. That is really a suggestion just to shock him. We could do a podcast episode around the questions after that, so that would be really to pick up on that, because doing that now that everybody is waiting for a coffee might be the better way to do it in a separate session, but then we would let you know. Good. Then let's do one last marketing thing. You have seen me picking up this.

This is the identity fabric, and we have prepared it over here so you can pick up your very own small glasses cleaner as an identity fabric, so don't forget to pick it up. It's the small version, a little bit reduced, but will help you in your daily business. And with that, we are going into the break for today. Break for today. But don't go too far away, because the next thing will be the real-life perspective by Kami and by Fabrice that will have a different angle, and we will look at things in reality, so don't go too far away. Fetch your coffee. We'll see you in 30 minutes. Thank you.

See you after the break.