Identity Without Intelligence Fails to Deliver Governance

Welcome to our KuppingerCole Analysts webinar, Identity Without Intelligence Fails to Deliver Governance. This webinar is supported by Nexis, and the speakers today are Dr Heiko Klarl, welcome Heiko, who is CEO at Nexis, and me, Martin Kuppinger, I am Principal Analyst at KuppingerCole Analysts. Before we go into the details of what we will cover, which is visibility inside intelligence and enforcing, so to speak, real governance, so delivering to what we need.

Before we go into these details, I want to do a little bit of housekeeping first, and then look at the agenda before we then dive into the subject of today. Housekeeping, very briefly, audio control, nothing to do from your end, you're muted centrally. We will run two polls during the webinar, three polls, actually, because there will be one at the end that is about your satisfaction with the webinar. And then there will be a Q&A session, which is a bit longer, where you have a bit more opportunity. I'll touch this when I look at the agenda this time.

But you can enter, and this is, I think, very important, you can enter questions at any time in the questions section of Livestorm, which you will find at the lower right edge of the screen. There's an area of questions, there's an area of polls and chat. And if you go to questions, you can enter questions whenever they come to your mind. We are recording the webinar, and we'll make available the recording as well as the presentation text pretty short-term, usually tomorrow, so that you can download them.

The agenda today is split into four parts, which is a bit different to many of our other webinars. So we will have two relatively short presentations. I will look at identity and intelligence, visibility, and observability. Then Heiko will look at automation and intelligence for enhanced governance and how to sort of bring this to life. And then we will move into a fireside chat. So Heiko and me will exchange our perspectives, our opinions, and end with a Q&A. But as I've said, the Q&A is a bit more flexible today, so you can at any time enter your questions.

And when there are questions that fit well into the flow of our conversation, then feel free to ask your question, and we will pick it up whenever it fits, either during the fireside chat or afterwards. With that, I want to move to my first poll, and then directly jump into my part of the content. And the question is, it's a pretty long question, I have to admit. Maybe I should have thrown a bit of AI on the question to shorten it in length, make it more concise.

But do you have a single place where you can gather all insights about the current state of identities and access across all the types of identities and applications? So do you have something where you can see the status and those anomalies of identities and the access they have for humans, for non-humans, for whatever your Active Directory and your SAP and other types of applications?

Yes, it's the one option, partially for workforce identities. So something integrated, which is focused on workforce, and that part of the human identity is less than the other types.

Or no, these are the three options. Looking forward to your responses. The poll is open. You can enter your responses at any time, and we will leave the poll open for a bit. And to start with, I think it's really surprising when we look at what a lot of the LinkedIn discussions of the past couple of weeks, I would rather say that there is a new kid on the block.

So IWIP, a term that was brought up by another analyst firm which is renowned for creating such terms, which is Identity, Visibility, and Intelligence Platforms. And what I want to look at is, is visibility sufficient or do we need more? It would be observability, and I'll discuss the terminology also soon. And I think the other question that this term raised to me is, is this the platform or is it more an element with an identity fabric?

And when I look at the identity fabric picture we have developed at Kubernetes Core Analysts, I think we brought up the new version early in 2025, but the roots are going back seven, eight years, at least now. In this identity fabric, we have an area that's about analytics and audit. So that's in for long.

So there's access governance, there's access analytics, which you also may name intelligence, there's user behavior analytics, or you also could say this is, you also have ITDR further below, but at the end user behavior analytics and ITDR, they're blurring lines between these two types of technologies. I think the tendency is clearly to call everything ITDR. There's application risk management, which looks more at the analytics side for line of business applications such as SAP. So it is in there. And we also could simply say, basically analytics and audit is in that sense, IWIP.

Maybe with a bit of change. So I think one of the elements we very commonly see, but not mandatorily in every solution, are identity access graphs. And I think at least from a technology perspective, there's a good logic in it. And maybe this is an interesting topic to discuss with Heiko later on, because graphs allow you to handle identity relationships and the relationships of identities to access entitlements and to applications, all that stuff, and make it more easier to navigate through all that information, this mesh of information than in traditional static structures.

But at the end of the day, it's something which fits quite well into the fabric, which I would say is the platform, which is the bigger thing. And it's an element which brings together sort of different pieces, which could be when we go further to the right in the fabric, which could be a service, the visibility, maybe observability service we have, which is then powered by one or multiple tools.

At the end, this visibility is probably integrative and in that sense, a platform across multiple places where you have insights about entitlements, like when you take your application risk management, deep insights into the world of SAP and other line of business applications and your sort of traditional access governance and access intelligence from the IGA tooling, Identity Governance Administration, then bringing all this together and maybe also from the non-human world, et cetera, clearly makes sense.

But it's also, and I think this is the point which is important, also when we take a perspective on the reference architecture, there's a lot in. So it's not that we start entirely from scratch. What to me is very clear is we need good visibility, absolutely no doubt. It is that we have a lot of places of visibility and there's a strong logic in adding enhanced capabilities, especially when we look at the bottom, the foundational relationship management, the craft aspects, as well as on the other hand, and that's what I'll touch in a minute, the automation aspect.

For me, the thinking is at the end, and this is very important, we probably must think beyond visibility. So visibility, and this is where these technologies can help and there are various challenges. So the identity sprawl and understanding where identity data resides, aggregated data, it's important. Having sort of a seamless data integration almost single place is an advantage, but I want to highlight for now the second line of it, the second row here, which is visibility versus observability.

And what I believe also as experience from history of identity management, and not only for identity management, is we need to think beyond visibility. So visibility means we get a central understanding of identities, their access, potential challenges around them, but this only tells us what is wrong. We need to fix it.

And when we go back to the early days of access governance, when the first solutions for access for certification, et cetera, came now to the market, they allowed organizations to identify challenges they have, to identify SOD conflicts, to identify critical access or entitlement assignments, but that's where they left the customer. And what we need is something which allows the customer to act upon this as automatic as possible. So this automation aspect, I think is important in the context of intelligence. And this is where we come to observability.

So observability means that we not only spot challenges, but we can remediate these challenges. This is where we really then move to an effective governance approach. So what I believe is that automation, that automated reaction remediation are essential. So we must turn data basically and the information about what is happening into actions so that we understand where our challenges and how do we deal with this. And these are certain areas we should look at when we look at IOWIP or however we'd like to call it.

As I've said, it's a bit of an umbrella term for things that are not entirely new, but we need to understand how these things come together. And so I personally believe we better call it IOWIP for identity, visibility and observability. Let's call it platform, I don't care much. Because the key thing we need to achieve is turning visibility into observability via automated reactions. This is where a real governance in the sense of we have effective controls that mitigate risks occurs from. And with that, I already want to hand over to Heiko. Thanks Martin. Welcome everyone.

And thanks for the great introduction, Martin. So basically 100% aligned what my thoughts are on IOWIP or IOWAP. So thanks for setting the scene accordingly to the audience as the IOWIP, IOWAP discussion was kind of wide going on. And especially I like that you really underlined the remediation aspect as to see something and to take a proper reaction immediately afterwards. I think that's something for the fire side chat later on. We can go deeper. Now let's jump into my part of the presentation.

I started some theory telling you a bit about Nexus from a high level perspective but then going deeper into the product and showing a couple of capabilities and impressions that kind of relate basically to the topic of today. Why we need kind of identity with intelligence in order to have successfully delivered governance. Let me start with a first view on the relation between identity access management and governance risk and compliance. And you mentioned some risk aspects earlier on when you have depicted the data on the IOWIP.

I think a very, very strong relationship is there in the market despite it's not yet established at so many, many customers. So when customers are kind of focusing or users focusing on the governance risk and compliance, they are kind of trying to be fulfilling some regulatory compliance requirements or some standards like ISO 2701, TISEX, BSI, Grundschutz or something like that.

It's often that you have a lot of documentation that you define policies, that you define controls but at the end, it's so often just paper or virtual paper documented in wiki systems like Confluence and Word documents or some summaries. And I think a truly relationship between identity and access management and GSE is kind of providing each other's information. So the IM side can provide a lot of information actually back to the GSE as a kind of so-called evidence provider really showing that policies defined from a business level are really implemented in the IM world.

For example, that segregation of duty requirements are implemented, that a certain amount of access refuels is conducted regularly. We can discuss later on what basically access refuels are and how we can shift them up to a new level. And I think that's why it's supportive for everyone to see the whole picture. I am as a part of an overall governance initiative and basically bringing both worlds together.

From an IM perspective, I've tried and I'm continuously refining to put our nexus capabilities into an IWIB capability landscape, so to say, which maps kind of to Coplinger-Cole's identity fabrics as well, where I just put out some aspects that are related to us at nexus. I think, as you said, IWIB is building the umbrella beyond identity and access management. I depicted it in the lower part of the picture. And I think the umbrella is super important. And as you know, and probably a lot of the audience, I was doing a lot of consultancy and professional services in various roles in my past.

And where users and enterprise customers really struggle, they have a variety of tools. And when you read current studies about the CISO's cybersecurity tool stack, it's roughly between 40 and 50 tools, different tools that kind of help a CISO to manage and mitigate cybersecurity risks. And this amount of tools is missing on the one hand integration, but for sure a kind of overall visibility.

And this is why it makes absolutely sense to have someone building the umbrella between IGA and access management, between non-human identities or machine identities, whatever you prefer, privileged access management, AI actions in the future. So this amount of different types of identities and this amount of different tools focusing on different area of identity and access management. And the challenge is it's not a single CISO, like it's so often sold.

There are interdependencies because when you have segregation of duty requirements, you should consider them between IGA and HI and PAN and AI agents. So four systems at least are there. And then you have so many larger enterprise customers that have probably a legacy IGA system and a newer IGA system because the kind of introduction of a new system might take months or even years until it's finally done.

And so our ambition is really to have this overarching layer and creating identity, visibility and intelligence for the business with proper remediation, kind of figuring out something and reacting it on a proper way. Just having a visualization and a list of tickets to solve. It's like an email inbox. It's like a ticket inbox. And I always say there are kind of two kinds of people out there. Those really process those things very quickly, kind of driving the principle of an empty inbox. And the others with an email inbox of 3,472 emails.

When you send them a finding after a visibility, they won't care and they won't be able to process it. And on the other hand, you have those 24-7 risks out there whilst you have probably an 8-5 job. So there is always a big gap in what people are actually able to serve. So we baked in a lot of things that are making the users' life, the business users and the IT users' life easier, whether it's support by AI assistants. It might be something very interesting later on for our fireside chat workflows and outstanding user experience.

So kind of to go away from a pure tech technical and IT tech world and kind of enabling it that a team leader or a manager in an HR department, in a finance department, in a logistics department is really able to make the right decision and to have the right understanding. What is this? What is my team actually allowed to do and what's not? And is this still correct?

Now, let me jump into some visualizations on how we do it. As I said, initially, AI assistants, chatbots, ours is called Nikon Nexus Intelligent Co-Pilot, are super helpful in explaining difficult things to end users and kind of guiding them through the process what's the next recommended action on the one hand and on the other hand, explaining it.

So AI is, I think then especially powerful when it's explainable AI, not just saying, okay, you should remove it or you should approve it. That's okay and it might be helpful. But the question is, why should I do it? I don't understand it. So I don't know the person. I don't know actually the roles behind. Why is this dangerous? And so basically giving them a reason and an explanation to sharpen their understanding will drive better decisions. And basically what we are seeing, and this goes for access reviews, but this goes also for policy reviews.

So at a certain point in time, you have to review something, whether your rules are still up to date or not. You have to support the end users, give them enough background intelligence to make the right conclusions based on those insights, whether those policies, rules or assignments are still okay or not. And having this kind of weave in intelligence with the help of AI is extremely helpful when it's really an explainable AI. So kind of lowering the barrier for end users. On the other hand, visualization is key.

You mentioned the access graphs beforehand that we are kind of using with Nexus as well. I depicted here our very famous and popular identity grid, which is depicting assignments between identities or a selected amount of identities, most of the time filtered by identity attributes, whether it's job function, organizational unit, something like that. And the construct that I'm using, whether it's IT roles, entitlements, business roles. And you can easily see that there are some things that everyone has in common.

For example, the blue boxes, that seems like a birthright rule for all those people in those departments, whilst the orange boxes and the pink boxes are not for everyone, and especially the pink ones are just for one person, which could be either a kind of manager role that would be something to be checked, or it could be a mover or a leaver. So someone who came from another department and has probably some additional roles until he has done all handover activities. So something that should be time restricted and then disappearing in the future automatically.

And I think lowering the barrier for business and end users with an intuitive visualization of those complex authorization landscapes helps enormously. So I really like this grid point point of view. But on the other hand, as you mentioned the graphs, graphs have quite a complexity, so they can show you, allow you to traverse through the graph. If you have a lot of data, it can be a little bit overwhelming for the end user on the other hand.

Segregation of duties is always another challenge I have seen in so many customer conversations on the one hand, so many IGA tools do not implement them well or in a non-technical style so that users are really capable of figuring out who is allowed to do what. What roles, what entitlements are kind of toxic when it comes to requests, to access requests and it's kind of rolling requests to say it already before, hey, dear user, you can't do it. You're currently in a procurement department with a procurement role.

Of course, then you can't have the role for some decision-making entity or so. And depicting this in the matrix is very, very powerful because you get this intuitive overview what roles are kind of conflicting and at a certain point in time, it's always the question, do we have to do recertifications on that as well?

And yes, it's a policy, a segregation of duty policy. And whilst probably the recertification of an exclusion is not that super business critical so it should be there for sure. There is no rule without exception. So there are for sure some exceptions and some whitelisting cause for this. In this case, it is okay to kind of ignore this general policies. And this whitelist and this white spots can be super dangerous because basically it's an exception from the rule. There might be a good cause in a large enterprise and most of the audience know it.

When you have a couple of 10,000 employees or 100K plus, there will be some exceptions as not everything is modeled that super clearly. And if you approve those exceptions, you have to have proper control mechanisms in place to really walk through that. And this might be this kind of recertification of SODs on the other hand. Another aspect, what we have been heavily working on in the last couple of months and shipped it just a few weeks ago is identity security poster management.

Most of those who know Nexus or who have talked to us know our strength in the kind of analytics and access governance side of things. So to figure things out that have changed that have changed over time. And so we can figure out a lot of anomalies and deviation from what does look like in an IGA setup and bring these deviations in a visualization view to the business side or to the responsible users is on the one hand, super important. And on the other hand, those automated remediations, you kind of build them into the observability part is super helpful.

So to see, okay, this person is overprivileged and let's be brave and let's kick it away or at least inform the manager. But if the manager doesn't react for a couple of days, you have an standing risk. So I'm really in favor to be a little bit more aggressive to have a system in place that allows a proper remediation in the sense of removing authorization but having a lower barrier to get it back. So it's only a big trouble if the effort for someone to get back to working or to get back to authorization is really cumbersome.

If that's easy, if that's a seamless and smooth process it's super okay to give it away. Those of you who are probably a little bit older or my age remember back in time when you have been in a hotel you've got the key. So this kind of physical key and some of the receptions ask you to give the key back when you leave the hotel or they have this big kind of thing on the key that doesn't fit into your pockets. And this kind of thing is, it was only annoying if you have to wait for ages.

If there is, if the desk is kind of set 24 seven you just get, oh, I'm Heiko, I'm room 411 please give it to me. And then I got the key and then it's very easy. So if the barriers is low, then it's easy to do. So the last, nearly last slide for today the license killer. So all the ISPM stuff brought us to what does it mean if we check in the sense of observability that the user is not using authorizations at all. What does it mean? Can we cut off access to the system at all? And we say, yes, we can.

And from a perspective to kind of allow and enable the IAM team to be part of a bigger business play, they can save costs and help the license management team and saying, okay we found out users that are not using any authorization at all. And most of you know, in a large enterprise it's better to have than to request. So basically no one gives back their accesses and licenses immediately. You can save a lot of budget when you really figure out those users are not using authorizations and there's no authorization is used at all.

You can give back that license and save an enormous amount of money. And last but not least, time-based access visualization also a part where we loop back to an auditor. Normally an auditor requests to have a certain controls in place. Are you able to figure out who in your company has been allowed to access this system and this system in the past three weeks, three months or nine months ago? And this is often a very, very hard task or you get a kind of crappy report on an Excel spreadsheet or so.

But users want to have the same great user experience like they do have in the normal day-to-day work. And so we built in this time machine into Nexus to go seamlessly back and being audit-proof. And especially in a situation of a crisis and a cyber crisis, and it's really important to figure out who was basically allowed to act on August 5 in this setup, then it's super easy to get all this information. Having said that, Martin, I'm keen to start the conversation with you. Thank you for your insight. Quite a number of these. I want to continue with a quick poll again.

So when we think about moving to a more integrated perspective, so visibility and observability across various systems across different types of identities, what are, from your perspective, the biggest challenges in moving forward to that? So the poll should open in a second. So the one would be a lack of unified ownership. So IAM might be owned by someone else than whatever ICP, than the world of human identities. A lack of maturity would be the second option in current IAM-IHE. So I think there's a promise that IAM helps you even when you're not very mature.

On the other hand, maybe you need a bit of a maturity to really use these tools. There could be budget constraints. Or at the end of the day, when we really want to remediate stuff, when we want to fix things, there might be a lack of business involvement for understanding the real impact of access risks. And that also means maybe it goes back to the budget constraints. So what is what you see as most important here? We leave the poll open for a while. It should be open or should open in a minute at least. And then move to our fireside chat as promised.

And this will directly move into the Q&A part. So you can, at any time, ask questions already.

Plus, I think what I want to highlight is that you also can vote for questions. And we will pick up questions which, so to speak, have a higher rank earlier because there's this upvoting option. So use this upvoting option if you want to move a question upwards and raise our specific attention to this question.

With that, I think we go into that conversation with you, Heiko. I already noted down a couple of themes which I'd like to address. And maybe we start with a simple and complex one. It's both simple and complex. I brought up the term graph. You brought up the term graph. What you said is graphs are very difficult sometimes or very complex to understand from a user experience. I think my perspective on graphs came more from a data perspective. And I think this is something which is important to understand.

So when we see graphs visualized, it's usually this model where you can click on a bubble and then it explodes with a lot of lines. And then you can move to the next one and pop it up or make it so small that you just see that there's a huge mesh of things, sometimes a mass of things, not only a mesh. And then I would agree it's sometimes not easy to understand what is going on there. On the other hand, I believe, and maybe you have some perspectives on that as well, there's also the side of the underlying data structure.

This is, I believe, where graphs can be extremely valuable because you can manage your relationships between different identities, the relationships to axes, et cetera. So what is your experience, maybe even from practice also, regarding this UX versus? So I'm absolutely with you with the UX point of view. So it looks fancy, first and foremost. But when you really use it as a user, especially in a complex situation, then it gets really tricky. So information representation is often a challenge for itself. And there is very, very rarely the case that you have one identity.

And I would say, OK, what is Martin actually allowed to do? And kind of figure out, oh, Martin is allowed to see on a SharePoint, this and that. This is a super important capability to have. But probably it's not the right visualization for the problem. The question is often, which identities to have access to the board level, to the board's decision, decision PowerPoint presentation or so. And then going back, OK, this means Martin, who is a board member, has delegated some of his authorizations to an AI agent. And the AI agent is also feeding Salesforce. And there might be a lack.

Figuring this out is super important. Figuring this out on a kind of like Sherlock Holmes super detective mode isn't done on an interpret Martin's data and go to the flow. It's more a system has to figure out this information and kind of starting a remediation or setting an audit.

Hey, there's something wrong. Martin has access to super critical information. And now some other entities do have inherited it. Please take care. And I think that's the important stuff. I think that that fits quite well to a question which came in, which is about comparing the identity grids you've been demonstrating and the access graphs can do one without the other. Is it complementary? And where's the market heading to? I think these graphs seem to be something which is quite popular in marketing.

Oh, we showed a wonderful graph. I think from a practitioner perspective, that's what you highlighted. Crits and maybe query interfaces might be the more used thing while the graph then at the end is essential. And so it's very complimentary because at the end, the graph is very essential behind the scenes, at least. It might be relevant for certain visualization use cases, but it's probably not. It can't be the only tool I strongly believe. I think from a data perspective, yes. So when you look at graph as a data model, absolutely yes.

When I look at graph as a visualization model, I think it's only one piece of a much bigger puzzle. What do you think?

Yeah, I think that as well. So it's important to have capabilities in this process that data graph-wise, or to have a graph understanding, kind of having the processing power. But often it's more a marketing feature for some use cases. There might be always an additional layer where you say, okay, for this kind of information representation, I really use a graph in order to make it more accessible to my end user. Then it's absolutely fine.

But from working with amounts of data and kind of working through a whole department with probably a hundred department employees or so, then it's probably really cumbersome to kind of squeeze it in a reasonable manner. And then probably more grid views, or even as you said, kind of some query languages might be easier to get the information you need as a business user. At the end, there are multiple types of usage and multiple information needs, and we need different types of interfaces which build on the same set of information. And I think that's where graphs are definitely interesting.

Which brings us on to this entire user experience aspect. I think this is where you brought up this point of a lot of cybersecurity tools. And I think we not only have a zoo or a sprawl of these tools, we also have a zoo of tools we use for access governance in a broader sense. And in that sense, I would say we have also a bit of an identity visibility sprawl where it makes sense to have some sort of consultation because what I see as a huge advantage is saying we have, so one interface, one risk.

What you brought up is the manager that is responsible for certain access to SAP, as well as to a lot of other systems. And I think we all, you've been a system integrator in a formal life. You've seen probably enough implementations where even access requests were not done in a single tool. Not to speak about the governance and analytical piece. So I think that is, I would say if you look at the big advantage, this is a huge value of this trend of saying, how can I sort of have an overlay across different components I have in my environment? How do you see that? Absolutely.

So there are so many different approaches out there. So some say, okay, I order everything in ServiceNow, from a pencil to a piece of paper, to a new laptop, to an access information. Some are saying, okay, I've spent so much money on my IGA software and they said at the process of setting, it's great. You have to use it. And then they figured out, okay, the IT shop is probably a little bit more focused for technicians and the business user doesn't really understand what all this technical information is able to do.

Some users want to build it into their kind of corporate request portal, whatever it is. So there are many different flavors and it gets even more tricky as you don't have a single IGA system often in place. So you have some systems that are not connected where someone is doing it kind of manually on a ticket base. Provisioning or fulfillment. Then you have some systems connected to your legacy IAM, which is still in place. And a couple of systems are connected to the new one, which is in a rollout stage since 2023 or so, which takes ages.

And then it gets really tricky because you can't say, okay, for system A to D, go please to the left from EK, go stride. And then it gets hard. Having an umbrella that kind of provides consistency that can be an IBIP tool, but that can be another as well, to be fair, I think is enormously helpful for the end user. And then providing proper guidance when it comes to SOD violations.

When you have those SOD violations across various systems, you might be able to request a role in your IGA system and at a later check, someone finds out, oh, it's not allowed because you have already those privileges. That goes well beyond visibility because this is something which even goes beyond observability. It goes into a different type of actionable capabilities where you say, okay, I also can use it when I request access to figure out potential challenges that then arise across a multitude of systems.

So this is probably one level above or two levels even above the IBIP term and one maybe above the IWAP term, if we want. But maybe when we look at this, I think there are a couple of things we can look at. And I think one of the things, this is one of the questions that came up and this is pretty much upvoted by the audience. That is about SAP, for instance, entitlements are much more detailed than in many other systems, at least in the core SAP. So ECC. So I think the one thing is how do you do it? That's the question.

I think that's something that we, how do we handle different types of entitlement models? Maybe normalize them without losing the detail you need, which is one challenge. The other clearly is also, again, going back to the UX question. I personally believe we need a variable UX which sort of provides the right level of insight to the right, in that sense, persona or request. Yeah. So basically I think whether it's SAP or any other system with a lot of detailed authorizations, the challenge is always to bring it together.

So you have this vast, vast amount and you are there and often teams are starting with an Excel spreadsheet and then it's chaos. You don't understand it. You don't have any mechanism to cluster it. And basically what we do to provide is basically we are agnostic on the level. So basically you bring in data into Nexus and we depict the identity, the relation identity to authorization. Authorization is an entitlement, whether it's an IT role, whether it's a business role or whatever you name it.

And then you can kind of really either in a manual way or with simulations, so letting the system do it, figuring out what are reasonable buckets to create kind of business roles. And as an SAP system also relates with users, with end users and identities, you will easily figure out, okay, this is the procurement department and they have a cluster of this authorization and entitlements. And this is the finance department and they have other. And then you can start to clean up, to bring structure into it. And then you kind of, as the saying goes, cut the elephant into slices.

So you won't be probably able to fix it within a fingersnip, but you can figure out the big chunks and you figure out all the outliers. So there is a user who has some very, very strange assignments, why I'm figuring it out. And especially as a team. Not only figuring it out, as I said, I think at the end, we need to move to a situation where we can fix it. So we need to understand visibility or observability instead of fixing it. And if ever possible, automatically. I think I want to come up with a new thing. We don't have that much time left. So maybe go forward from here.

When we look at iWIP, which role does ITDR, so the Identity Threat Detection Response, play in it? Which is another angle of it, which means, so the one is the entitlements you have assigned, the other is what happens with them.

Yeah, that's a good question. So personally, I always thought a little bit more.

ITDR, a little bit more, but probably I'm biased into the access management world. So I log in, I figure out some behavior. I have a detection to an immediate response. Personally, you can probably transfer it to the iWAP or iWIP thing as well. I think having an immediate remediation is important. So that goes for ITDR when it comes to access management. You can't say, okay, I've seen Martin is now requesting a login. From a location based in Russia. I let him wait till Monday, till my system administrator is back to decide whether he is really there or not.

So you have to step up authentication, for example, or bringing up any additional mechanism or I kill all your sessions. I can't be that Martin is traveling there. I think about it from a perspective, for instance, of Martin never uses this file. Right now he uses, he accesses it. This is at least an outlier. It might be malicious or not. And so I think we also can gather a ton of insight if you bring in these perspectives, what is used and also, again, help in remediating a ton of risks. For instance, if we know which entitlements are never used.

And maybe which entitlements are only used in a certain situation. Take a factory where during the summer break, a lot of different access happens because all the suppliers of machinery will update software of these machines and make changes. But they only need access for whatever three weeks when the factory is closed for the summer break. That would be something which is something very easy. Only then you need the entitlement. And the same goes for kind of auditors.

When the auditors are in the house, whether it's yearly financial audit or whether it's an ISO 27 audit, it's a couple of weeks in a year's time. And then those personal identities are not using it anymore. And I think two things, at least two things we provide. On the one hand, kind of really figuring out who's using what, at least if the target system is providing this information. So often systems are not able to collect it or provide this information back. So this is an important precondition.

Then we can say, okay, Martin never used this authorizations despite he has some proper assignments. I would suggest to remove it. That can be a kind of co-pilot recommendation to a business user or even a little bit stricter and more aggressive to say, okay, Martin is not using it. I'm sending you a notification. Hey Martin, I've seen you have not used the system for three months now. In case you don't positively come back, I will kick it out in the next week. Which I interestingly get from a couple of external SharePoints or Teams where I'm onboarded.

Then saying, okay, do you still need this access? Then recertify. Otherwise we will remove the access. Timing. We have one question I'd like to bring up before we come to the end of this conversation. And that is also a question that came in from the audience, which is we've already heavily invested in SailPoint. Why should we consider putting something like iWeb, something like Nexus on top of it? So I would say my answer is you probably don't only have SailPoint and you surely have identities that are not on SailPoint. When we go beyond the workforce, it becomes blurry.

Probably also a lot of systems that are not onboarded. I think for most IAM projects, if you ask for the IJ projects, by far not all applications are onboarded. I think this is something which is also, by the way, a question which came up. Why is application onboarding so relevant in this context? I think one big advantage from my perspective is that you can integrate more insights into applications that are not fully managed by your IGA tool. Clearly in an ideal world we would say we bring it in.

Anyway, there's another poll, by the way, then popping up where you can bring in your perspectives. But maybe your feedback on that point while I bring up my slides again.

Probably, yeah. It's not just about SailPoint. It goes about every other vendor. I think it often makes sense. As you said, there are other areas of IAM. There are other types of identities that are not in the respective software hosted. There is often a better together story between SailPoint and Nexus, for example, indeed, when you bring extra capabilities on top of this IGA software, for example, that are not there, whether it's an authorization concept, which is required for solar-regulated companies in the European Union.

That's a role lifecycle management that's not part of nearly every IGA solution of the larger players out there. When you bring some additional capabilities, you can have a better together story on the one hand. As you mentioned, the other question with application onboarding, there are so many customers out there. I recently talked to a big bank with roughly 2,500 applications. They have just achieved to onboard 500 applications in three years' time, so 2,000 left. If you do the multiplication, it's an endless amount of time. You still need visibility. You still need observability.

I think we are fully aligned here on that. I think this is what we need to keep in mind. There's a lot more out. There's a lot more diversity amongst your identities, amongst your systems, amongst the state of onboarding, Having something that helps you in gaining insight into, so to speak, everything and making it actionable, I think is what we need to look for. It's probably something which is more complimentary than a conflict. It's an integration layer in that sense, which definitely makes sense because we need this intelligence to go back to the title to deliver governance.

Heiko and the audience, thank you very much for this discussion. I want to quickly highlight we have an upcoming event, November 6th, which is our identity-centric cyber security impact today. One day event in Frankfurt. Have a look at it. I quickly touched, so there are a ton of services. You'll find it on our website. Don't miss it. And by the way, don't miss EIC next year. And with that, I come to the thank you part. So thank you very much for participating in this Cook & Co. Analyst webinar. Thank you very much, Nexus and Heiko for supporting this webinar.

And hope to have you soon back in one of our upcoming webinars. Thank you.

Thank you, everyone. And feel free to reach out at any time.