Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. I'm an analyst and advisor at KuppingerCole Analysts. My guest today is Martin Kuppinger. He is the principal analyst here at KuppingerCole.
Hi, Martin. Hi, Matthias. Pleasure to be back in the podcast. Great to have you. It's been a while. And last time there was some heavy feedback when we talked about iVIP. We will not necessarily follow up on that. Maybe some details, but it is part of the bigger picture.
Today, we want to talk about identity fabrics for the future. And you've just written a blog post with the main theme, the identity fabric for 2040, 15 years from now. Why is this a realistic horizon for identity architectures that one should be aiming at when they start right now? The equation I tend to show when I do it in a presentation is 2025 plus 2 plus 3 plus 10 is 2040. Why? We are in 2025. If you start a large IAM project, you may spend two years in planning, budgeting, et cetera, et cetera. You may have an implementation time that also takes a while depending on what you do.
Sometimes it's faster, sometimes it's longer. But three years are not unusual until you're really done. Sometimes it takes even longer if you take some of the IGA projects. And then 10 years lifetime is also not uncommon. We've seen IAM implementations that are north of 20 years now, and then we are in 2040. So it simply means what you do today has an impact for 10, 15, and more years from now. So we should think about what can we already predict about potential changes, expected changes, and what should we keep in mind there? And this is, I think, why we're thinking about 2040.
And that leads to looking at certain trends on one hand. And you brought up IWIB. And then I think a concern, when we start with the Identity Fabric, concern back from these days comes up again. And that is the point why I think I'll touch IWIB. So identity, visibility, and intelligence platforms. Platforms is such a big term.
Anyway, I'll touch it. But I think there's a reason to bring these things together. Right. And as you said, so we are considering the Identity Fabric as an identity infrastructure that provides a portfolio of services. So we're not necessarily thinking in tools. We're not necessarily thinking in products or vendors. We're talking in providing services and an infrastructure that serves an organization at the individual point in time.
And as you said, so there are many different capabilities around, and these are implemented by tools, which leads to tool sprawl, maybe even a capability sprawl and duplication of capabilities. I think that is one of the aspects that you look into when you look at 2040 and beyond, right?
Yeah, it's one of the aspects. And when we go back to the early days of the Identity Fabric, so when we started with the Identity Fabric and created this paradigm, which in that sense could be interpreted as the platform of your identity services, if you want to use the term platform, an important element or aspect then was we saw established workforce identity management. We saw consumer identity management emerging. We saw B2B identity management emerging, et cetera.
And when we stepped back, we thought about, does it make sense to have a separate identity management for every use case, because this would lead to sprawl, and that was why we brought up this idea of the Identity Fabric to think about which are the capabilities you need? How do you combine them into services? Which tools do you need to also, on one hand, integrate what you have and what you do, and on the other hand, to reduce, in fact, the tools sprawl as much as you can, because this was something which was there also almost a decade ago or so when we started with the Identity Fabric.
And I feel that currently we're in a situation where it comes back. Yesterday, I read a comment on a LinkedIn post where someone said, oh, iWIP is forgotten for what it is. And ISPM adds to that with that and that.
Oh, ITDR was not even mentioned there. IGIA wasn't really mentioned. And even when I just take some of the new things, so we have NHI management and various facets now. We have Identity Visibility and Intelligence Platforms, iWIP. We have ITDR, Identity Threat Detection and Response. We have Keen Cloud Infrastructure Entitlement Management, which better would be called NHA for non-human access. We have ISPM, whatever it is. I can't explain the acronym.
Anyway, so we have a lot of emerging tools that provide a certain capability or set of capabilities. And I see this risk that we end up with a zoo of tools and the lack of integration and the Identity Fabric. So Fabric can be something that produces services, which is an important element of what Identity Fabric must do. But Fabric also has this notion of a mesh. And this mesh, I think, is an important aspect of the Identity Fabric we should look at in these days very, very thoroughly and intense, because that is probably what we need.
And then the mesh thing will bring us to another theme I talked about when I talked about the Identity Fabric for the 2040s, which are signals. I think there's a reason to think about, and absolutely there are capabilities, new capabilities emerging that fill gaps. The big question is, how do we deal with that to have something consistent, coherent, integrated at the end and not many, many tools? I think we were good in having too many tools, cybersecurity. Every user can speak about that, having too many tools out there. Let's avoid it for identity. Exactly.
And you've mentioned it already that actually the Identity Fabric should be the platform, and you have this term also in your recent publications when it says platformization. So that is really transferring your overall capability landscape into a single mesh-like platform, which allows for coexistence, which allows for migration, transparent change, transparent upgrades. So that would be also the trend that you would see for an Identity Fabric for the future so that it evolves over time.
I talked about this during my opening keynote this year at the European Identity Conference in Berlin, where I brought up this idea of we have basically an orchestrated platform, not just an orchestration platform. So this is what does the orchestration, but the result orchestrated. This gives the room to use specialized solutions for certain capabilities that are lacking, but in an integrated manner, together with things you have or broader, large platforms that deliver a lot of services.
So I think very importantly, my thinking is there are customers that like to have a strong platform that covers a lot of things, or they can maybe also do that because they are just opted for a certain vendor relatively early, or they migrated to a certain vendor's portfolio over time. And there are customers that have more different elements, but at the end, we need to bring it together and we have the means nowadays. We see more and more orchestration platforms also in the identity space that help orchestrate everything.
Most of the tools are API first, or at least expose a very broad set of APIs which help in orchestration. They can exchange signals. We can consume signals. We saw all the emerging signal standards like shared signal frameworks, CAP, Continuous Access Evaluation Protocol, and RISC-RESC emerging and really being finalized just in the last couple of weeks and months. So we have a lot of things on hand together with all the modern architectures running things, having microservices running in containerized environments, all the flexibility we need to build an integrated set of solutions.
I think this is what we should look for. So there's an absolute value of new capabilities which tend to come as specialized solutions, which means there's a reason why we see all these terms and market segments pop up. But strategically, we need to think about how do we bring it together? How do we create the ability also to exchange them when especially emerging markets tend to look different five years from now with all the evolution happening in the market? So how can we remain flexible?
And this brings us to an orchestration, API first, signal-based integration syncing, where maybe for some customer, 80% of the capabilities come from single vendors tools. For the others, they have a lot of different vendors, but you still integrate. You even can integrate at UI level. It's interesting to see that a lot of vendors nowadays really build their API first platform and then they build the UX. I've even seen vendors that have different UXs for different use cases, so an MSP UX versus an end-user experience.
And that means also we as an organization or the customers, we can potentially build a better integration layer more easily nowadays based on all these capabilities. I think this is what we really should think about, that we on one hand understand, yes, which capabilities we need. This is where the Identity Fabric and the Reference Architecture help to understand, what is it what we need? What do we have already? Not everything in iWeb is new. Not everything in other technologies is new. So what do we have? What do we need?
And how do we put this into our ecosystem to have something which fits well into this fabric instead of ending up with a ton of silos and isolated tools, etc. This doesn't make sense. Right. But that's unravelled. You've mentioned three terms. So that was orchestration, that was API first, that was signals, and you did not even mention the A word, artificial intelligence or generative AI, which would be a fourth trend. So all these trends would also contribute to changing capabilities, functionalities over time, and maybe even benefiting the end user, the organization, compliance, security.
So let's start with one aspect. I really want to learn more about what you think signals are, to explain it to our audience, but also where the benefits are for using a rich set of signals to use for authentication authorization? Beyond that. So I think that signals are frequently seen in the authentication space nowadays, but I think they are much bigger. So a signal basically is a real-time information that is sent from one system to another. That could be an information about the authentication status, the authentication strengths, the context. It could come from the endpoint.
It could come from an authentication system. It could come from a fraud intelligence platform providing additional feedback. It also can be, could be information about anomalies, about outliers that are based on historical data. So on our behavioral data, etc. So it can be a lot of different things and it can be sent. It makes sense to use signals in authentication and in authorization. So what is the context? This is the device Martin is using usually. Signals are more, we exchange them clearly to the XCR world, to our various types of cybersecurity systems.
But when we envision moving towards a world where we lesser rely on setting entitlements, we can also use signals to provide information about what is probably the entitlement Martin will need now. You need to move towards something like a just-in-time provisioning. Signals could also be stuff that comes from your Outlook calendar, which will say, okay, Martin is on travel. We handle him differently or Martin will have this thing to do next. There's a lot what can be done. And the signal thing is, I think, a very, very important element for everything around handling risk, sharing information.
We see also in the broader cybersecurity space, we see a tendency to at least complement, sometimes even shift from a scene as a static sort of amalgamation of data and a huge database towards security data or security telemetry pipelines, which basically transport this information at runtime. For everything around identity threat detection response, clearly signals are a very essential element.
Again, ITDR also issuing signals to other systems saying, okay, be careful here, deepfake detection will issue signals saying, okay, here's a risk signal, this looks whatever. Some things of Matthias' video look a little bit weird. Speech to lip movement is not synchronized as usual or whatever else. And then I would maybe get a little alert in my, in this case, Riverside window saying this might not be the real Matthias, all based on signals. Right. I sent my agent to do this moderation today.
So that's, that's true. Yeah. I already wondered a little bit about the questions you've asked. Right. I really made sense. But the question is really, how does this improve also the user experience? You've mentioned authentication. So using more signals to strengthen the decision-making process when it comes to authentication also continuously, but also to getting to some kind of AI augmented multi-signal authorization process, as you said, that is context dependent. So this is, this is one trend that you anticipate for 2040.
I think we will see way more signal exchange between different solutions and more things. We have already a ton of signals on hand. I think on another occasion, I recently talked about potentially moving to more passive authentication also where we really don't log in anymore because we have so many signals. And I think it's very worth when we talk about signals to look at things like Bayesian mathematics or vector algebra. So in vector algebra, you can envision a signal as a, as a small vector.
Some of them might be better, some weaker, but if you have many, many vectors you combine, you end up with a very strong vector, very strong signal. So a ton of small, relatively weak signals, if they are pointing in the same direction, can lead to a very strong signal. By the way, if they're not pointing in the same direction, it's also a very important information you derive from that. So I think this is an interesting field to look at. Right. So we've talked about the signal part.
The second part that I want to also end this discussion is really the platform aspects or the platformization, how to do this properly. We talked a lot about the identity fabric and the reference architecture, but giving good guidance for organizations that want to move to this mesh, to this platform approach, what would be your recommendations how to gradually move to a platform approach that really is worth the word platform? So what would be a good starting point?
Yeah, the cynic in me first would say the current discussion about platformization is just a revamped suite versus best of breeds discussion, which we have been running for the last more than two decades in our world. I think we should look at this platform thing from the customer perspective, not from the vendor perspective first.
So what must be our target is from a customer perspective, from an end-user organization perspective, to have an integrated, as much as we can, set of services that delivers the capabilities we need and what helps us doing this integration and that sense of the platform. And this is where orchestration comes in, where centralized authorization services come in, where centralized AI services come in and some other centralized services. So I think the identity craft, the relationship handling of entities and their access, also is sort of a platform service.
And then we have functional services that base on that. And in that sense, the result is a platform. Whether we do that, as I've said, based on very few, very large and comprehensive tools or more in a mix of different tools, it doesn't matter for the smash approach, you can do both, especially when the larger platforms are also API first, are sort of speak Microsoft, when you also can handle them.
In fact, as a set of capabilities and services, integrate them, orchestrate them, et cetera, when this is the case, we can fill it with what we either have or where we say, okay, there's a huge gap we need to fill now. And it makes sense to fill it that way, to integrate it, et cetera, instead of just saying, oh, there's a new tool, let's add this tool to our portfolio of tools we anyway have lost control about. So the platform, and this is the Fabric thing, helps really to bring these things together, to measure, to orchestrate it. And then this is the platform.
And whether you then say I go for a larger platform of a vendor or have various different tools, I think that depends on a ton of different factors from your history and legacy to your preference for sweet versus best of greed, the mood of your CIO saying, come on, let's do everything with vendor A or B now, all these things come together and impact how you do it and based on what you do it.
But most importantly is, and I think this is a learning we should really have from not only from identity management, from many, many other areas, start with your outcome, your expected and your planned outcome, your perspective of how should this look like, your Fabric, and then think about what does it need to fill it? Not the other way around, not just throw a tool on a problem you're facing. Always think about what is causing the problem and is there something you also need to do on the organizational side, on the process side, whatever, so that this next tool really delivers to value.
And bring us back by way to visibility. If you just have visibility, you may not have achieved much. It may be just, okay, I have another tool because at the end, only if you can achieve better results, easier, bring us to observability from that visibility, then you potentially make progress, but then still you need to process, you need to people, you need everything. Right.
So it's not necessarily the purchasing decision that you made, but it's the glue that is shared signals, shared policies, shared capabilities that together provide the services, this outcome driven design approach that you have just mentioned. And then it's really not really important to which kind of product approach you actually chosen. And it's reflected also in our research. When you say we have these specialized leadership compasses, which do access management, IGA, and we have the Identity Fabric leadership compass, which looks at the bigger platforms.
So the market provides you with both. The question is, what do you want from this platform? So this outcome driven approach, I think this is where it all starts and where we as advisors starts, it's requirements engineering, right? And I'm absolutely confident you never will have one single tool when you're a larger organization for everything in identity management, because you have a legacy, you have changed and you see all the innovation popping up, which adds to it where you say, okay, I need to do it.
But if you do it, think about it first and do it in a well-planned manner, starting with the capability and the services, then add the tools and ensure that you have the right organization, the right processes, the right people in place to really make value out of it. Absolutely. And I think the only change that I really anticipate is that the iterations will be much faster. So there will be more change over time so that we are, you've mentioned that and I've mentioned that in my opening keynote at IFID in Munich, we need to provide IAM at the speed of the business.
And that often requires not having a 13 month IAM upgrade program, but maybe a change every two days as an idea for the future. And that is something that the identity fabric and the reference architecture actually can allow for when done properly and when you reduce complexity for one update. And I think my, whatever, 35 years in identity management or so, they have definitely shown one thing. Always when you say, oh, it's going more into a stable and mature state. You're wrong. A ton of innovations pop up and change everything.
And to be very clear, all of these things, be it IOIP, ITDR, ISPM, et cetera, they deliver value by addressing capability gaps. The question is only how do we bring it and integrate it into a bigger picture so that we do it strategically and as tool-driven. Absolutely. And I'll leave it with that. Thank you very much for these final closing words, Martin. There is much more to unpack here and we will do that in later episodes.
Of course, because we just scratched the surface, to be honest. But this is great because there's so much more to do for this. If you have any questions, if you have any comments, if you contradict massively, please reach out to us, quote us on LinkedIn, leave a comment below this video on YouTube or just drop us a mail. We are available and we are happy to receive your feedback. There will be an event at the beginning of November in Frankfurt, the Identity-Centric Security Impact Day. That is something that we are looking forward to as well.
So join us there in a more cozy atmosphere and to talk about real-life experiences by those who actually do it, so practitioners. And we are also looking already at EIC in Berlin again. So there's a lot of possibility to talk about these topics and to follow up. But Martin, we will talk soon again about more of signals, orchestration, platforms and sharing signals. Thank you very much, Martin, for being my guest. Thank you.
