As Alejandro said, I'll give you a bit of an insight on the Identity Fabrics Leadership Compass, but it's probably more the things around that, because the report is out, so you can read it. I don't want to read out an 80-page or so report here. It was not in 20 minutes, anyway. We'll give you a bit more of the rationale behind what we did this year, what changed, maybe also in comparison to previous years, and the way we looked at this topic. Probably most of you have seen that graphic. This is the 2025 version of the Identity Fabric.
There's a long advisory note out as well, which is available at our website, which looks at the Identity Fabric and our Identity Management Reference Architecture, which is closely aligned with that. The Reference Architecture goes even deeper into the details. The Identity Fabric basically is a way to provide a high-level perspective on how Identity Management looks like, but also give guidance here. It all started a couple of years ago when it first released. It was really coming from practical work and stepping back and thinking about what is the job of Identity Management?
At the end of the day, there was a much more simplified version at the beginning. I think we need to bring back a simplified version, maybe, so over time it evolves.
Basically, what is the job? The job of Identity Management is to provide a seamless, yet secure and well-governed access of everyone and everything to every service.
This is, at the end of the day, in a nutshell, the core of what we do in Identity Management. That can be workforce, which is the very traditional perspective that we added consumers, customers, employees, and also all the non-human, silicon, whatever, identities. I think there's still a bit of a need for getting more clear in terminologies.
I'm, for instance, not a big believer in the term machine identity for workload identity because, for me, a machine makes noise and moves, etc. I think machine identities fit much better, for instance, to things and stuff like that. Maybe over time we will come up with a broadly agreed terminology, but it's really a lot of things.
Also, increasingly clearly, and that's something I think I'll touch in the afternoon when we talk about AI identity, so the intersection of AI and identity, we also have more and more autonomous acting, AI agents, bots, whatever, that we also need to look at both sides of that. This is the higher-level picture. Yesterday in my keynote, I also looked a bit into the future of how I see this evolving, and we'll see there are even more types of identities, like organizational identities, maybe post-mortem identities. I had a very interesting conversation yesterday.
Maybe post-mortem is more on the personal, individual side, but there's also the post-employee, post-client side of things. That are really interesting use cases, how to handle that, where we definitely have a lot of work to do, something I'll start thinking about once my mind is clear again after the conference, so to speak.
But also, smart infrastructures, for instance, where we need autonomous identities which handle these environments. As I've said, we have AI on the target side, etc., and this entire thing will become more orchestrated, more mesh. From the very beginning, we looked at the term of fabric in two meanings, because this is a term, when we take the English term, that has different meanings.
The one is clearly more the fabric as in production, so we produce identity services, we deliver identity services, but also in the term of the fabric as a mesh, as this is fabric, something which brings together things. And over time, I believe this mesh element will become more and more important, which is also important for clearly technologies. So moving away, that's something we already see when you look at typical identity management products, how they have evolved over the past couple of years from monolithic on-premise solutions towards modular identity as a service solution.
So this is a trend we see in the market. And this modularity also will allow us to better combine services, but to combine them, we need orchestration. We need capabilities that bring together all these things, and we probably also need more policy-based controls to keep control of that. We will have, I talked about it, a lot of things flowing. We will have more signals. I think the entire topic of shared signals, continuous access evaluation protocol, CAAP, shared signals framework, etc.,
is very worse to look at in this broader context, because it will allow us to add another level of, I would say, orchestration in the flow of signals, for instance, to authentication when we have risk signals, behavioral signals, context signals, etc., but also to integrate identity and security further towards something. This term of identity security is quite common nowadays into data. So signals will play a very important role in the future, as well as APIs.
And I think the good thing is when you look at the implementations of software today, then more and more of that is basically, it's a set of microservices which is built, and then a UX is built on top of that. I had a very interesting briefing, a little bit different market segment, but where the vendor said, okay, we have, depending on the personas, we have built factually sort of an admin perspective on the tool, but we have also built an MSP version of it, which organizes very differently because the MSP looks at it in a different way per tenant than the end user looks at.
So this will enable us to do things better, to decouple UX from functionality and orchestrate it. This will be important. This orchestration piece is something which was one of the aspects we moved up in the rating, in the relevance for the rating this year, compared to the previous versions, because we believe that this is a very essential capability.
So APIs, modularity, orchestration are important things to consider. Some of the key findings, I think we really see that identity fabrics are in some sense a paradigm shift. And I think it's also interesting to see, I had a couple of conversations here where end user organizations also said that they are really using this paradigm as something which helps them to build their own identity management strategy, their framework, et cetera.
What is very important is it's not a one, so the paradigm shifts really around this integrated perspective beyond the identity silos into something which is much more seen as an integrated framework, because we also have a lot of capabilities that are relatively similar for different types of identities, for instance. I had another leadership compass I recently published, which was around enterprise secrets management, which also looks at some of the NHI vendors. But what we also hear from the end user organizations is that they say we want to have a governance layer across all identities.
We want to have life cycles that are as integrated as they can be. So we see also this evolution towards we want to have sort of similar, and that would be when I go back to the previous slides, from the support services that are consistent across as many areas as we can. So not having five different governance approaches, but having integrated governance. And I think this is also part of it, which also goes back to the paradigm shift. If that is one size fits all, that's very important. And who of you has been in the workshop yesterday morning on identity fabrics? Quite a number of you.
And I think Philipp and Matthias talked about how to use that also to adapt it to your specific organizations, to your needs. And I think this also aligns with some of the other talks we had here in sessions, et cetera. You can't do everything. This is a journey, and you need to figure out where do you start, where do you go. But it helps you hopefully to have an idea about where they should move. So is it aligned with a shift towards this integrated approach? And we see organizations that focus really more on different tools or on more single platforms.
It can be built on strong platforms for key functions, supplemented by specialized solutions. It could be more individual solutions. In the evaluation, we look at a lot of things.
Clearly, functionality is important, but it's also the architecture, which takes an important role in that. It's the API, the deployment flexibility. Because we see that a lot of organizations, while there's a general trend towards IDaaS, it's not that everyone wants to do everything or can do everything as a service.
And also, the way the service is provided may vary. The requirements may vary here. So we need some flexibility here. Orchestration, I touched already. APIs come to the modern architectural paradigms. All that what I already touched here. So when I look at some of the key capabilities, I don't want to read out all of them. You will have access anyway to the deck. And some of my colleagues said, hey, Martin, you have too much text here and always complain about us having too much text on our slides.
And yes, fair points taken here. But as I said in earlier presentations, in the past, I sometimes had this five-point font size. So I at least got better here. It should be readable also from the back of the room. So we look at support for different identity types, for instance, is a very important thing. We look at support, for instance, for supply chains. So really going beyond the workforce identity. Flexibility in how authentication is done.
And also, how the service is provided. How authentication is done. Some zero trust features. Compliance, support, all that other stuff. So there are quite a number of things we looked at. And we also thought about how could this look like. And at the end of the day, I think this is one of the challenges you have as an analyst with every comparison of a market segment. I think we have a bit of an advantage that we go in many cases in relatively focused market segments, which makes it a bit easier. The identity fabrics clearly is that vendors come in with different approaches into that.
And so we have these more comprehensive solutions, which are a bit more the converged platforms, which in many cases support IGA plus access management, maybe even privileged access management or IGA and privileged access management at least. So then we have the orchestration focused solutions, which really are more coming from the orchestration side of things. Integrating, but having usually not the breadth and depth of functionalities that in all cases. In the ideal world, clearly this comprehensive thing aligns with a strong orchestration sort of backing that would be ideal.
And then we have also some specialized vendors that fill in some interesting sort of gaps in the framework. Clearly some of that come more from a policy-based access control and combining it with orchestration that might be one of the areas or IDP orchestration could be one of the areas where there's one of the vendors in that. So this is the other thing. So when you build your own identity fabric then, there are a couple of things I believe, and that's something I would like to elaborate a bit more on, you should keep in mind.
So from the step, I think the first thing is really also thinking architectural. And I think what we really must do in identity management is also do a good job on what are our architectural requirements. I think many of you may have learned that customization and all the bells and whistles you add to a solution on one hand are important and sometimes fine, but also can lead to an early end of life of the solution when you over-customize it or customize it to death.
So I've seen a lot of solutions and a lot of implementations where just the customer couldn't do the updates anymore because there were so many customizations that failed with any update. And that's the point which you should avoid.
And so, I personally believe everything you do in code must be in a separate microservice, isolated via APIs. That's an absolutely fundamental paradigm for when you need to code for customization, and you should avoid coding. But if you code, then do it right. And by the way, if you do low-code or no-code, think about some simple things like versioning, documentation, et cetera, et cetera. So all the other things, because otherwise, you will end up where all these Lotus Notes users ended with thousands of Lotus Notes databases no one could maintain anymore. That's our big risk.
So I think low-code, no-code will be the next disaster of IT, honestly, because we are not good in doing it. We are really repeating mistakes from the past. And that's also true for all the low-code, no-code stuff here. And if you do pro-codes or coding, then isolate it well. Do it good. Architectural skills are important, and you need to tell your system integrators how to do it properly. They should tell you. But if they don't tell it, tell it to them, because they have to do what you want, and they have to do it good. So do it to them.
And based on that, you need to do it consistently, moving towards the target, but step by step. So it's this balance. You can't do everything at the same time. So you can't say, okay, in the next few years, we'll build our completely new identity fabric. You most likely will fail, because you usually start in something which is not the green field, but something between brown and black field. And you can't do all the projects at the same time. You need to understand what are the services. So thinking about what are the services needs now and in the future. That was the 2040 outlook yesterday.
When we talk about what we are doing now, this will impact what we have in 2040. We need to plan, we need to implant, and it has a long, long lifetime. So what we do is not for now. It's for later. And it must serve what we need now. Back-end service is consistent. Architectural model are headed. Add functionality over time. Orchestration, again, that's something which will help us. And over time, you also can replace components. So if you do that architecture thing right, it will make it much simpler to replace components without breaking everything.
So that's, for instance, why I emphasize this identity API layer that much. Having a consistent API layer and want this your API layer and not the vendor's API layer. And if you change it, you can wrap APIs. You can expose them in a different way. Think about it. That's very important. So in the leadership compass itself, as usual, we have our leaders here. This is the overall leadership, which is product, functionality, market. We have our leaders. We have the challengers. We don't have followers here. For some reason, vendors don't like to be followers.
And we have, somewhat interestingly, as I've said, the market position plays an important role here, as well as innovation as product capabilities. So it also means that in tendency, in this perspective, the larger vendors tend to be more on the right side, due to the market leadership part. What I always say is this is a nice picture, but never, never use an analyst, quadrants, compass, whatever, as the sole foundation for your decision making.
This is, and there's a reason why this is an 80-page or something report, because there's a ton of detail that should help you in understanding who is a better fit for you. Do it thoroughly. Do your own request for information, your own RFI. Look at some of the more exotic quotas vendors, the non-standard vendors. You will learn a lot. Even if you maybe not use them at the end, you will learn from having different types of vendors in your comparison. The other perspective I'd like to give you, this is the product leadership thing. I think one thing is very important to understand.
If you look at this, so this is the size of one of these boxes, and this one is much smaller, what you see here, which means I just, it would go up there to the top, which means none of the vendors is perfect, basically. So there's quite some room left to perfection in product leadership, which means someone that's very close would be, you can see how big the box is, someone would be at the top of the other box. So it's still some way to go for the vendors.
And we see some, I would say some expected vendors here, but we also see that there's quite a number of other vendors coming up with sometimes very good things. And then there are some very interesting specialized vendors further down there, which really provide alternative approaches, which, and again, look also at these, if you go into these selections, read through the entire report, understand why we say this vendor might be really interesting for a certain type of use case. This is what really will help you. So that's it in a nutshell. You'll find the report online.
If you have the membership, you anyway will get way more access to all the old videos and research and analysts, et cetera. Don't miss it. And if you're still not connected with me on LinkedIn, that's here. Thank you.
Thank you, Martin, for bringing all this information about this massive thing in this 20 minute talk. And I think you could ask, talk for hours about it, right? I'm pretty sure about this. I think before we come to the next talk, time is pressing. I think we have time maybe for one question. Someone here from the... Yeah. Thank you for the presentation. One question about the identity fabric. It seems to be interesting and quite generic. So the question is maybe, do you think it's useful to make it, to have some special versions for specific sectors like financial sector, identity fabric?
Something we are working on. So that is on our list of things to do. To also go into more sector specific sort of blueprints, because that clearly will help sectors to do that. Our advisory team, together with the analyst team, has this on the list of things to do. Thank you.
