The Signal-Driven Identity Fabric for 2040

Welcome to our KuppingerCole Analysts webinar, The Signal-Driven Identity Fabric for 2040 and beyond. I'm Martin Kuppinger. I'm Principal Analyst at KuppingerCole Analysts, and I'm your host and speaker today. Feel free to ask questions at any time. I'll go through the housekeeping in a minute.

So, basically, what I want to do today is having a look at the identity fabric around some thoughts or some thoughts we have around where is this evolving. I'll shortly comment on one or other current trend or hype or buzzword in that context. We'll also look a bit at results from the relatively recently published Leadership Compass on Identity Fabrics on platforms that can form a foundation for building your own identity fabric.

Also, clarifying a little bit around terminology and what it is, what not. So, that will be what we will do today. From a housekeeping perspective, we are controlling audio. You can mute it centrally. Nothing to do here. We will run two polls during the webinar, one towards the end, one towards the beginning.

Actually, three polls right before the end of the webinar. There will be also a feedback poll on how you perceived this webinar. There will be Q&A after my presentation, but you can enter questions at any time using the questions area at the lower right-hand side of the screen. And last but not least, we are recording the webinar and we will share the recording as well as the slide deck within the next couple of days.

So, in the first part, I'll talk a bit about my perspectives, my thoughts, and our thoughts on the identity fabric for the 2040s and where this is evolving, but starting a bit from the ground with what is behind this concept, what is essential for that, et cetera. The second part then will be, as I said, the Q&A, but as mentioned, you can enter questions at any time using the questions area. The more questions we have, the better it is. But before I dive into my subject, I want to bring up the first poll. This is a bit about the state of your IAM infrastructure today.

So, what is it that you're using? Is it a converged IAM suite where you say, okay, this is basically the one suite which serves all or most, at least by far most, of your IAM needs? Or is it an orchestration? An orchestration, as I'll touch on later, also really means orchestration of multiple solutions that are neatly integrated.

Or is it, and that's sort of the opposite thing of the orchestration, are it loosely coupled or uncoupled IAM tools? So, the poll is open. It will remain open for a while.

So, you can go to the polls area on the lower right-hand side of the window of this webinar and participate in the poll within the next few minutes while I start talking. So, when we look at 2040, so I brought up this 2040 thing a while ago, and it was interesting to see the reactions.

So, the initial reaction tends to be, why should I think about 2040 now? Interestingly, after my explanation, so after going through that slide, there's a tendency towards, why only 2040? And this is my equation behind it. It's 2025 plus two plus three plus 10. That's 2040. What does it mean? It means we are in 2025. When we go into a major identity management project in a, let's say, larger organization, we can probably factor in two years of planning. Maybe we are faster. Maybe it takes even longer. Let's take three years of implementation.

Also, definitely not unrealistic. And 10 years of use.

So, when you look at how long are your current IAM tools, be it access management, be it IGA or PAM, already in place, then 10 years also is definitely not too long. And that brings us to 2040. What it means is simply, everything we do today must help us as soon as possible, but it also must serve what we need in 2040.

So, we must really think beyond the current state into what will be there technology-wise in 2040, what will be needed in 2040, and how must it look like to still deliver in 15 years from now and beyond. And this is, I think, a very important thing when we really start investing, that we not only fix current problems, that we not only look at the current state of how does identity management look like today and what did a great job for the past 10 or 15 years. What did a great job for the past 10 or 15 years not necessarily will do a great job for the next 15 plus years. It may or not.

And that's why we need to think about it. That also means at the end, and this is where the identity fabric also comes into play, a lot of this is thinking about architecture, about principles, about concepts. We need at least to be prepared for, we really need to be prepared for change. No one knows what will happen until 2040 innovation, but at least we should look at building something that is making good use of the options that are and the potentials that are visible, the technologies, the principles that are visible already today that are sometimes out for a while.

So that's, I think, very important. So when we look at the identity fabric, and you'll see over the course of this webinar that I have a bit of different background pictures here for these buzzword slides. Sometimes it's more a factory, so fabric in the sense of a factory producing services. And sometimes it's more a fabric in the sense of a mesh connecting things, orchestrating things, bringing things together.

And there's really this dual meaning behind that, that the concept of the identity fabric we had brought to the market some, it's almost a decade ago, eight, nine years, from the very beginning focused on both aspects. It's something which delivers identity services, but it's also something which connects the different bits and pieces you have in identity management, which integrates and which orchestrates them into a more integrated thing. And I'd like to start with a bit of a, so you may have seen some of the identity fabric charts we have produced.

I'd like to start with a little bit more simplified, we could further simplified picture, because I believe it's important to step a bit back and look at what is it really meant to be. And when we started with the identity fabric, there were, I think, two major drivers. The one was that around that time, consumer identity management emerged. We saw some first B2B identity management, and some other sort of incarnations, plus we had clearly already privileged access management, and IGA, Identity Governance Administration, and access management, and some other things around.

And the question we looked at was, should we really end up with yet another identity silo for every use case? And that doesn't make much sense. There are a lot of capabilities, which already may be there, which might become reused. And that was one of the sort of the starting points. The second was thinking about what is the real job of identity management? At the end of the day, the job of identity management purposes to provide seamless, but yet secure, well-governed access for everyone and everything, this is the left-hand side, to every system, service, application.

This is the right-hand side. So identity management, that sits in the middle between the identity's left-hand side and the target system's right-hand side, and needs to deliver what is needed to bring them together in the way we need it. And from the very beginning, we looked at human identities and non-human identities, which is a bit of a tricky term, because I think the focus is on certain types of non-human identities, and there are very many of these and very different ones. As well as on the human side, there are quite some differences.

On the other hand, at the end, there are identities, there are potentially accounts, there might be secrets, there are entitlements. There are a lot of things which are in common, and things that are different across these identities. And then we started looking at, okay, what are the capabilities needed? This is a bit more a coarse-grained list, you can go deeper here. Which services do we need to deliver these capabilities, and which tools help us implementing these services? And it very clearly goes from left to right. It never goes from right to left.

The tool is something we, at the end, have to implement the service for capabilities we need. And when we start with capabilities, we also may observe that some of these capabilities already exist. And then we need to think about, do we need additional capabilities, or better capabilities than the ones we have?

If so, is this really a new service, and do we need a new tool? I think a wonderful example for that is the current hype around IWIP, Identity Visibility and Intelligence Platforms.

First, it's not a platform, very clearly not. It's a tool that delivers certain capabilities. If we say the platform, then probably the platform is, in that sense, the fabric, or maybe the orchestration platform. But this is a tool that delivers capabilities. Some of them we may have, some of them we may not have. And then we need to think about, do we need this? How does it fit into our services? But you always should think from the capability side of things. Do we need certain types of capabilities? And the answer might be, in this case, yes or no. As usual.

And we also need to prioritize, et cetera. Our advisory team, for instance, we also created a reference architect for identity management. They have some very well-proven methodologies to walk customers through from the needed capabilities or the capabilities that exist at all. Do you have them? In which state are they? Is there something to do? Do you really need it or not? A very important question. You don't need everything. You need certain things, and some of them have a priority. Then you can prioritize.

Then you can come up with your representations of what are the clusters of technology you need first? What are the big gaps to solve in which order your roadmap, et cetera? So back to the fabric. Left-hand side, different types of identities. Right-hand side, the target systems, capabilities, services, tools. On the lower side, there are also connectors, scripts, code to connect to legacy applications, but also to legacy identity management. You will not build your own identity fabric in a day, so to speak. It will not be a big bang release of something, but it will be something which evolves.

And there might be components which are really legacy, which don't really fit into this concept of that. It might also be that you say, okay, I have whatever, an older IGA tool, and there are certain types of applications which are really hard to move to a new tool. If you have some still existing mainframe connectivity you need to maintain for a while, it might be even an idea to say, I run this as a target system. In that sense, the side of my legacy applications.

On the top of the graphic here on the right-hand side, you'll find also standards, connectors, scripts, code to connect to digital services and SaaS outgoing. So you manage them. You create accounts. You manage the entitlements like you traditionally do also on the other side in the, so to speak, established legacy, whatever you'd like to use as a term, identity management. But on the upper left, there are also digital services connecting to an identity API layer. This is really also a very important and essential element of the identity fabric.

For us, an identity fabric must expose APIs in a defined manner as an API layer, which can be consumed by digital services so that someone can build the services upon identity service. This concept became very popular relatively early, for instance, a consumer identity space where some of the consumer identity solutions were factually very API-based and developers could develop against these consumer identity management services. But we see the same happening nowadays, for instance, in the new human identity quotas space where tools then work against basically request identity services.

I think this is a good way to segregate ownership responsibility, et cetera, between different domains in your organization by delivering the right identity services instead of trying to get control about everything by connecting to it, managing it in the sort of traditional, sometimes needed, sometimes relatively intrusive manner. We do it with the standard concepts of identity management. Keep in mind what I've said here. When we right now go one step further, then this is a bit more advanced picture we frequently use.

Capabilities are grouped in different areas, but it basically is the same idea. Capabilities that are mapped into services that are then delivered by using certain types of tools and services. Not fundamentally different here.

Again, it's not that you go and say, okay, this is what I need. I take all of the bullet points on the capabilities and I look that I have them. No. There might be things you need beyond that. There are always the three dots for saying, okay, there's more. There might be things where you say, I don't need them. I have whatever. The list of services probably will look somewhat different for you. The list of tools may look different. There might be also capabilities at the end, just be realistic that are provided by more than one tool.

You then just need to understand that this is the case and understand what it means and what you want to do with it. This is something you say, okay, this makes sense because at the end, there are different types of same capability, but in very different use cases. You want to keep it segregated or it is that you say, okay, I'm hard to fix. It's just there. You have two tools delivering the same capability, but you use it only from one tool or you plan to retire the one tool. It depends on. Don't see this as something which is put into stone. That's the way an Identity Fabric must look like.

The basic principles in that sense are put in stone, but how you feel capabilities to services to tools, that is what you do for your domain. There are more principles to look at. When we look at today's Identity Fabric, there are these red arrows that indicate custom integrations. Then you have potentially quite a number of tools. Most of these tools come with their own set of connectors, which is definitely a burden because it means that you need to integrate with the same target system sometimes multiple times.

So not every tool connects to every target system just from a functionality perspective, but some do and you have multiple connectors. Okay, for AD management, you probably have less connectors to be fair, but at the end, you may have some of these and then you add another tool, you add another set of connectors. This tool may integrate with others like whatever IGA may integrate to PAM for managing the ownership of rich accounts or consume events from access management or whatever else, but it's a lot of custom integrations.

And to go further, there also might be situations where you say, okay, there's still a lot of things which are lacking. So the custom integration challenge, no exposure of identity API layer and identity API layer, a consistent set of APIs, a lack of management of certain types of identities, all these things come together. If it's just loosely or uncoupled tools, I wouldn't call it an identity fabric. That's not an identity fabric. So there are architectural paradigms that we see as essential for an identity fabric.

Amongst these are modern architectures, modern deployment models, and integration capabilities. So orchestration is something which is essential, having sort of an orchestration platform, an orchestration layer in that identity fabric. By the way, as I've said, the Q&A is open. You can enter questions at any time. Feel free to enter the questions. I'll either pick them up during the webinar when it fits into the flow or then the Q&A session. So don't be shy. Raise your questions whenever they come to your mind.

So when we look at this picture, then we may have, or in an identity fabric, there should be some sort of an orchestration platform. That could be no-code, low-code. It could be support pro-code. Maybe as a quick side note, if no-code, low-code, still look for support for, I would say, just good practices in software development, documentation or comments on the code, versioning, and all these things we need testing, et cetera, proper staging. All these things are elements that we need also when we work with no-code, low-code.

It's not a very good idea to just create these no-code, low-code solutions. That will potentially end up in what I tend to call the next Lotus Notes disaster. So thousands of unmanaged orchestrations where after a couple of years, no one knows who did them, for which purpose, in which state are they, or anything like that. We must work very properly here. I think we could even say, just apply good human sense here. What we have in the center of the graphic is then we may have some sort of a partially or converged IAM solution, which is available.

There's a lot of connectors that are used by different components, which has some AI capabilities maybe in already some centralized authorization capabilities. It's a common UX, some workflow capabilities. We may have still other access management tools, some more tools like Keen, et cetera, which are not integrated. But some of that then may be orchestrated in this integration. So this is where really then where, for instance, authorization then is orchestrated with other tools using that orchestration platform.

This is where it really starts to become a fabric, an orchestrated set of components. These components should follow principles like microservices architectures, flexible deployments, including as a service, but not necessarily limited to as a service. So flexibility can be very helpful here. Frequently also sort of containerized deployment, stuff like that. So that should be really principle API. So everything exposes the APIs and the tendency API first, whether the UX of the solutions or the tool you purchase, the SaaS applications really build on the APIs itself.

That should be the way these solutions are built. Then moving from there, again, look at what do we have? So frequently it is a bit of this, how do we balance sort of converge versus specialized tools? What is really important is, as I said, the orchestration platform and center. The question is, are we there that we move at least to sort of integrated services? At least some mash, some platform here maybe. How do we handle new types of identities?

So we started looking at workload identities very intensively, which is what is frequently called machine identity nowadays, or non-human identities, the latter being a bit more of an umbrella term. But at the end, we have also other types of machine identities, so to speak, for the real machines in operation technology, stuff like that. But you also see other types of identities appearing. For instance, autonomous identities like agents and bots and stuff like that.

So that is what we see, I would say, as a current state where many organizations that move into this world of identity fabrics are in sort of inner transition orchestrations appearing more in an integrated perspective, but there's more in that. I'd like to bring up a few theses here about how IAM will evolve, which are around convergence versus mesh, around AI identity, so the intersection of AI and identity, around autonomous identity, the future of authentication, and policy-based access control, and even beyond policy-based access control.

And when we think about 2040, we also should think about change, and sometimes that might be more radical change. So we had a lot of discussions in the past two, three, four years maybe around convergence versus mesh. At least I believe strongly in the orchestrated mesh at the core. So when I go back, I remember when we did our first European Identity Conference. This was our annual conference. We were running every year in May in Berlin.

When we did the first one, which was in Munich back in the days in 2007, someone said, hey, there are maybe at the time 70 or 80 identity management vendors, depending on how you count them. And then some of them already started acquiring others, some of the newer emerging vendors. And the question was, why do your conference for a market where maybe only a handful of vendors will exist a few years from now?

Now, in 2025, we probably have more than 1,000 identity management software vendors or cloud service providers. We alone have several hundred identity verification players. We have a lot of vendors and many of the other subsegments of the identity management market. And for me, it's sometimes a little bit like a hydra. So one of the larger vendors becomes acquired, and seven new vendors appear. So we see that there's a lot of innovation. But there's also a logic in saying, okay, there's a sort of a foundation by tools that deliver a lot of capabilities for an identity fabric to start.

So the converged solutions will remain here, but they will need to support integration with others, and use as well as provide common platform services that also can be well integrated, orchestrated to other types of solutions. Because this world of IAM is still far from being really mature, it's evolving continuously. And we need this flexibility. And an orchestrated mesh helps us here. The second part is AI identity. And just this morning, I was asked about MCP server and identity and security. So these MCP servers are one of the hot scenes these days in AI.

And the entire field of AI identity, so this intersection of AI identity, AI for identity, it will help us to do a lot of things better, hopefully moving away from standing privileges, from a lot of things we do in rules and roles. And even there's something I touched a minute beyond policy-based access controls. A key success factor here will be AI governance, so that we implement really governance for AI, so that we can really utilize it for many of these things. But we also will see that we need to understand, how do we manage the identities of AI bots?

Also, the complex relationships. So someone or an AI bot acting on behalf of someone, an AI bot creating new AI bots, and things like that, all these relationships must be handled well. And also the entitlements of that. But it will be something which will happen. We will go through some learnings here, as usual. So when you look at MCP servers, it's again innovation with security, governance, etc. as an afterthought. But we will manage this, we'll get a grip on that, and it will empower what we do. We will see autonomous identity evolving in certain use cases.

For instance, when we look at some of the non-human workload identity management use cases, we're talking about large-scale environments. We can't work in the style. I think this is a very important thing. We can't do identity management well when we try to do everything with the same principles we used for our workforce, or employee identity management for the past decades. These concepts were built for a certain part of our identity management. But when we talk about ephemeral identities in workload identity management, then our traditional joint removal principles won't work.

We even need to question, do we have identities and accounts and entitlements? How do we handle it? How do we automate? We may even learn from the other side of it. We may learn from automation, from creating things automatically in a very dynamic manner for all the traditional use cases like employee identity management.

But also, when we look at whatever smart infrastructures or autonomous operational technology where we have locked up environments, then identity fabrics must become autonomous. It will be an interesting playing field, well beyond our common perspective on the employer with a little bit of the suppliers.

Yes, there's a bit of consumer, and we start thinking about this NHI in the sense of workload identity. We must think beyond that. A lot of this is really more and much bigger. We will see authentication changing.

Passwords, anyway, are outdated. We all know, still use it. We are especially permanently asked. When I go to the internet, most of the sites there still rely on username passwords. This is so much yesterday. It's insecure. It's a bad practice. Even usernames are mostly outdated today. A lot of the things we do is we don't use a username anymore. We use maybe our email address, which is sort of a username. We use our biometrics at the end of the day. When I use my phone, I still use a password. I don't think I've ever done that, but things like that.

I believe we will go into more and more of a passive authentication where just the context, the passive biometrics, all of this delivers signals for a strong authentication. Enough context for most scenarios where the sort of active authentication will be the exception, not the norm. We will move beyond policy-based access control.

Yes, we could argue we are not even there. We have policy-based access control around for long. It's not really new. Some of you may remember XML, extensible access control, markup language. A lot of hype back in the days. Never gained the traction we hoped it will, but I think when we look at 2040, we will probably be beyond that. Policy-based access control is a step away from standing privileges towards dynamic authorization, but the policies will quickly become very complex and we will need help for creating, for maintaining, for optimizing policies, which means AI comes into play.

AI will help us quickly to make, I would say, more created decisions. When we have a policy, the result is basically either yes or no, allowed or not allowed. If we want to make this very differentiated, we need very complex policies. AI is much better in doing so, but we need to have an AI we can trust for making such decisions. That will be one of the things I expect to happen. What does it mean for an identity fabric for the 2040s? So my next question here, and what I expect to happen there is, so to speak, the full mesh.

Something which really helps us in bringing together a lot of bits and pieces into a combined platform. We can argue about the fact that for AI, so the AI identity piece will also be one of the central platform elements. I have all orchestration platform here and authorization platform here for now. We could add AI here. I refrain from adding data here, so we see some discussions around the data piece because the data is a very static thing and defining whatever a standard identity data model probably will not lead to any results.

A lot of this philosophy, when we go to the inner part, lower left side, we have this signal exchange. A lot of what we do will be based on signals and flows, lesser than on accumulating all data in a single place. I think this is a tendency we see in other areas as well. So we see this security data pipelines or security telemetry pipelines evolving as an alternative approach to gathering all the data into your senior security information event management. The same will happen to identity fabrics.

We will see a lot of signals flowing from the identity fabric and to the identity fabric from different tools. We will have at the core orchestration platforms, authorization platforms, and maybe AI. So because in the supported services after AI, we also could say they probably better fit into the central thing. We will have connectors, which are reusable by different components. We have supported services like our UX built on APIs, our risk management identity information quality monitoring services, maybe reputation services, relationship management, etc.

And we have our core services, and some of them I put already in quotas, because some of them will definitely change fundamentally. IGA in 15 years from now will look very different because we will move away as much as we can from static, from standing entitlements. Consumer identity management already moved or changed quite a lot into more customer data platforms and authentication platforms. PAM and key cloud infrastructure entitlement management and some parts of NHI and secrets management have a strong logic of conversions in it. So it will change.

But at the core, there's orchestration, there's central authorization, which is beyond PBAC, as I've said already. We will see also on the very left-hand side, other types of identities, organizational identities, smart infrastructures, maybe even for certain more consumer-centric use cases, maybe post-modern identities, stuff like that. On the other hand, we will see other types of identities emerging like smart infrastructures more around AI.

And our fabric of the future will be a mesh of services that are orchestrated in a very flexible manner with orchestration, with authorization platforms at the core. So that will be the way we envision it, which also means from a technology perspective that API-first architectures, modular architectures are essential. And from these services, it might be that you say, okay, most of them come from a single vendor. Or you say, okay, I have a really big mix and match from different vendors. There's nothing which says it must be all sort of single modules or all converge, but both fit into that.

Usually the point will anyway be, this doesn't happen in a greenfield approach. You start, don't start from scratch, but you will evolve into that. And then it's important to have the principles in place. But one of the really most important things will be signal exchange. So signals are something which helps communicating between different services.

So if your services for managing authorizations and granting access, in which way ever, receive signals from your access management about, okay, session started, session ended, that this is something where you can manage who has an entitlement at a certain point, what has an entitlement at a certain point in time or not. So in principle, we strongly believe that orchestration, policy-based authorization flexible based on the platforms is really the key.

And then there will be, as I've said, other services like also services that provide you visibility, provide you insights here that are an element of such a fabric. But always keep in mind, there's a difference that again, between the capability and tool that delivers the entire thing. So this is at a very, I still at the high level perspective on how we see the identity fabric evolving, which are sort of central principles for the future. As I've said, will immediately or inevitably lead to reuse of connectors for many of the scenarios.

And that maybe helps you, hopefully helps you in sort of shaping what you're doing. As I've said, we recently did a leadership compass on identity fabrics. And the focus there is when we did this leadership compass to look at technologies that usually provide a good support for multiple core areas from a capability perspective. So access management and or PAM and or IGA, and maybe some other aspects, plus ideally also deliver relatively well on orchestration. So which have an orchestration platform.

And as I've said, and I think this is very important, you can also build your identity fabric with a lot of small tools. You can start saying, okay, I use one or two or three of these more powerful platforms, maybe as a starting point, and then add the other components. You extremely rarely will end up as a single tool approach, because there's so much evolution in the market, there are new things happening quite regularly so that you may say, okay, these are really cool new capabilities I need, and I need them now, I'll add them.

But always try to integrate, to orchestrate them with what you have, not to have at the end, a lot of sort of more or less isolated tools with custom integrations. This can't be the right way forward. I just want to quickly look at two perspectives. One is the product leadership and the other is the innovation leadership I put in yesterday. So the product leadership shows that we have first quite a number of vendors that we analyzed, and there's plus a very long list of vendors to watch in this report. The leadership compass is available on our website.

And we see some vendors that are usually more powerful from their overall capabilities, some of them also being quite mature in their sort of orchestration offerings. But we also see specialized orchestration players then, which really focus more on the orchestration piece, some of them then more towards the bottom of the list, which then really are sometimes specialists that serve a very specialized, very specific use case. And what it also shows is there are many vendors that are in a, I would say, in a good position to be part of your own identity fabric of what you build.

But at the end, it's the tool where you always should start, start as capabilities to services, to tools, and looking at what is it really what you require to build something that deserves the title identity fabric. Innovation is looking a little bit different. Some of the specialist orchestration players scored them significantly higher here, because that is, from the innovation perspective, something we looked at very intensively, very closely.

So, this is just a quick glimpse here. As I've said, feel free to download the report, which gives you, again, a lot of background on what you should consider when building your own identity fabric. But the first thing really is I'm saying, okay, what is it what I want to achieve? How should it look like? What are the main principles? And then looking at the capabilities.

And here, the identity management reference architecture we've created, which we are regularly updating, also should be, I would say, a very valuable resource. As I've said, my, or our advisory team has some proven methodologies here that helps you going forward in a very structured approach from the different building blocks and capabilities and, speak at the end, technology areas, to what you need and build your roadmap and then moving forward with creating your own identity.

And so, when you say, okay, I'd like to work on my own identity fabric approach, what do you see as your biggest challenge here? Is it budget? Is it the integration complexity in the sense of that you feel what you have is not really easy to integrate, even with a good and modern orchestration platform? Is it a skills shortage? Or do you just say, okay, just not a priority right now? I'm curious about your perspectives here. The poll is open, so please feel free to respond to it in the background.

So, let's move to the Q&A. And there already are a couple of questions. When you go to this section of questions, you also can upload questions. That's also very helpful, always very helpful for me, because I then can pick the questions that are of the biggest interest for you.

And also, please enter more questions if you have, so that we have a lively Q&A. When we start here, there's an interesting question that is about how fits a business continuity management in this concept.

So, how do we handle emergency users? Still putting them in a safe, in a paper form. For an identity fabric, we have a lot of tools. And that also means that we need to think about how can we secure access to an identity fabric or to the different tools within an identity fabric.

As usual, I think it's starting with what are the really critical tools? What is what always needs to be on? And how can we ensure that we can have... At the end of the day, putting sometimes an emergency user in a safe in paper form still might be a viable way to do it.

So, because we always need to prepare for the worst, and preparing for the worst at the end of the day means we need to prepare for a situation where not much works anymore and where we need to power up systems. And sometimes this is the only way to do it.

So, what is it if you're... So, we had this situation.

So, I was in an advisory thinking about what happens if you're whatever, your intra-ID is off for a longer time. So, not just a few minutes. How do you handle that? And that then goes into really resiliency. And resiliency in this case, this is less about the emergency user, but it's about maybe even having a solution in place that helps you at least continuing to run your really critical business systems, the ones that can't be off long, like everything which is used to keep your... If you're manufacturing company or a real telecom company to keep your core business up and running.

And so, really look at it from these, I would say, traditional resiliency approaches like incident management, like having a business impact analysis. So, building the knowledge here.

So, I think it's difficult to answer that question in a very short manner because there's so much in, but at the end, even as I've said, even a password in a safe can be okay. Then there's a question about, or there are two questions basically about orchestration. One is there are different types of orchestration solutions. One which is more about decisioning-based orchestrations. For instance, when we look at authentication, the other is more about user journey orchestration.

So, what we see happening over time, and if we click back to continue, is a trend towards more comprehensive, more holistic orchestration capabilities. So, I don't think we benefit from having the own orchestration engine per tool, but to really having orchestration platforms that can serve a variety of use cases in an efficient manner. It might be then, at the end, more than one orchestration platform because there are differences between, let's say, more the workflow or flow-oriented ones and more the flow-oriented ones.

So, we see more powerful platforms either delivered as separate solutions or delivered as part of some of the larger, and that's already happening, some of the larger, more powerful platforms you can build your identity fabric upon. Another question, as I've said, if you have more questions, feel free to enter them here. Feel free to ask them after the webinar, whatever you need. There's one more question, which is about orchestration layers. What are the top two or three tools that you see your clients adopting? I don't want you to comment on individual tools here in this webinar.

It's something we are clearly can do in a direct engagement. But what we see is that there are some more established areas.

So, orchestration within authentication, especially around fraud, fraud detection, that is something which is relatively established already. We see some specialized solutions in the access and other fields, and we also see some of the larger and some of the specialist layers coming up as really more powerful multi-use case orchestration platforms. I have a bit of a, as I've said, a tendency or preference towards the as long as it serves specific needs, but I think we are still pretty much at the beginning of the entire orchestration journey.

So, there should also be in a minute or so, another pull-up which asks for your feedback on this webinar. I quickly want to hint on the upcoming identity fabric impact day, full day going very deep and hands-on and practical into identity fabrics, and one in November on identity-centric cybersecurity.

With that, I'm at the end of what I wanted to share with you. I think the QR code should go to my LinkedIn connect page. Feel free to connect with me via LinkedIn. If you have any questions, feel free to reach out to me. Thank you for your interest in this Click and Call Atlas webinar. I hope to have you soon back to one of our events or other upcoming webinars. Thank you.