Identity Security and Management – Why IGA Alone May Not Be Enough

Welcome to our KuppingerCole Analysts webinar, Identity Security and Management – Why IGA Alone May Not Be Enough. This webinar is supported by One Identity, and the speakers today are Robert Kraczek, who is a field strategist at One Identity, and me, Martin Kuppinger. I'm principal analyst at KuppingerCole Analysts. Before we dive into the subject of our today's webinar, a little bit of housekeeping.

So, you're muted, essentially, nothing to do here. We will run two polls during the webinar, and I always encourage participants to participate in the polls, because that helps us gathering interesting data, which we, if time allows, may use in the Q&A. There will be a Q&A session, so we will have a longer sort of fireside chat session, but also during that, you can always enter questions. We will sort of include them in our talk.

So, it will be a mix of, so to speak, fireside chat and Q&A, and a great opportunity sort of to pick the brains of the experts today. And last but not least, we are recording the webinar, and we will make the recording, as well as slide decks, available soon after the webinar.

So, before we look at the agenda, I'd like to start with the first poll, and you will find this Q&A section to the right hand of the webinar tool, if you're using the web tool. And so, we leave the poll a little bit longer open, so you have a bit of time to answer here. And the poll is about the main reasons for IAM projects stalling or failing.

And yes, there might be more reasons, but we only have four to five options we can use on the webinar tool. So, we have chosen four. The one is budget. The second one is stakeholder management, so bringing all relevant people on board. Then there's the lack of understanding of IAM risk and regulations, and there's the lack of skilled resources.

So, which of these four do you believe is the most relevant one? As I've said, we leave the poll open for a bit, so that you have some time to respond to the poll, while in the meantime, we can have our first look at the agenda.

So, as most of our webinars, it's a agenda that's split into three parts, and in some sense, you could argue four parts, because we have a chat and then the Q&A, which, as I've said, will probably be sort of merged into each other. In the first part, I'll look at the breadth versus depth silos and the target operating models for IAM, and why it's very relevant to think thoroughly about these, having a lot of different systems, a lot of different pieces in IAM, especially in IGA.

In the second part, then Robert will look at enhancing IGA and sort of adding the missing layer for a comprehensive IAM and IGA. So, what is it, what frequently is lacking, and maybe too disparate?

So, he will go deeper into detail, more into practice here, and then, as I've said, we will have a chat about these aspects, look at how we see these and our experiences, our thoughts about it, and that is a very great opportunity for you already to bring in questions. At the right-hand side of the screen, you also will find the Q&A area, so you can enter your questions at any time. You also can vote for questions, and we will usually pick the questions that have the highest number of votes.

So, use these options, make it lively, and use the opportunity to ask ourselves about what we want to do. I just observed that the second poll is in the wrong place. Give me a second. Moving this away. It hates me. Give me a second.

So, here we go, and let's directly jump into our topic of today. So, the point I'd like to talk about is, what is, so, there are several challenges in IGA, as we know. Recertifications can be challenging. Managing roles can be quite cumbersome. Connecting systems is not easy. Sometimes we tend to over-customize, but aside of these things, and we've covered them in many different webinars over the past years, there's one area which I think also is very, very important, and that is that, in some sense, IGA doesn't cover everything, and what I did here is I brought up a slide that is not very new.

I think I've created a slide that looks a little bit outdated from covers, et cetera. I created a slide, I believe, some 15 years ago.

So, it's really old, but it's still, I believe, very valid. So, it took me a while to find, because I didn't use it for a while, but I thought for this webinar, it might be a great slide, and so, what this slide is about is basically, in the upper part, we have our IGA, so the Identity Provisioning Fulfillment, the Access Governance, with the Access Request Management, with Recertification, with Analytics.

We have the role models, so business roles to system roles, and then we map it to, for instance, global groups and active directory, which then are mapped to local groups, but from an Identity Provisioning perspective, very commonly, we have primarily insight into what is exposed at the highest level, the highest level of AD, or at the highest level of SAP. So, in many of these systems, we have, again, multi-layered models, and we don't have the full insight here.

So, what happens in reality is that we usually don't, or in many cases, in some cases, we have, but in many cases, we don't have the in-depth sort of view and the in-depth control about the target systems, about their, if they have complex entitlement models, about their complex entitlement models, and that means we basically have a sort of a defined break point where things can fail. That is, we look at IGA, so the upper part of the graphic. We do manage our role models here. We map them to the AD groups, but someone else is managing the world of AD.

Someone else is managing the world of SAP, of Salesforce and other systems that have more complex entitlement models, and if that person makes changes, it's not sad that we know it at the IGA level. This may impact our SOD controls. It may impact, actually, our access governance, and so we have something where we need to get a grip on it, which we can do partially organizational, partially technical, but at the end of the day, it's a bit like we have the IGA silo, and we have the target system silos, and we need to think about how do we, how can we solve that?

I know some organizations have solved it well, but not all have solved it well, and it's a sort of a by default challenge to look at because IGA is targeted at the sort of the upper part, and we still have the lower part to keep in mind, and it's not only IGA and AD.

It's also, for instance, if you look at this entire world of application access governance or application risk management, application access control, whichever term you want to use, so these solutions that, for instance, help you in devs controlling entitlements and SOD controls, et cetera, in, for instance, an SAP environment, in an Oracle enterprise application environment, whatever else.

These solutions then commonly come with rule books, optimizations for the line of business applications targeted at these types of applications, while IGA targets more the breadth of applications across everything, so it's really a breadth versus depth thing, like an active director administrator goes very deep into his active directory. IGA is more broad across the applications, so this is a per-definition challenge we need to look at, and some things usually are in common. They overlap, but we need to understand which tool serves what. What do we need? How do we bring these things together?

How do we create a more comprehensive perspective, and as I've said, it's not a new challenge. It's one that is around for decades, and we need to be aware of this to deal with it properly, and yes, IGA is just one part, and there are so many other elements within IGA. This is our equipment called Identity Management Reference Architecture.

We will, by the way, release a new version that will be as a webinar in January, so I think January 14th, we will do a webinar on the next incarnation of the identity fabric and also touch the reference architecture, so stay tuned, where we go into how this evolves, how this continues, but there are many elements, and so for a comprehensive IGA, we need to look at what is it what we all need.

What are these things, the specifics, for instance, around the management of line of business applications of active directory and other very important applications that have a very granular, multi-layer security model, and how can we enforce this, and this is something which is about really technical integration or technology integration, like how does you, if you have an SAP access control, I see many call it SAP GRC, so the SAP access control solution, and you have an IGA solution. How do you bring these together? What is the right way to do it?

That's a technical integration charge, but it's also an organizational challenge, and what you need to do is you need to understand how these things can come together. How do you really make people work together, so that even if you have more than one tool, and in many cases, it means you need specialized tools for certain environments, and sometimes you can do quite a lot with your IGA, but if you would say I need a specialized tool, I have this environment, then how do you enable collaboration on a regular basis? How do you bring this together in the organization?

Because in many cases, it's just that there is, oh, here are the identity management people, here are the AD people, and those act like in silos, or the SAP people, or whoever. We must get rid of these silos and must think about how do we make this work together, and this is where target operating models come into play. This is a standard foundational target operating model for the IGA world, for IAM, basically. How can this look like?

It's a bit more than IGA, it's really more the IAM part, with the development and the platform operations, which also could be at the ITAS, the cloud provider, with the functional operations, and with the governance and business involvement pieces, and within such a model, we have different areas, and I marked some of them in red, which are logical points to bring together, for instance, the identity management team with the AD team.

If the AD team is separate, if it's one team, it's even easier, but even then, you need to define which group in the IAM team does what, who's responsible for what. You need to have very clearly defined responsibilities, and the most important point with every target operating model is to define the intersections between different layers, between different teams, between different parties. What do you do, what does your managed service provider or your system integrator do? If you have the IAM team do, what does the SAP team or the AD team do?

This must be defined, because otherwise, you always will have the situation that either one feels that the others are interfering with their work, or more common, and usually even more worse, that everyone says, oh, I expected the other to do that, and no one does it. It doesn't help you. You need to think about a target operating model. You need to go deeper into detail to make this work, and this is a very important point. If you look at the full breadth of what we need to do around entitlements, around roles, groups, access, then we must not stop at the IGA level.

We must go beyond, especially we must go deeper. This has some high-level thoughts here, and before I hand over to Robert, a quick second poll, and this is more about the budget perspective. When you look at the factors that are impacting your organization's IAM budget, that are basically, in that sense, are, if so, helping to grow, or at least stay stable, the IAM budget, what is the most relevant, what is the primary factor here? Is it regulatory compliance? Is it organizational growth?

Is it ever-increasing security threats, and new options you have on the technology side, or is it more about operational efficiency, cost reduction targets, where you say, okay, this is where we need to shrink our budget, so this is the downside of it. Again, we leave the poll open for a bit, so please enter your perspectives, and with that, I come back to the agenda, and the second part right now of the presentation will be done by Robert, before we move into our chat and our Q&A.

So, Robert, it's your turn, and I'll stop sharing, and you can start sharing. Thank you so much.

So, Barton Tak just spoke about the target operating model and the complexities on line-of-business software that may hinder or add complexity to an IGA strategy.

So, if you look at when you're designing a target operating model for a particular use case or use cases, and you're introducing IGA to your environment, there's very often an enthusiasm, I'll say, around solving every problem with an identity governance solution, a product, a solution set, a combination of consulting services and customization and an IGA solution, and as you dig deeper into those line-of-business solutions, like Martin mentioned, SAP and, of course, Active Directory, you'll find that the complexity outweighs the benefit, and what do I mean by that?

If we look at today's environment, and as Martin mentioned, he has a 15-year-old slide that really hasn't changed much in how organizations organize their identity security, but you'll find that today's environment has become increasingly complex, where you have millions of users in internal and external sources, you have federated identities, you have, of course, service accounts and AI automation, now we're starting to see more advanced AI that's being used for policy management, and, of course, we still have on-premise solutions that can't be moved to the cloud or that can't be moved into a cloud directory service, and so you have this, instead of a single or two or three directories in your organization, you may have a dozen, and so introducing identity governance administration to that type of model can be very difficult without line-of-business specialization, and what do I mean by that?

Well, if you look at, say, Active Directory, for instance, if I were to approach Active Directory strictly with an IGA solution, and let's say an example model would be an organization that's had Active Directory for 10, 15 years, you're going to have layers upon layers of different groupings, different structure that's been built into that directory to suit your organization's needs.

Trying to understand that and extrapolate that information and drawing it into an IGA solution without, perhaps, an intermediary line-of-business application that can sort of filter what's useful and what's not, you're going to end up with a program that could become overwhelmed by all that AD structure. As a former customer and as a consultant, I've seen many, many IGA programs falter or stop because the Active Directory structure has become too complex to implement natively in a governance solution.

So, say, for instance, you have 1,000 Active Directory groups. You really don't know what's in there from a holistic perspective. You may have an administrative team that understands where certain groupings lie, but as Martin just pointed out, that could be a siloed source of information, and trying to understand how that's structured and then draw it into a governance solution natively and try and manage it from that solution may not be the best choice.

And if we look at our other issue with today's environments, and that's more automation, now you have bots and ever-increasing amounts of service accounts that may not be subsidiary accounts to an actual person. They may be operating on their own.

And so, how do you understand how those are governed through Active Directory into a governance solution natively without some sort of intermediate layer can be very difficult. And, of course, the legacy stuff, you know, I would be curious, Martin, we should do a poll on how many people have one AD domain. I would challenge that most organizations have at least two or three because you have to count intra-AD or hosted Active Directory and AWS or any other flavor of Active Directory could be counted as a separate domain.

And so, when you look at the current state of cybersecurity, you look at identity governance and overall your IAM program, these line-of-business applications that help you organize and structure your data before you deliver to an identity governance product become very important, particularly if you've inherited an environment that you don't really know where all the structure is or how it's actually been built.

And so, if we look at a sample architecture that I built, you know, in a typical environment you'll have, in this case I have Azure, of course it's rebranded Entra, but you could substitute any of your popular access management products here. You have business identities, external identities, and privileged identities all operating within your organization.

So, from an identity perspective, relatively straightforward and simple to look at. However, if we dig deeper, some of those identities are being provided to, say, a ZTNA or SASE cloud infrastructure model, plus they may be utilized maybe via LDAP through Active Directory on-premise in some of your switches and routers and other Layer 4 and Layer 7 gear that you may have on-site.

So, these networking solutions are tied to your overall identity infrastructure, and you typically have specialty applications managing those. But now, if we bring in more structure, now we have privileged users and we have remote access that we have to deliver through that networking model, potentially through that access management model, and we're utilizing your identity infrastructure.

Okay, so now if we look at identity governance and administration, your authority of sources, as Martin mentioned earlier, SAP. SAP is a huge presence in a lot of organizations, and you're providing, it's providing you identity data that you have to govern.

But, IGA is not the facilitator of a lot of these day-to-day operational needs, and when it comes to managing the overall identity repositories, most organizations have Active Directory still in the center of all of this.

And, if I were to try and use IGA to manage all these pieces without somehow creating either a filter or some sort of other type of structure around Active Directory, a line of business application, or something that could help me extrapolate the important data from Active Directory, so that I could deliver that data to my access management product, I could deliver it or consume it from IGA, I could add those different functions of Active Directory from an attribute level perspective, along with my target system information into IGA.

There's got to be a way to extrapolate and organize that Active Directory information before I actually consume it with IGA, and then also deliver it to other sources like Azure, or Entra, or my PAM solution, or thousands of other applications that may be out there that utilize Active Directory in some way. And, let me give you a real-world example. I was recently speaking to a client, and they had a cloud initiative, which many organizations, I'm sure you as well have, where you're cloud first, and we're going to move all our directory information to the cloud.

Okay, that's great. Well, there was a lot of head nodding, there was a lot of acknowledgement that that was the path forward, and the networking team, one of their team lead raised their hand and said, that's great, and I appreciate where you're going with this initiative.

However, all of my Palo Alto gear, in this case, uses Active Directory for authentication and management of the security model of all that networking equipment. What are we going to do with that? How are we going to organize that data so that we can deliver it to the cloud?

Currently, it's not possible, and we can't use IGA for that. IGA is not fast enough to make the decision points needed when we make a security change in this networking equipment.

Again, that's where a line of business or intermediary solution would step in to help that organization figure out what's being utilized from an Active Directory perspective, security perspective, to manage that Palo Alto equipment. Then, from there, you can deliver that information to IGA, and then insert that into your governance process. It's the same example with SAP. Very few organizations build an SAP management model from scratch in their IGA system.

There's typically a very large, well-built SAP modeling connector or application that is purchased or added as a separate piece into the IGA solution to help you understand how that S4 security model actually should be leveraged within your governance program. So, in the examples that Barton gave, SAP and Active Directory, those are two prime examples where you need an intermediary solution that can help you filter all the extra things that you don't need to place under governance before you deliver it to your governance solution.

This is the most successful model that I've seen in the field is where you're pre-filtering, if you will, your AD or your SAP or your other high-level or applications of a deep level security model before you give it to your IGA team to develop a governance framework.

Some of the other things that I'd like you to consider when you're building out a program and you're looking at your different management paradigms that you need to place during either your overall IAM modeling or when you're delivering or building an IGA solution for your organization is, how are you going to build out the most important pieces of, say, that Active Directory security model in a way? How are you going to consume that build-out and how are you going to deliver that identity governance model to your other applications?

Is it going to be from a discovery method where you're going to add an Active Directory solution to your Active Directory modeling program where you actually maybe combine a number of different domains into a single management console before you deliver it to your IGA solution? Are you going to perform some manual processes first where you organize your Active Directory in a way that helps it be a little friendlier when you start to federate to Entra AD?

Are you going to try and model all your Active Directory groups and organizational structure into IGA natively and then perform attestations after the fact to expire the ones that aren't needed? There's a lot of things you need to consider with that and one of the things that we do at One Identity is we provide some modeling capabilities that allow you to extrapolate that Active Directory information and get a really thorough understanding of how that very important authoritative source of identity information is organized before you add it to an IGA solution.

I think that's something that Martin and I were speaking about a little earlier before the session started is that things really haven't changed in 15 years. It's just gotten faster. I've seen a lot of governance initiatives stall or fail because Active Directory wasn't considered because it was a siloed source of information with a separate team.

I guess I would encourage all of you to take a look at your AD model and really think about what tooling you can use to organize that infrastructure before you deliver to your IGA solution so that you're not having to reinvent and discard a lot of structure that wasn't necessary for the program. Right now we are entering the chat and the Q&A part. Right now we will look at the questions. We already have a couple of questions here.

As I've said, feel free to enter more questions and also vote for the questions because I think the Voting Advice helps us to pick the ones that are of the biggest interest to you. So we will then walk through the various questions and I'll stop sharing here so that you can see the two of us really more in a talk. The first question, and that's the one that already has a vote, that is, do you see organizations where SAP GRC access control or similar tools are in the ownership of IAM and how to convince the SAP kingdom of shifting responsibility here?

So Robert, do you have any thoughts and experience here? Yeah, I actually have a lot of experience with that. So SAP GRC is a very interesting application. I know SAP has made some changes to that over the years and they have some other solutions that perform similar roles now. But SAP GRC can be a touchy subject to talk about with an IAM team because it's typically owned by the SAP team.

And we at One Identity have some pretty good capabilities around SAP and what we found is the best approach, in my opinion, is to understand how SAP GRC is being used first because it can be used in different ways depending on your implementation and and your use cases. And then figure out how you can augment that and bring them in not as a replacement for SAP GRC, but I would recommend understanding how they're using it and then see where you can augment and add, either streamline the capabilities of it or put a wrapper around it to add integrate GRC into the overall certification framework.

So now, case in point, we had a customer who had a very large implementation of GRC and they were using it just for SAP modeling and we were able to take those use cases and integrate GRC into our overall attestation model so that we were feeding the information back to GRC. It was left alone and we still had a larger access model for the overall big picture of the identity. So I don't know, Martin, if you have anything to add.

Yeah, I think to my experience, and I think you raised an implicitly very important point, the first thing is talk. So talk to the others, gather a common understanding, the likeliness that each party will learn a lot during this process is high because there might be things where you say, okay, I didn't know that they are doing this, this seems to be really important, we can't do it, or there are things they could do, we can't do well. So why not joining forces? And so I think talking is really the first step and then it really depends on what is used, what is the scenario.

Probably it also might, may change, some things may change in the future when the SAP Access Control Tool is moved to HANA, the cloud, and also the operations part changes a bit because currently, clearly, the thing that runs in the SAP environment, it's ABAP, it's very, very close. So the ABAP part probably won't go away, but the way it's operated, it changes. So that also may help in working. And then the questions about integration, about how to work together, who has the ownership for what, again, something which we also can map very well into a target operating model.

So when we think about a target operating model, these are the points where we then can define, okay, who does what? But it's a starting point. I also think it depends a bit on the role of the CISO. So for the sort of first level of defense type of CISOs, so the ones who are really active in cybersecurity and frequently have a broad responsibility for them, some of them really sort of also request to have the ownership of everything that is related to security and to governance and related controls.

So they have to deal with the audits to say, we need to be in charge of everything, otherwise we will strike. So there's also, I would say, an organizational factor that's impacting this.

Okay, so we are getting more questions here. And we see also quite a number of votes. The second one is one I also would give first to you, because it goes back to something you brought up. Maybe you opened a bit of the box of Pandora here in this case.

Robert, you've mentioned non-human or machine identities. Is this another area where we need integration of IGA specialized tools? How could this look like?

Yeah, so the thing that I think about with non-human identities is, you know, to me initially, it was just service accounts, right? Very static systems. They perform a very specific function. You just turned them on and you left them alone. But now that we have non-human identities that can essentially act like humans, they can perform very complex operations. And depending on how far down you've gone the rabbit hole with AI, they can actually be quite dangerous. So in an IGA model, the thing where we always consider is your risk and how that affects your entitlement score and other things.

So in my opinion, as non-human identities become more and more commonplace for more advanced functions where you need to place them under governance, I wouldn't treat them really any differently than a high-risk user, which means there has to be other factors that are added to, you know, to the authentication and the authorization of those machine identities that maybe you didn't consider before. So for instance, you might have a service that, you know, a bot or an AI system that does advanced scripting for you and it authenticates into your different systems. It uses Active Directory.

You know, you have to consider how you're going to govern those from an acquistation perspective. Are you going to assign ownership to those AI systems? Are you going to uplift their risk score so that they have to have a certain encryption level or some sort of step up or second authentication that it can utilize? Because obviously MFA and a phone is not going to work for AI. So those are a lot of things that in an IGA model, you have to consider when you're uplifting and as you have your Identity and Cloud Conference 2025. So a lot of those topics, I'm sure, will be covered there.

But in a nutshell, I would say that your service accounts need to be treated less like static accounts and more like high-risk users. And you need to understand all the options available to you through your specialized tooling and your IJ solution to manage those. And I think this entire non-human identity or however you'd like to call it, is a huge topic because it's not that we have humans and non-humans.

We have, as we all know, we have within humans, we have the employees and the extended workforce and other types of partners and customers and consumers, et cetera. And on the non-human side, we have everything from a service account, very traditional, the privileged account, to service accounts. We use an infrastructure as a service where we talk about many more. And we talk especially about volatility because whatever the Linux admin account, super user or the root account, yes, that was quite steady.

In a world of DevOps and agile development and running this on the cloud, things go up and down and appear and disappear. So we talk more about automation. Then we have also things and devices and other types, so to speak, the real machines, things like that, and so on. And we have AI, so bots and agents, which I like them because they're really interesting. So in this field, I tend to call it AI identity. In this field, we have this nice challenge of, we have a bot that is acting on behalf of different people, and we have an identity relationship challenge as well.

So we need to do a lot of things. So the question is, where does IGA in the traditional sense come in here? And I think at the end, we can go back to the good old and hard to seldom implemented PAM to IGA integration. So what I always say is every privileged account, so every functional, technical, non-human account in this world needs to have an owner. And when I have, for instance, a mover process and someone moves into a different role, then the mover process must trigger the change of the ownership, and in that case must interact with the PAM system.

And this ownership thing, I think, is something we should expand, which will make IGA, which is a new challenge for IGA. But I think at the end, IGA is the right place to trigger these things and then to interact with different types of systems. And so at least from this, how do we implement these processes, the ownership to change processes, the governance processes as well? So this is clearly an area where we need to think about a better, deeper intersection of IGA with non-human identity space. And I just had a thought.

So I would say any of the attendees who are, say, an engineering firm or someone where they onboard teams for 90 days or 120 days for a program, they're very familiar with the concept of sponsorship. And with sponsorship, I would say that you could use those similar paradigms for advanced bots in AI. You need a sponsor. You need someone overseeing them from a perspective of management and responsibility. And I think if you start with that concept, you'll have a better approach to these types of advanced artificial identities.

And one other thing I have had in my conversation with customers, two approaches to AI. One is paranoia about managing the AI, and the other one is leveraging it as a tool. So I'm seeing this dichotomy in what AI means to organizations depending on their position. That may be true. And I think we're just sort of working on the very foundational things you have to get a grip on AI to do the right way with it.

As I said, there are so many, many interesting questions which go well beyond IGA around the identity scene. And as you mentioned at our European Identity Conference 2025 early May in Berlin, we will definitely have a lot of talks about that. But maybe back to a question that is related to what we just discussed. And that is, how do you consider the role and responsibilities of CSPM, so Cloud Security Posture Management, and KEEM, Cloud Infrastructure Entitlement rules in relation to traditional IGA offerings? Yeah.

So, I mean, with KEEM, you're essentially trying to create an organizational structure on things that may be a little chaotic. I think traditional, if you look at a traditional model, IGA model, the original intention was to help you organize your identity sprawl.

That, you know, that was join, remove, or leaver, right? That was what we started with. And then we added governance to that. But if you look at, say, popular cloud systems like, you know, Entra or Amazon, they have their own unique way of managing the resources. And that's become a very real concern for organizations, especially if they're multi-cloud, because now you have these different types of modeling that may not make sense to a traditional IGA environment. How do you how do you put that under a wrapper? How do you add these different management approaches to a traditional IGA solution?

And I would say that IGA solutions are typically designed very flexibly. They're very flexible systems.

So, adding KEEM or adding other types of modeling that may be specialized to a particular cloud environment or to a different, to a methodology, I would just look at those and understand how they're built and then see if you can create a mapping to your traditional attestation and access review model. I don't really, honestly, I don't see it as a huge leap to add those things into an IGA solution.

Yeah, I think there are a couple of interesting points around that. So, when we look at KEEM, for instance, I think basically it started with that we learned, OK, we have a huge number of service accounts with access to resources that can be very critical in different infrastructures. I don't like the term KEEM with the C and the I, because it's probably more than cloud and it's more than infrastructures, every dynamic sort of runtime environment.

And so, it's clearly more than infrastructure. But the problem remains the same.

So, we have things where traditional super user accounts sometimes are really not as big as a problem as what we have as a service account somewhere on AWS or Azure Cloud or wherever, or GCP. And we need to get a grip on that. And I think initially it started with a look at discovering what we have, understanding what we have, so that I can understand the risks and try to mitigate these. There's another angle, which is how can I sort of avoid that sprawl or get a bit of grip on that?

So, for instance, by having no, so to speak, standing privileges, no secrets around that. There's some interesting things or standards like Spiffy Inspire around that. And then there's the part which is the governance element.

So, what is the grip? And I think IGA is typically in this highly automated, highly volatile environment, not trying to move a lever or two for these types of accounts, because they might be too volatile, but there's a governance angle. There's an ownership angle and all these things. This is where I believe it really comes in. And this is where I would say, this is the area where we should think about when we look at this intersection of the different types of tools.

Okay, let's move forward, because we have a lot of questions here to answer still. One more question is, and that's this one, maybe I start with the response here. Should ADB, AD, so Microsoft Active Directory, be in the domain of IAM or separate? And what about Azure AD and Entra?

So, who should own it? I have a very clear perspective on that. My perspective is Microsoft AD should be owned by IAM. Entra ID must be owned by IAM. I think this is how I see it.

So, at the end of the day, yes, the traditional Active Directory does some things which are not directly identity management. Take all the group policy objects, stuff, et cetera.

And so, it started more probably as an infrastructure tool. It was out of a network operating system back in the days when we used these terms.

So, it evolved, but at the end of the day, it's primarily nowadays really a tool for managing identities and access in systems. And so, the logic is it should be there in the IAM realm. For Azure Entra ID as being primarily an access management tool, I think the answer is very, very clear. And I think there's no, really nothing, I don't ever have heard a valid argument why it shouldn't be that way, at least with the Entra ID perspective. And by the way, if you want to pick more of my brain, KC membership, we've shown it here, the option to directly interact with me and our team.

Okay, what's your perspective, Robert? I agree 100%. All the most successful programs I've seen where they were able to establish advanced controls and governance, IAM owned Active Directory, and they used it as a very important authoritative source.

I think, maybe just to add a little color, typically it's a political problem. And it's because Active Directory, you're right, Martin, started with the server team and started with the infrastructure team.

And so, that's just the way it's always been. And as humans, we're very set in our ways.

And so, but I would encourage you, anything really identity-related, directly identity-related, should be IAM team. And so, they can establish a strategy around the complete control of those identities and the governance's identities.

So, I agree. And I could argue, if I could have made this change, everyone can do, because I started with LAN manager. I went through the entire Windows NT world into the AD world.

So, I've seen everything before, and I have a very clear opinion, also with a very deep knowledge of the other world. And I think this is also very important.

So, that is a nice question. I think there are some other questions around AD. The first one I'd like to pick, we have several AD domains hosted by AWS as a managed service. How can we manage that environment better? I think the question is, what is right, and it might be worth to reach out to Robert and or me directly. I think we are easy to identify on LinkedIn, et cetera. But maybe you have a bit of a more generic response here. Yeah.

So, I think that, you know, being able to aggregate your AD domains into a central management point through some sort of tooling, I think is the best way. You want to find a way, because if you're managing 50 plus domains individually, it can be, it's a huge time waste, huge time waste, particularly for your help desk, your second line administrators. I know I used to be one. I'm sure Martin was one as well. You get those calls to make that quick change to an identity.

Well, imagine doing that on 50 domains. It would be excessive.

So, you know, from a general perspective, I would say, you know, introduce a specialty, so specialty tooling that could potentially help you streamline that process would be my recommendation. And that would be for other things as well. That's why people introduce specialized tooling against SAP or against, you know, other sources of truth that have an extremely deep security model and may be distributed over multiple systems. And I think the next question goes in the same direction.

We are currently attempting to add Active Directory intra-ID groups under management to our existing IGA solution, and it's becoming increasingly difficult to model them all. What can we do to speed up the process? I think basically it is, there are tools you need to use in close integration with what you have on the IGA side that Robert might be the spoiler for your quick one identity active role server advert, so to speak.

Yeah, no, I agree. I think being able to streamline the process, like your point around GRC earlier is sometimes it's better just to have a conversation, understand what needs to be placed under governance, and if there's a need for more filtration or attribute mappings of things that may be difficult in your governance solution, I would look to introduce something that could help coffee filter the data into governance, right? What's the old term? Garbage in, garbage out.

So I've seen a few customers, you know, clients who decided to just import everything from AD and then they had, you know, a third of the imported groups were useless, and they had to go back and clean it all up again. And I think, you know, every AD environment I've seen, which was around for a while, and so first it tended to have too many forests, the main worst cases, definitely in virtually every case, too many domains. And in any case, a lot of orphaned accounts, index accounts, you didn't use any more groups, you didn't use any more. So you definitely need to clean up.

And I think this goes to another question we have here. We have been trying to replace AD with Azure or Android ID for a few years. Can this process be simplified? So what I would say at the beginning is, the first question is, can you fully replace Microsoft Active Directory? That depends on how many dependencies you have.

So if you're a manufacturing company, in your operation technology environment, you may have dependencies, in your operation technology environment, you may have dependencies, which hinder you to fully replace, but you at least probably can, can minimize and sort of, yeah, so isolate to a certain extent, the on-prem AD, which makes sense. So, and then at the end of the day, I believe this is really where it starts with dependencies.

So what is really dependent on AD, and clearly one of the first steps is to shift from, so at the beginning Microsoft said, okay, you, so to speak, you provision from AD to Azure AD. We can flip it for years right now, and clearly it's very clear to flip what is the primary system or the IGA, which serves both. It could be a very smart approach that you say, okay, at the end of the day, a lot is really more the IGA serving both and working that way. Any further hints from your end?

Yeah, no, I agree with you a hundred percent. I think the important thing is understand your environment and understand where the dependencies are and understand the technical and political hurdles. And sometimes the technical ones are far fewer than the political ones, but, you know, the other thing to also consider is the expense. You own AD. You're paying for it as part of the operating system. It's a known quantity. Once you go to the cloud, the more you add, the more you pay.

And so, you know, obviously that your mileage will vary on that statement depending on your, you know, service agreements and your contracts, etc. But as technologists, we're always interested in the most efficient way to get something done. And if Entra, migrating to Entra has taken you two years and it hasn't been successful, then it may be time to re-evaluate what you're attempting to accomplish.

And then, you know, like Martin said, understand where the dependencies are from a technology. Again, it's the word on my consulting hat, people process technology. So understand who's involved with the program, what the process is that's not working right now, and then what the technology is that needs to move. And there may be dependencies, like my anecdote earlier where, you know, nobody can sit in the networking team with the Palo Alto gear and it uses AD for management. So you can't move to the cloud, right?

So now, okay, we have to take that off the list, right? And let's focus in. That's my opinion on it. It's a journey, not a destination. Yeah. And that's through a good closing statement, in that sense.

Robert, thank you very much for all your insights and to One Identity for supporting this COVID-19 Co-Leadership Webinar. Thank you very much to everyone who has been participating in this webinar and for all the questions that have been entered and the participation in the poll. By the way, in the first poll, stakeholder management was seen as the biggest challenge in IAM projects, even bigger than budgets, just to bring up the point.

Yeah, I think sometimes it's budget, sometimes it's stakeholder management. But I think in reality, stakeholder management and some of the other things like proper planning, having processes, there are a lot of things where you can make a project struggle.

Anyway, thank you very much to everyone. Hope to have you soon back at one of our events to talk to you soon, to be in one of our webinars. Thank you.

Thank you, everyone.