IAM 2025: Integrated, Agile, Flexible. Decentralized?

Thank you. Thank you, Matthias and welcome everyone to this session.

It's, it's one of these sessions, which is, has it pro in this concept for an Analyst talking about a future, which is part of what Analyst tend to do. On the other hand, you, you always can fail. And I also tried to, so it's 20, 25.

So, so if it were 2030, I could talk about everything and say, this probably will happen in 2030 for 2025. A lot of things are under their way already. So I think it's a little bit closer to reality and to what we can do. And some of the things which I have on my list, here are things you can do today. A lot of things are things you can do today, but you should have done by 20, 25. Let's phrase it that way. So that will be my, my, my focus for today.

And in the interest of time, I'll, I'll speed up things already, a little given that I only have 30 minutes and I have 12 topics to cover, which gives me with the intro and out for less than two and a half minutes per topic. So stay concentrated and focused here. The first thing is comprehensive. I believe that we must move to a focus that is broader in identity management, even broader than the three core domains, IGA identity governance administration. So use lifecycle management, provisioning and governance and privilege access management and the access management Federation piece.

So this is just the picture of our IM referent architecture, where we trust recently released an updated, updated version, which mainly have been created by Matthias and some of the colleagues, but with the, the, the central role identity management has in organizations beyond human identities. I think this is also very important, but I'll touch this later on.

We, we need to, to think about what all to include into this area and this start with very baseline things. So one of the discussions I have quite frequently is organizations is to whom belongs directory. And I have a very simple answer. It must be part of the identity management responsibility. You might discuss it for the old ad, but you can't discuss it anymore for ad. If ad is not part of your identity management responsibility, then something is wrong. Full stop. Not everyone in the organization feel like this statement by the way, but I'm happy to explain further in your organization.

So we need to think bigger. We also need to think multicloud multi hybrid, because the reality of our, it is multicloud multi hybrid. Most of your organizations probably will have, will utilize multiple cloud providers. And they will have a lot of things somewhere in between on premise and the cloud. And this is here to stay for quite some while. And so think about doing it in that style. I think the strategy for 2025 is having your identity management delivered from the cloud for everywhere. So by default, it runs on the cloud, but it's also able to run somewhere else.

It can run on the edge, it can run hybrid, it can run in some distributed manner. It says delivered as a service and it's operated as a service. And what you need is something which is a well defined target operating model, who is responsible for what? This is something you need to work on. You have in a multi-cloud multi hybrid environment, your challenges, you have cloud providers, you have to manage service providers, your partners who do something, and you have your own teams define who is responsible for what define it clearly or will fail.

And it's also ready for infrastructure as a service. It's the other part of the cloud. So whom of you has a real cry. You don't need to raise hands has a real on all the service accounts in your infrastructure, as a service and their access to cloud resources. It's a challenge. You need to address this for all the targets from SaaS to legacy. So we need to think really multi-cloud multi hybrid. And this must be our focus on solutions.

Yes, surely some of you are born in the cloud as an organization and live in the cloud, but most organizations are the bigger and the older they are. They don't. And you know, I remember customers, which in a project said, oh, by the way, we need to do it because 2023 will shut down our main data center. And then a couple of weeks later in the project, they said, oh, by the way, it has been postponed to 20, 26 and another.

Yeah, few months later they said, okay, so most likely most will be shifted away by 2030, but we probably still have this data center. And I think this is just a reality and we need to look at all identities. And I think this is one of the major trends to think identity, not in the sense of identity equals human, which is still for a lot of solutions. For a lot of things we are doing for a lot of organizations. It's identity equals humans. It is more, we need to think beyond that it's consumers, it's customers.

This is an extract part of our identity fabrics, graphic it's partners, workforce services, devices, things think about all the stuff, which is in your OT environment. If you're a manufacturing organization, sensors, act traders, all that stuff.

And yes, there's workforce identity management, but workforce identity management, convergence in some way with partner identities and Alliance with customer consumer, we need to think bigger every and everyone and everything at the end of the day, the challenge is the same. It's everyone and everything need access. And we need to get a control of about access. We need to enable seamless access secure, but it's not that this is a totally different thing.

If a service account needs access to a resource, it's about, I think at the same, the same problem, the same challenge, like when Ellen needs access to a SharePoint server, for instance, but we need to think beyond that, we need to think beyond trust the workforce, the human perspective and, and, and understand that there are a lot of similarities and don't end up, don't end up by 2025 with having workforce identity management partner, identity management, customer identity management, OT, identity management, some for your software, robots, and other things.

If you have a lot of identity, you might have a couple of different tools for different purposes, serving different capabilities, but start with one perspective on that will be part of our discussion. Later on API first, we are used to have identity management tools that manage other systems. So we create accounts in active directory and SAPs at etcetera. And I think we need to add not to reverse add something. That's why I say not trust manage.

Yes, we will still need this management capabilities. This from an, from an identity management perspective, it isn't from identity management inside out to the applications. We also need the outside in an application of digital service, asking identity management about something like authenticate. This user also indicate a thing for me also indicate authorizes, do that, do that. This is something we need to do by by APIs.

And by the way, we, we can, can gather a lot of benefits and, and, and bring identity management much closer to the digital business, because that is when we have a good set of a good identity API layer. We are delivering time to value for digital services. We are speeding up development because a service can trust, consume identity unified us as well. We make things way simpler and all the things like customization extension orchestration also become more easy.

Probably a couple of you had in the past the one other issue and saying, okay, I want to upgrade my identity management tool, X firm release four to release five or from even because I left out release five, I want to move from release four to release seven or something like that. And then you say, okay, it doesn't work really because all my customizations will fail. I'll spend the next year trust in, in renewing customizations. If you work through APIs and the APIs are stable, then you get rid of this challenge. If you do it right, you can do it wrong, but you can do it right.

You have the option to do it, right. And, and you should think that way. Think about API first. This is from my perspective, really, as a very essential thing, which also means at the end, I'll touch this again, that your identity management must be able to expose APIs, which means it must have a modern architecture. It should be microservices, container based deployments or stuff like that, which gives you a lot of flexibility, but think in two directions. And we see a strong uptake here. When we look at what, what is happening these days around authorization.

So there's for instance, this standard OPA open policy agent and the, the, the Regal language around that, which is heavily used by developers these days, because they all say, okay, I can, can have a policy based authorization for my digital services. They laugh it because they exactly understand this makes me better. And this is where you can deliver the service. And this is where you get better as I've touched it, modular microservices. Yes.

We, we need to understand that it's not about big fat monolithic tools anymore. It's about servicing capabilities, a modern architecture that enables the flexible deployment. And that enables us also to put together things also from different vendors into a unified service. So at the end, it starts at the core. And one of the questions I ask to every vendor is about architecture. Sometimes like clear answers frequently. I still get, I would dare to say fussy answers.

And, and sometimes it is that one answer is, oh, yes, all microservices. And then you ask and, and which part of your capabilities are exposed? Why are APIs rest APIs or so, and then they say, oh, maybe 85% and then say, okay, one of the answers might be another a hundred percent correct. So ask the right questions surely helps here. And we need to think towards this because there's no single tool which help, which solves everything. There's not even a single vendor, which will fulfill all the requirements you have in your typical, at least your enterprise level, large enterprise environments.

And you need to bring things together and you need to work with APIs, with standards and other things. It needs to be flexible. I would be glad if I could do that in my yoga class, but, but I think that this is something which is a little unfair to men, usually because I, I believe women have more tri and here to do that than men. At least when I look at my yoga class all the time, man staff are here. More flexibility is key to success. So it enables us to, to get flexible and we need to bring, this is a little bit repetitive.

I, I agree. We need to bring together a couple of things here, which is the modular architecture I already touched. Builder. Microservice is allowing us to orchestrate, allowing us to integrate it's. The API first approach was the set of APIs, that identity API layer and delivering identity. Then it's the standards. I quickly touched this. The standards part, I think the good use is we see more and more standards and we see standards evolving, getting better.

They are always things which, which can pop up in and also customer projects where we, we didn't learn, okay, there's something missing or there's something not yet a hundred percent there. So, so whatever fi leading a lot of things open, and yes, you could do that that way. Instead of saying, you must do it that way, causes friction over time, but that is changing. This is the walling we see.

Also, as I've said, in other areas down to authorization, we see standards because it helps us to integrate. It helps us to get better across all the domains of identity management. And the other thing is workflows. So the ones of, of, of you, you who have been involved in it projects particularly, so use life cycle management and that stuff have their experience with the build in workflow capabilities of IGA solutions.

And what we currently see is really a, a fundamental shift to something which has had been there a little, maybe some 15 or more years ago, where some vendors said, okay, I, you can use an external workflow system, or I, I trust user external workflow system for creating these workflows that has really changed a little since then, where, where all the workflows were really focused on this specific IGAs.

And what we have seen from several vendors in the last one or two years is coming up with way more capable, call it workflow called orchestration capabilities, following a low-code or low-code approach, allowing to consume APIs or to, to work against APIs from a variety of systems. Well, beyond the identity management scope. So surely it service management and other things, but adding these capabilities of saying, I can integrate way more systems, way more or way simpler than, than, than I ever have been able to do.

So we see definitely a, a, a paradigm shift in the way workflows are constructed and allow us to integrate either from identity management, with other systems of, of identity management, into other systems. This is I believe something which is very important also for the future.

And I, I'm very convinced that this, this strength will continue over the next couple of years, that that it's about integrated and integrable. If the letter were, is really correct, but, but the ability to integrate it, I always have limited space here for, for these things, if I want to use these big passwords.

So, so what is it about, it goes back to this also topic of our upcoming panel, this identity fabric thing. We've coin the term a couple of years ago, I think some three years or so four years ago already, and, and talked a lot about that.

And there, there are different aspects around that with integrated. I don't mean, I think that something which is clear from what I've said previously, you don't mean that you have one big mono thing. I have something where you say, this is my, my identity fabric. And for me, it's, it's something which so fabric is a, a term with two meanings, the mesh and the production. And it's something which, which brings together services in a unified architecture unified perspective and delivers services.

The way you need it, scale with story cloud capabilities, cetera, but it also needs to integrate, like integrate with it, service management. There are different concepts for doing that. When you look at the vendor landscape, it integrates why our workflows are already touched this modern workflows, the APIs and this fabric aspect.

So, but going back to the first thing I talked about this aspect of being, being comprehensive, this is, I, I believe very, very close to, to this fabric thing. So really saying, okay, I, I try not only to, to solve one problem, and then the next problem, but I, I at least want to have a big picture, understand which capabilities I need, how I group them into services, what I have in tools, what I need, where are my gaps?

How do I deliver doing this as, as a, as an, an exercise, because it helps them to, to understand how these things cry together, where you have redundancy, where you can use what you have, where you do need, where you need something different. And clearly it's not about a single tool, but it's also about them saying, I have an architecture that allows me to integrate with the outer space, with everything. Like I said, the identity API layer, what else?

Oh, yes. Right now it starts getting interesting or really interesting. I hope so. At least I, I believe in that policy based, yes, I have a lot of talks with vendors and I think there's, there's a lot of meaningful innovation around how can you better deal with roles and recertification. But I think it's also very important to think about how can we do it the next step. And I believe policies help us a lot. The good thing with policies, everyone understands policies.

Policy is easy to describe because it's always the word subject and an action and an object, and maybe a constraint and policies look the same. And yesterday tried was fun from our cm.

I said, Hey, you know, can, can you describe so to speak policies for sales? And then it's very clear, whatever. Only the sales people are allowed to see certain information in an offer. That's a policy sales, see information offer to object, very simple. Then I said, okay, could, could you also give me the, the, the business roles we need for sales? And then you see the, the, the big eyes, so to speak, no clue about it, because business roles are an artifact. Artificial, not logical, not really. So we need to think policy based because they help us to do a lot of things much better.

They're not new. We have, we had, Xam allowed, there, there are.

And parts, firewall rules are nothing else than that, but we need to UN Wiel the potential I believe. And there's so much in policies. We can do better roles and lesser re-certification. If you trust need to re-certify policies, instead of all, the entitlements life gets much easier because people also understand policies, but they don't understand technical entitlements.

We need, we can automate steady entitlements. If we have a policy with a little, little bit of work from the vendors, we can derive a lot of static entitlements automatically from that. If you derive them automatically, we don't need to re-certify them. We just need to re-certify the policy life gets easier. And I don't know, a single organization globally out there, which says, Hey, my departmental managers are waiting for the next re-certification cycle because that's their biggest fund in their life.

No, it never happens. Adaptive authentication is policy based. We do it already. Dynamic authorization is policy based. And when you look at zero trust, the core of zero trust, there is, there are policies.

We, we, we can have a long discussion that would be out of, out of the scope of this session, whether this, this focus of a, on a central policy system needs zero trust. Isn't exactly the opposite of zero trust because you create a single point of attack. I think it heavily depends on implementation and a couple of, couple of other things, but it's, that's an interesting discussion out of outside of this conversation.

Anyway, it's authorization focused. So most of us, in some ways, stop with authentication today and also indication we are quite good.

We, we are not bad in authenticating users, also doing risk and context based, adaptive authentication, cetera for authorization. We, we, we say, okay, you you're through you're authenticated. And right now we trust you, okay. Nothing to do with zero trust at all. Or we say, okay, we have to static entitlements. And you have this cover is token, and there are the IDs. And then we compare this, and this is the authorization that happens. But I think we, we, we it's, it's an underserved area of identity and access management is authorization.

We need to, to focus more on that, to get more, to do more policy based dynamic authorization, which we can do well in two places, the one places we can do it well for everything we create new. So if you create digital services without externalizing your authorization to a why, an identity API layer to your identity management re system, then you do something wrong in creating your digital services. Would you make your life much easier over time to do it differently and, and very, very quickly would would help you. But it's also on gateways. You can do it quite well.

It's hard for all the legacy stuff, the legacy applications. Sure. So it's journey, it's a cornerstone of necess zero trust and yes, we have to look more at authorization. Interesting thing is we, we see really an uptake and, and growing interest in authorization. Also several acquisitions in that field, which always are signal of, okay, there's something going on, the experience and that what we really see is that authorization is, is speeding up first at the level of digital services, new types of applications and the infrastructure of service infrastructure as a service field.

And then it probably will move up the stack. This is what, what starts to happen here. It should be trust in time. And I'm still on time. Yes. Matthias is painting always here saying five minutes, eight minutes, etcetera. That's why I always look to Ellen so that I don't see Matthias here and I can run over time. Trust the time. Yes.

You know, I think we can phrase it. Very simple. Static entitlements, standing privileges are bad, full stop. They trust cause problems.

They, they are hard to manage. They are hard to re-certify no one understands them. They get totally out, out of control and explode into numbers. We need to get rid of it. And the good thing is, if we say, okay, this is trust and time your access and the access goes away. Not easy to do in all use cases. I clearly admit it would be a very long conversation we could have here. Then. It's the good thing is if there is no entitlement, then no attacker can use entitlement because you definitely mitigate security risks. If you don't have to study entitlements.

So it's, it's saying you send a request and their authorization system does it, or even a, a provisioning system, maybe provisions and de provisions entitlements that could be bad trust working on the mapping between something like saying, okay, I, I put you in role. I remove you under roll, easier than integrate all the entitlements and target. There are things in between or what we see in privilege. Access management are more and more ephemeral certificates. So short lift certificates for me as a non-native speaker.

This was one of these terms, ephemeral certificates, where I had to look up first. Oh, what does it mean? It was like the, the hive in active directory or so things like where you look up and say, Hey, okay, what does it really mean?

Anyway, we need to get better here. We need to be broad and deep. I think this is also important that we see in convergence of these. I call it application risk management.

So the, the, the access management for line of business applications with IGA tools, because we need to look at where do we need? How can we do it? But overall, there's a clear tendency to work convergence, where we have both the breath across all the systems and the death for serving systems like the landscape others.

Well, and so this is, this is definitely a tendency in this market. And finally, this isn't less and reusable. We need to give control back to the, I think we can have a lot of benefits here. So you have a workforce identity. Does this easy to use with a partner, even simple then with, with a standard Federation onboarding partners. If they come up with a, with a trust versus identity is way simpler. Look at how many time and effort is spent on, on, on partner identities. Freely.

I remember queuing at, at one company than early in the morning because they, they focus more on the, the, the people working in the factory. And then you spend three hours to get a, a batch or things like that. We can't do it better.

It's a, it's a new that's familiar world. And there's a lot of decentralized technology. And this is nothing which is disruptive. It's just maybe in some way you could say it's just another authenticator. It's just another thing you can add to what you have one way to come in to onboard people better to authenticate people better. This is a clear option. So you have one user which has his or her identity. It's a strong proof, which is reusable and easy to integrate. And this is what we already have. We are here with that.

We can use these technologies integrated into what we have and make life of people easier. And for workforce, for partners and consumers, I really, as a, as a consumer, I hated when I have to reregister again and come up with a new username and new password. It's so much 90 eighties. We really need to get better here. That's it from ISAD. Thank you.