The Right Foundation for Your Identity Fabric

Welcome everyone to our KuppingerCole Analysts webinar, The Right Foundation for Your Identity Fabric. Speaker today, that's me, Martin Kuppinger. I'm Principal Analyst at KuppingerCole Analysts. So what we will do today is, or what I will do today is giving you really a bit of a deeper dive into the concept of identity fabrics, how to move forward with identity fabrics, what is behind this concept.

We have, I think, written the first time about identity fabric some five, six years, probably at least, quite a while ago. And since then, the idea of the identity fabric has seen widespread adoption by many, many parties in the market. And so I think it's a good time right now to go a bit deeper into this. And also for some of you, there might be some update in, there might be some new ideas in what I'm talking about. So this is what I will do today with, over the course of the next hour. Some housekeeping I have, excuse me, we are controlling audio.

We have two polls, one more at the beginning, one more towards the end. If time allows, we will share the poll results during the Q&A. We have a Q&A session. You will find the option to ask questions at the right hand side of your application or at the bottom, I believe, of the app, depending on how you joined. The more questions we have, the better it is. So feel free to ask your questions. If you have sort of a massive run over of questions and can't respond to every question, then I'll probably will write a blog post afterwards to respond to open questions.

And last but not least, we are recording the webinar. We'll make the recording and the slide deck available relatively soon after the webinar. So with that, the agenda, very simple. I start with some deep dive into the identity fabrics. Then we do a Q&A. And as I've said, in the deep dive, I will look at, so how to make this work? What does it mean? How can you move forward to your, so to speak, own identity fabric? All that stuff. But before we start, I want to raise the first poll, which is about technology impact. And this is just a small list of technologies.

We are running these polls in different webinars to gather a lot of input. Unfortunately, most of the tools we use don't allow too many responses. And I think it's also not adequate to have whatever eight or 10 or 15 options in a webinar. So this time we look at passwordless authentication, decentralized identity, consumer identity management, and identity fabrics as what has the biggest impact.

And yes, we can argue that identity fabric is more concept and a set of technologies than it is a single technology. Would be fair enough to argue that way.

Anyway, the poll will remain open for a while. In the meantime, I want to start not with the identity fabric. I'd like to start with the IAM reference architecture. And we probably will release an update around the European identity conference, our identity conference, which runs early June, which anyways, don't miss it. So you should really be in Berlin from June 4th to June 7th, because it's really the identity event, at least in Europe. And we'll give you all the great opportunity to talk to me and many of my colleagues.

So also a couple of years ago, we created this reference architecture looking at all the different building blocks. And I don't want to go too much into detail in the reference architecture. But what we did here is we really said, okay, what is part of identity management? This is what we call extended IAM, sometimes considered being part of IAM, sometimes not. And what are the areas where IAM is closely related to? And as time is flying, for instance, we probably would add XDR to SIEM and SOAR. There's ITDR right now, which is probably here more on the user entity and behavior analytics.

So sometimes terminology is changing. Sometimes there are new technologies occurring. Sometimes technologies are just not that relevant anymore. And so we update this every, I would say every second year approximately. But the interesting point is there are really many technologies. And this is really more the building blocks. Some of this usually is put together in a single technology. So access management usually has some web access management and some identity federation capabilities and adaptive authentication.

While IGA is identity governance and administration that includes identity lifecycle management and the access governance piece. And certain of the other technologies like identity provisioning. So there are different layers we need to look at. But what I want to start with is there's a lot of stuff around in identity management. And that is why I believe that the idea of identity fabrics is so essential because we must think about how can we get a grip on this complexity and how can we gather sort of a unified perspective.

And this is basically the idea of the identity fabric as a paradigm, a foundational paradigm that provides us with an integrated perspective across all these different areas. And that at the end of the day helps us understand what we need. So when we started with this concept of identity fabrics, so the beginning basically was really stepping a bit back and saying, okay, what is the job of identity management or identity and access management? And the job is to provide everyone, everything, every type of identity, a seamless but secure and well-governed, well-managed access to every service.

This can be a user to a web application or a SaaS service. This can be a service account to a resource infrastructure as a service. This can be everything around workload identities, around human identities, around non-human identities.

So syncs, accessing other syncs and service. Everything is always about someone or something needs access to whichever type of service or application. And this is basically the idea, what do we need in between? What is it what we need to make this work? And one of the points behind that when we started with this entire thing was that when we started this, it was also that we were in this evolution of, yes, we had workforce identity management. Then consumer identity management came. Then we saw B2B identity management emerging, et cetera. A lot of IAMs and a lot of overlap between us.

So sometimes there are very specific functions. Sometimes they are pretty common and established functions. Things like adaptive authentication, the ability to authenticate, to adapt, to authenticate in an adaptive manner is one of the key capabilities we need virtually everywhere. So some of those things are very common. And the question is, do we always need a separate technology for that? What can we do together? What can we do separately? And so we thought about capabilities and services.

So capabilities that are needed and how can we group them, which services provide these capabilities and which technical tools are finally needed. And this helps. And this is also learning that from quite a number of engagements with customers from advisories. This helps really customers to streamline their investments into identity management. And at the end, it is really about all identities. There's also this idea of an identity API layer. I go much deeper into that a little later. There is the need also to support legacy. So how can you move from your legacy IAM forward?

Something which also is of high importance when you look at the bottom of this picture. How can you do that? It's in the picture. It's in the concept. It must support everything, SaaS and legacy. It must be delivered as either. So this is from our perspective, a prerequisite that you can run it as a service, that you at least have the option to run this as a service model. And it must support your entire hybrid IT, everything. So legacy for IAM, how can you move forward gradually and hybrid IT support? It also provides the sort of verified identities and access for zero trust.

So it's a real essential thing when you want to have zero trust, because zero trust starts with Martin, takes the device, authenticates, and then accesses the network, goes to services, authorized. It's all identity and access. There's a lot of identity and access in zero trust, and we need a sort of a modern means to do that. I look at the details of this in a minute. We already have the first questions here, and always feel free to enter the questions once they come to your mind. The more questions we have, the better.

I will watch the incoming questions continuously, and I will pick some of the questions directly, some I will leave for the Q&A. But the one question I think is a very interesting one, because it fits very well to this introductory part here I'm talking about. And by the way, you also can vote for questions. So you can say which is the most important or the most interesting question. If you enter your vote, then it moves up, and then I surely will focus on the questions with the most votes. But the one I'd like to pick is here. The term fabric has two meanings in the English language.

The one is mesh, and the other is factory or production. So which one do we mean by identity fabric? And the answer is both. The answer is both, because the idea is that we combine services, that we sort of build a mesh of identity services that, on the other side, that deliver what we need. So it produces the identity services, but it also connects components, different components, into sort of a network, a mesh of identity services. In that sense, the fabric has at least two meanings, but the two meanings here, both are relevant for what we are talking about for this identity fabric idea.

And that is also a reason why, for instance, when I wrote our recent leadership compass on identity fabrics, where we compared vendors that have sort of relatively comprehensive offerings that at least cover a larger part of the different types of capabilities, usually at least IGA and access management, we also looked at vendors that are really coming more from an orchestration end, that are coming from an area or from an idea of how can we connect different bits and pieces into something combined. And this is also extremely important for building an identity fabric.

So when we enlarge the picture a bit, the core picture, then there are a couple of things that are, from my perspective, of higher relevance. So as I've said, on the left-hand side, we have all types of identities and there's nothing left out. So there might not be every name you are using currently or others are using on that list, but everything is in. This is at least, so it's more an explanatory list of things. The same for the services. There's at the bottom, there are legacy IAM, legacy applications. I'll touch this in a minute with the next slide.

There's on the other hand, on the top, there are things that I also will go into more into detail on this later on. But what is very important to look at is that there's an area which is, maybe I quickly move to the laser pointer, which is really here more as connectors, et cetera, where we go to sometimes digital services to SaaS, and also have the connectors to legacy applications, all that stuff we have here. This is more the traditional way of doing identity management. Traditionally in identity management, we manage systems. We create a user account in Active Directory.

We create an account or a user in SAP, whatever. This is, so to speak, inside out from the identity management out to the applications. But there's another direction here. This is the identity API layer. And what I feel is extremely important is to understand that identity fabric must support both the traditional inside out and the outside in approach. Outside in means that an application can request a service, can request a service like create an account or register its user or run the identity verification or authorize this transaction or this request or whatever is needed.

All that can be done via APIs. So there are two ways to look at which are both equally important. As I've said, we then have these lists of capabilities which are not complete and which change with every customer-specific implementation. Depending on what you do, what you need, this will be always slightly different. You may say, I don't need this in my work or I need some other things. You may not have all types of identities. You may have an emphasis on things or other stuff from IoT depending on what you're doing.

So it's the framework, it's the umbrella, it's the paradigm which then is adjusted to what you need. You have the capabilities, you have the services like an identity management service, managed service to manage entitlements, maybe a risk service, whatever. Whatever you need, you can define it.

Also, this may look a bit different. Sometimes more from a historical perspective that you say, this is the way we look at it or we have defined it already in our strategy. Sometimes because you say, okay, I just want to keep this for my world a bit different. You may also have services that are focused on different types of use cases a bit more. Up to you. And then it's all underpinned by tools. That might be one tool, that might be multiple tools. Usually it's more than one and relatively few core tools plus specific additions for different types of services.

So it's rarely something which is really in the narrow sense monolithic. So when we look at this, then the question is, and I talked about one more, it's an interesting question. I think there are arguments for both saying I combine services or I go more for the orchestration piece. The interesting point is we see more and more orchestration solutions which make it simpler to integrate things. But it's clearly not super, super simple if you have a lot of tools. We can derive this from the why sweets, why lesser vendors. So lesser vendors means you have lesser vendors to deal with.

Also from an education perspective of your team, that's a bit simpler to do. So there are a couple of reasons to say maybe not too many vendors. Integration potentially is simpler. But as I've said, we are seeing really good progress on the orchestration piece. You potentially end up with more consistent UI, UX, not always. So I've seen everything in this market. The consistent APIs, I talked about the identity API layering. This needs to be in some way consistent.

Anyway, to remain flexible, it's a good idea to say I expose my APIs but also combined capabilities like gadgets, widgets, whatever, your own way, so to speak. So you wrap the vendor specific proprietary APIs with your own layer. Because then everything you build on top remains much more flexible. Operations potentially is easier when you have lesser tools. On the other hand, if you go for specialized solutions, you can go for the best of great solutions. You also can add them always.

You can say, okay, I use this as the core technology, but I use this for whatever specific types of fraud detection and reduction, whatever is needed in your environment. So there's a good fit of that. Because at the end of the day here, we talk about the holistic perspective and how to bring these things together. You need fulfilling the gaps. You will have legacy as well. Because honestly, if you say I have identity management, I've done this for 10 or 15 years or even more, then some parts will be more modern, some less.

Some will be still pretty good and fulfilling requirements are just less. Some you may feel you still can maintain them. For others, you might even be out of support, out of the current release far away because you're not able to patch an update anymore. So depending on that, you will need to fix some things earlier than others.

Also, you may need some new capabilities first. And this is why we thought about legacy support. So it's just something you can connect to and use as part of it until you replace it. Because you decide about how to move forward and what you can do, what you can achieve from a management capacity, from a budget perspective, from all the other factors. And sometimes it's even that, as you say, I may have some systems that are still connected to my legacy I am, and I'm retiring these systems.

I just last week spoke with someone who said we still need to retire a lot of Lotus domino databases or Lotus nodes databases. In that case, when you do that, you may say, okay, I don't add nodes support to the list of capabilities for my new solution. But I will keep at least my old I am, whichever part it is, as long as I have finally retired Lotus nodes. That might make sense. And it's very important there's no right or wrong in that. It depends on what you need. And this is what needs to be discussed.

But at the end, it always starts with the capabilities, which you prioritize to the functional services mapped to your target operating model, the Tom. And then you decide about the tools. It's not the other way around. And there's also this question here. I see on the list of questions, as I've said, if you have any questions, enter these questions, and I'll pick them either now or later. I also have already some in the book, so to speak, in the backlog list. Can I converge by existing I am infrastructure into an identity fabric? I think depends on how you interpret converge.

If converges, you say, I just put a badge on it and say, this is identity fabric, then it's probably not the way I would recommend. If it's saying I can use some of the parts, at least for a while, and migrate them at my own pace, then it's a yes, this is the plan. Because Big Bang approaches in complex environments such as identity management rarely work. So you need to approach on a phased modernization, on stepwise modernization. So from that perspective, it makes sense.

And there might be also areas where you say, you're modern, it's IDaaS, it supports APIs, it has all the things you need, and then it just becomes a part of what's your identity fabric in the future. And surely after a couple of years, you may revisit this and say, okay, is this still the right technology? What has changed? But in that sense, it depends a bit on what you're talking about. But there's a place for everything, either at the bottom, like legacy IM, or within the tools that provide certain services and the capabilities behind that you already have.

You can look at identity fabrics also from another perspective, which I find quite interesting. And this is the control planes. So in that sense, there are a couple of control planes. And this is also something which has been discussed quite intensively over the past few years, I dare to say, where the discussions were about what is the control plane for what, or what is it? It was not only control, but integration plane. And when I was asked about it a while ago, I thought about what could be the control planes you have in your identity fabric. And I came up with at least four of these planes.

One is around identity, one is around access, one is around policy, and one is around security integration. And here, we see the identity control plane. The identity control plane is really very much about managing the identities, and having all the elements that you need to manage identities. By the way, and I said this in a couple of talks in the past years, your active directory, definitely, it's about managing identities, should be part of your identity fabric, and it should be in the ownership of IAM.

For EntroID, or Azure Active Directory, there's no doubt that it must be part of IAM, and must be under the control of the IAM organization, because it's really a core part of, in that case, not only of the identity, but specifically also of the access control plane. It's an IAM tool.

And a lot, not everything, but I would even dare to say most inactive directory is part of your identity control plane. So it should be in the domain of IAM. I know that not every organization is there, specifically when it comes to on-prem AD, but think about it. So we have an identity control plane. We have an access control plane, which helps us managing the access, for instance, by authentication, by all the access management, but also by the privileged access management piece. So how do we manage privileged access in this environment?

We have a, oh, it's boring, policy control plane. In that sense, it looks boring because it's just everything, but I think that is something where we really need to think about when we move forward with identity management. We already use policies in quite a number of places. We have authentication policies. So depending on the context factors, what is the level of assurance, which, whatever, when is a step-up authentication needed? When do you revoke an authentication request, et cetera?

For the ones who are more mature and do more on policy-based access control, we have quite a number of areas where we use policy. This is really policies. If Martin is in that location, that domain, et cetera, he has access to the system. A salesperson only can access the accounts that are assigned to him or her, whatever else. Very much about policies. But we also have the rules we use for birthright provisioning, which actually are policies, which also fit into that.

So we should sort of think more in policies, really change our understanding and move forward to an approach where we handle the management, the governance of policies, at least consistently across everything. The enforcement of policy usually is then more at a two-level. The integration happens then to some of the component, but from a conceptual perspective, we should start with a more holistic perspective on policies.

And yes, there's a security control plane, which is then about additional services, about integrations to other services, where we can integrate with different types of security solutions, like our SIEM, SOAR, XDR, whatever else we have in place. So identity fabrics can be seen from that perspective. Another angle before we can go more into some technical details is the measuring of maturity for identity fabrics. And I don't want to read this entire slide out, it would be probably a bit too much. But I think it's worth to also think about what really is required for an identity fabric.

And when we take, for instance, architecture, and even when we start calling something an identity fabric, it means we should have at least a high-level blueprint across all the areas of IAM, where we then move forward to a standardized approach for identifying the capabilities and their prioritization. Have a stable concept for our identity fabric with a roadmap, refine it regularly, and have a really a process in the organization finally to continuously update it. For the supported identities, it means we at least have a view across B2E, B2B, B2C identities, at least the humans.

Ideally, we go beyond that. So we have something where we, for instance, also are able to handle non-human identities, etc. We have an API layer from the very beginning. So that might be not as consistent as it could be, but we need to understand that this is about an API layer. So when you reach through these maturity levels, it makes very clear to talk about something or to name something an identity fabric already raises the bar at quite some height. So it means you need to have a certain level of maturity in IAM. It is not that you say, okay, I call what I have an identity fabric.

It usually is not yet there. You need to do really a bit more around it to call something an identity fabric. So no consistent view, no consistent API strategy, at least it's not yet an identity fabric. So when we look then a bit further into the next detail. So how do we deliver this? And I think there are two aspects, and this is a bit of a different picture of the identity fabric here, but it basically is the same from left to right. But the point I'd like to emphasize here is really more an architectural aspect.

So you may say, and earlier I said, so my expectation is IDaaS, at least the ability to be run as IDaaS. And there might be various aspects where you say, okay, I'm a bit reluctant still regarding that. So there are aspects to keep in mind when we talk about an identity fabric. Some may say, okay, in my world, some parts must remain on premise, for instance, or just run in a very specific type of cloud, a very sovereign, et cetera.

Anyway, when we take this picture, there's an element in which is really about architecture. And I think there are two levels. The one is where it runs and how it's constructed. And for me, this is probably the more relevant aspect to say what we need are, so the solutions within the fabric, from my perspective, should be follow the concept of microservices architectures, running containers, or maybe if it's a full public cloud or so, fully containerless, they should be. And that makes them capable of running in different places and to be moved around.

Ideally, we are able to also define which of these microservices are used. That can be a configuration thing. But what I expect from the solutions we have in there is a modern architecture that supports us in a flexible deployment. And otherwise, if you just say, lift and shift the monolithic old IAM tool somewhere to run it somewhere in the cloud, it's not really what I mean. I really mean the architecture must be modern, flexible, adaptable, scalable, all these things you get when you have a really modern software architecture.

But also, by the way, the thinking of these architectures also really helps when we are looking at customization. So I think it would have been an interesting poll question about whom of you already got in trouble with the customizations that have been made in some of the IAM tools over years? Because I've seen so many projects where organizations really struggled with even sometimes updating. They were years behind. They were just not able to install the newest release.

Or if they installed it, it was a project of several months in time and several years in manpower to make an update work because there were so many customizations that need to be changed. Basically, when we talk about customization, I always mean as encoding. And that is something which must not happen within the IGA tool. Sometimes in the older tools, it's relatively difficult to do it differently. It also requires a very thorough thinking about API security, about scalability, performance issues, etc. So it's surely not super, super easy, but it's doable.

And basically, the idea is to really look at this identity API layer. So we have an architecture, a modular architecture anyway, and we expose APIs. And we can consume these APIs to create our customizations. And our customizations are in additional microservices, which again can expose APIs. So we can even extend these by consuming these APIs, again, in other services, which also allows us to deliver pre-configured components. So you can create a microservice that is your registration service that is used in all your customer-facing or your supplier-facing digital services.

And it's always the same because it relies on the same service. We can orchestrate the same way with other services like ITS, etc. And this is, I believe, what we can do. And so I think it's very important to also utilize the potential the Identity Fabric has in that way to externalize it. It's not easy. Not long ago, I published on LinkedIn an article about customization of IGA. You probably easily will find it when you look at my LinkedIn account. There were many, many comments that I commented back on many of these comments again. And I think it's not easy, but important.

And yes, there's customization sometimes needed. I think the first thing is to think about, do you need customization? Or is it that you don't need the bells and whistles behind that customization request? That would be the first question. If you need to customize, do it the right way. So for instance, especially never code against the data model or so. Data models change.

If so, then create your own API wherever or something like that. But ensure that the API, that the interfaces are stable, that you're in control of them. Then a lot of the problems you may have experienced in the past will disappear. And anyway, I think with IDAS, we have more customization, more configuration, lesser customization, which also helps. Okay. What should you do to move forward? This is a model of my advisory colleagues used and I've brought up. And that is really...

The first thing is you really need to understand what you want to do with IAM, what you need to do with IAM, not only today, but also in the future. And also to understand where do you have IAM already? Is there something you need to bring together? Or is there a reason to leave things a bit separate? I think there's always an advantage in logic to bring things together. I know that sometimes the customer-facing part is kept a bit separate, but there are a lot of overlaps and integration points anyway. So I think it makes a lot of sense to, at least from a strategic perspective, look at it.

You still may have different implementations. You may run different instances of the same tool or have different tools for, depending on the use case, all fine within an Identity Fabric, as long as you understand what you have, why you have it, avoid what you can avoid, the redundancy, accept what you need to accept in redundancy and have the gaps filled. So the Identity Fabric's picture and the reference architecture are a very strong starting point.

And we have some, my team has a, our team, I'm not in charge of it, it's my team, the device team has really some very good methodologies on walking through that and coming to results relatively quickly. And then you need to understand on your side, what needs to be done. So observations, where do you stand? What is it what you hear? And what is lacking? And then analysis, understand the consequences. Look at your expectations. Where do you want to be? Define your requirements. This is so frequently one of the things that don't work well. Without a good requirements analysis, you will fail.

And the requirements analysis is truly based on what is lacking, what is not working as expected, what do you have already, and what you want to keep. But also what will come up from a regulatory perspective, from the technical evolution, from new use cases, you need to bring everything in that. And this is clearly all something where it may make a lot of sense to work with external experts, specifically when it comes to what will potentially happen in the future. And then you go out and do an RFI, RFP, and walk through the different types of vendors.

Step by step, it's not usually one for the identity fabric. It probably will be more than one, depending on the pieces you have. Part of that is then structured analysis. For instance, a structured analysis of where to start. You can do that with, this is what the market sees as important, and you, on the other axis, you say, this is my priority. You can take your priority and your gaps, so take the x-axis and put a gap on the horizontal axis. Where's your biggest gap? Just when you do it, always ensure that the upper right edge that you find the most important things to do.

And then you can prioritize and then cluster the different elements into, oh, what is it where I should start? What is it, for instance, when you did more of the gaps or the need and stuff like that? You can say, okay, this is really my biggest gap. There's a huge need, a huge pressure. I'm not very mature on that. And then you say, okay, this is what pops up on the upper right corner. That helps me understanding where should I start my journey? Where should I begin with everything? So this is relatively easy to do, honestly.

This is an exercise which is done in a very short period to understand what you do. And then that helps you also to define your roadmap. And then you, at some point, go out to the market and look at who are the players in this market. Here are the two of the leadership diagrams from our recent leadership compass on identity fabrics. You may also spot that one or two very prominent vendors are lacking. And one or other occasion is because the vendor said, I don't want to participate. By no means, happens very rarely for this.

In some cases, it's because, for instance, vendors are very focused on, like take SailPonder or some others, on, for instance, IGA or only access management. And the expectation is that a relatively broad set of capabilities is covered, or vendors are very strong in orchestration and refocusing orchestration. Some vendors don't fit into the full identity fabrics picture, but can be like the SailPoints, Omadas, etc. of the world, can be a very, very important element of an identity fabric when you build it from different tools, like also many of the PAM tools. So this is just to help.

And the best thing is really to start with building your, so to speak, your own identity fabric. Before we go into the Q&A, and again, enter your questions, vote for the questions, then we can really try to answer all the questions which are here. But before we do that, let's maybe quickly look for the second poll. And this is really about where do you stand? So do you have something like an identity fabric concept and IAM blueprint that covers all major areas? So all types of identities, all types of use cases? Do you have it in place and regularly updated? Or did you do it once?

Or is it in work currently or not in place? So this remains open while we go forward to the Q&A session. So next here is then, as I said, the Q&A. So the first question I have here in front of me has been already answered. So the next question from a voting perspective is, who should be in charge of the identity fabric? That clearly depends a bit on the organizational structure you have. So in many cases, the first line of the CISO, if it's the first line of defense on acting CISO, so to speak, also is right now in charge of identity management.

And then the CISO below this is usually the head of identity management or whatever the formal title is, are in charge of that. And this is, I think, a relatively proven model, having it in the IAM department, which then frequently reports to the CISO so that you say, this is where I bring these things together. That may require that also, as I've said, shifting some of the responsibilities, like AD or intra-ID, or sometimes also some of the CM tools into just responsibility, because it's a service that delivers to the other applications.

And I believe it should be, in one hand, I think that makes really a lot of sense to do it that way. Next one. Does Kutma & Kola have a methodology to guide customers through this process on what they need, what is missing, and what to do first? Not very surprisingly, the answer is yes, we have. We have a process in place, we have a methodology, and our advisory team does it quite regularly, really working on how can it look like, what is needed, et cetera. So just reach out to me, reach out to my colleagues, and we will provide you the information you need.

We also have our KC OpenSelect, which helps you, when you look at the vendors, to sort of build a bit of a short list to figure out who might be the right one to do that. The Identity Fabrics one will be launched relatively soon as in the next couple of weeks. We also have a lot of research out there, and I don't have a slide on that, but again, I'd like to hint on the European Identity Conference, which runs DIC, which runs in Berlin, June 1st to 7th. You'll find all the information on our website.

I hope to see you there, because it's really, I would dare to say, the must-attend event in identity management. You definitely shouldn't miss.

Okay, then further questions. Shouldn't we define, and I've seen that, shouldn't we define an Identity Fabric, a CM Identity Fabric, a Consumer Identity Fabric, or an Identity Fabric for API-based security as specializations?

No, and I tell you why. The idea of the Identity Fabric is the umbrella, is the holistic perspective on that, and then you can say, okay, I take a sort of a view on that and look at what is relevant for CM, what was in my Identity Fabric is relevant for CM, what in my Identity Fabric is relevant for API-based security, what is relevant for my IoT world, and it will be always parts of that, but I think this is the right way to look at it.

So, really saying, okay, what is in this Identity Fabric is what I should look at, and what of that is relevant for a specific area, and you can clearly also start of constructing the Identity Fabric from different pieces, bringing it together, because we'll have a lot of things anyway, but I think this is the way to look at it. So, we currently, also, we can have a bit of a look on the polls.

So, when we look at the first poll results, technologies, so it's Decentralized Identity first. I think Consumer IM is already there, so it's probably lesser than the trending topic.

Fabrics, I think I probably impacted the votes by saying it's not really a technology, but a set of technologies. Passwordless authentication, also very strong. I believe Decentralized Identity, my own perspective, definitely is one of the most impactful technologies, because it will really change a lot.

So, yes, we shall thank you for responding to that. We'll look at the other poll a bit later.

So, okay, let's look which questions didn't respond to. Here's one. Is the source of your identities, like HR, and it goes back to the reference architecture, where we had the extended IM or in the integrations. The question was, is the source of your identities, like HR, also kind of an extended IM at the source side? I think it's a fair point. We should think about it. Maybe we should add this. But really, from a responsibility perspective, I probably never will be responsible for the HR system. So it's probably more on the integration side.

But when you look at the reference architecture, you also will spot that in this reference architecture, there's an area which is about identity information quality. And this is where HR really comes in, because this is about HR systems, in plural. I've seen organizations more than 100 about other sources, because when you think not only about the workforce, then we have many, many other sort of systems.

And how can we really create a quality of information, which is a process thing, which is a communication thing, but it shows a technology thing, identifying the duplicates and cleansing the data and all the other stuff. So, yes, we will think about where to put it in. To a certain extent, it's really in the identity information quality piece of it. Next question, can I converge my existing infrastructure into an identity fabric? I talked about this. To a certain extent, yes, you can converge, depending on how modern, how good the technology is.

Maybe we'll look at the second poll in the meantime. Okay, it's already displayed, and it shows that a lot of you are working on identity fabric model, which is good. Few have a regular update here.

So, few have really this, in a process already where you say, I look at it at a state, I want to evolve very regularly, do it. It's important, because IAM never stops. It always goes forward.

And yes, we see that here, the poll. So, you have that here, and I think it's an interesting picture. And I see half of you are already working on that, which is, as I've said, very positive.

Okay, back to the questions we have here. We had this one, we had this one. Just try not to miss one when it's shifting up in the list of questions. How do we develop it? I would say, start with understanding what you have, where your gaps are, and where you want to be, and try to map this. It takes a bit, but it's not a really long-running process. And this goes to another question.

So, defining models is time-consuming, isn't it? Yes. But just doing something, at the end, is much more time-consuming.

So, developing your identity fabric, your bigger picture, your roadmap, etc., even with the usual delays of, oh, these people are not available for that workshop or so, that come in a project, it can be easily done in significantly less than three months in most organizations, unless you have many, many people in there.

So, where do you find detailed descriptions, definitions of KZ reference architecture? There's a document on the reference architecture available on our website.

So, you can always look at our, when you go to our website to research, you can search in the research for documents like that. So, we have material here, and we're always happy to support you with further information. One interesting question here as well, how do you see the role of AI in an identity fabric? Good question. I think there are two things.

There was AI as part of identity measurement, then it's trust capabilities, or it's supporting the better delivery of certain capabilities, like analyzing who currently has access to what, like in the user behavior analytics or identity threat detection response. But the more interesting question is, from my perspective, how will an identity fabric look like that supports, for instance, autonomously acting agents?

The control plane, the policy control plane will become much more important here, I believe, while an agent at the end of the day is, in some sense, so, I think the interesting thing then is the agent has an identity, but it may access services, but it's also a service that is accessed. So, this is something we are currently discussing internally, how to build, so to speak, the identity fabric for 2030s. A lot of things are in there.

So, we don't have that much time left, so I need to look at a bit of the questions that are coming in. So, there's one question. Entry ID is often controlled by IT.

So, IT in the sense of IT infrastructure or other parts of IT. How to get IT to transfer entry ID to IAM? How to do that? It's not always easy. I agree with that. At the end of the day, I think it's something where the head of IAM, the CISO, at the end of the day, need to, on one hand, talk to the infrastructure people, which usually are not very willing to hand it over, and to go through the CIO and maybe to refer to what I'm saying.

So, sometimes the analysts, some people believe analysts more than other people, which might be good or not. Not about me to judge about it. Okay. Cool question here. Will identity management features built into some cloud services, so we see a lot in AWS and others, make separate dedicated IAM solutions obsolete in the near future? I doubt. Because they are usually really focused on a very specific domain. We see clearly that a couple of the cloud service providers have strong IAM offerings. We talked about Entry ID. We see some stuff from Google as well.

But except a few, they usually are not trying to become the provider of the full comprehensive set of IAM features needed in an identity fabric. So, I think that these are, in tendency, honestly, more target systems, which then serve the details of a specific environment than the other way around, which then would probably give us enough material for an entirely separate webinar, where we talk about is this really good or bad?

Because, you know, when we, for instance, manage access and applications through Active Directory groups, I think a lot of us have learned that this is not, let's say, friction-free to do. So, there are a lot of challenges we need to keep in mind.

So, this is really a huge topic here. So, we have done this.

So, developing the own identity fabric, I think I've touched this, is really looking at gaps, requirements, these things, building the picture, relying, to a certain extent, on the materials we have, all this stuff. I think this is a good way to do it at the end of the day.

And so, there's one more question. Michael, do you have a question for me? There's one more question. Microsoft's Entra ID has a lot of services, but truly has done everything.

And yes, there's rarely a one-stop shopping for an identity fabric, because depending on what you need, specializations, there might be additional tools, additional requirements you have that you need to cover. So, I think that was a relatively quick information about all the questions I have here, quite a number of questions. Feel free to reach out to me. Here's my email address. You'll also find me very easily on LinkedIn. I just want to say thank you here for all of you for participating. This could be a webinar to my team, who organizes the webinars and makes them work.

And hope to have you soon back at one of our events, especially hope to see you in Berlin, June 4th to 7th at EIC. Thank you.