From IAM Pitfalls to Realistic Roadmaps: Structuring Identity Projects for Success

Hi everyone, good afternoon and thanks for joining to today's webinar. My name is Charlene Spasic, I'm a Senior Advisor at KuppingerCole Analysts and the topic of today's webinar is From IAM Pitfalls to Realistic Roadmaps, Structuring Identity Projects for Success. And the reason why I'm talking today is that I'd like to share some insights from our advisory work and more importantly move the conversation from problems that we observe towards practical solutions. So before we jump in just a few quick housekeeping points. Audio is centrally managed so no need to mute or unmute yourselves.

I'll also run a few polls during the session to make this a bit more interactive and we'll discuss some of the results later on. Besides that there will be a Q&A session where we will also look at the poll results and you also have time to post questions. We will look at them at the end so you can anytime use the chat to do that. And finally this session will be recorded and the recording as well as the slides will be shared with you after the webinar. All right so let me briefly walk you through the agenda of our webinar today.

At first I'll start with why IAM programs struggle in practice based on experience across enterprise or let's say end-user organizations. Then I'll shift the perspective from capabilities to tools because that's a key step to bringing more structure into IAM. And building on that I'll introduce a structured IAM approach on how to think about IAM in a way that is actionable and that will ultimately lead to a well-defined roadmap for your IAM program. Finally the key takeaways you can apply in your own context and of course we leave time for discussion and questions at the end.

So before we jump into the topic I'd like to start with a quick poll and I'm interested in your perspective. So what is currently the biggest challenge for IAM in your organization? Is it unclear ownership? Is it data quality issues? Is it a missing strategy or too many competing priorities? Or is it challenges around complexity or tool integration? And with that being said there is no right or wrong answer here. The goal is simply to get a sense of what resonates most with you. So feel free to pick the option that best reflects your current situation.

I will leave it here for a couple more seconds before we move forward. All right. So now let's take a look at IAM in terms of a broader organizational setting. Identity and access management it doesn't operate in isolation. So instead it sits at the intersection of business, security, and compliance. And organizations they rely on IAM to ensure that this is sort of the common phrase that the right people have the right access to the right resources at the right time. Right?

But the challenge appears so the challenge that appears is that IAM must simultaneously address very different expectations across the organization. And there are three drivers that primarily shape IAM initiatives or IAM programs. So we have the business demanding enablement. They want fast onboarding. They want seamless access to systems. They want to enable digital transformation and digital services for their workforce and also for partner ecosystems that they engage with. Then on the other hand we have security which demands protection. Right? Protecting critical systems.

Also reducing identity-based attack risks so to speak. Right? And then we as a third factor have compliance which demands accountability. That means meeting regulatory and audit requirements ultimately through governance and control. And as you can see IAM is in the center and these priorities they pull in different directions. Right? And these priorities within your organization they are typically represented by different teams or also different stakeholders. So we have IT. We have HR. We have of course security teams. We have compliance teams or audit teams. We have application owners.

And all of those they come together with different goals and also different perspectives. Sorry. And so to speak this is where you see like the pulling in different direction. What enables the business can likely increase risks. Right? And what satisfies security can slow things down on the other hand. To give you an example for this when we think of MFA. Enforcing strong multi-factor authentication. It increases security but at the same time it can create friction for end users or it can impact productivity.

And ultimately if there is too much friction for users they will either complain or they will try to find ways to bypass those controls. And another example is when you think of fast onboarding of users. So the business may want to onboard employees or partners immediately. Right? Should happen in a blink of an eye. But security and compliance they require proper approvals. We need specific checks. And yes same applies to fast access to systems. Compliance requires approvals, documentation and also auditability. Right? So as you can see IAM is not just a technical topic.

So for me it's about balancing competing expectations across the organization. And this is exactly where IAM programs may start to struggle. Because when these perspectives are not aligned what we typically see is that sort of ultimately programs don't deliver the expected value. So the goal of IAM is not just to gain control but it's, as I put it here, enabling business value through an identity-centric approach. So ultimately a successful IAM is about balancing these competing priorities and also putting identity at the center to connect business, to connect security and compliance.

Yeah and so with this view in the back of our minds I'm also interested in how IAM efforts are typically prioritized in your organization. Or you could also say what drives your decisions in IAM. Is it urgent business needs? Is it compliance or audit pressure? Is it sort of security risk considerations? Or do you already follow a defined target state?

Or maybe, and that's something that can happen in reality, is that there isn't a structured prioritization approach yet. Also let's give it a couple of seconds for you to vote. But the poll questions will also be open throughout the webinar so if you need more time. You can take this time. Okay so let's take a look at what can be observed in practice. I would say that almost every organization today agrees that IAM is critical for security, compliance and also for the business. But when we look at IAM programs in practice the reality also indicates something different, right?

That's what we observe. On the left side you see sort of what's happening. There are projects that run longer than expected. We see that the scope is expanding, also scope creep so to say. We also see that ownership is unclear. And in many cases the business or end users struggle to see the actual value, right? There might be issues with user experience and with user adoption.

And yeah, ultimately IAM programs can become what people describe as this sort of never-ending program. And yeah, what we have here on the left is sort of like the symptoms that can be observed. But the more interesting question is like why does this happen? And this is where it actually gets quite interesting because the underlying issues, they are usually not solely technical. They are rather structural or organizational. And this is what we have on the right side of this slide.

For example, one issue that I observe is that organizations, they start without a clear IAM vision or a sort of like target state. And yeah, the issue with that is if you don't have a defined target state, you might simply prioritize based on sort of like who screams the loudest or what is the next urgent security fix. And you may end up in a situation where you implement these like isolated fixes or isolated solutions instead of building a coherent set of capabilities, right?

So what else is an underlying issue is that identity data or entitlement data might be incomplete or inconsistent, which makes automation very difficult. We see that processes are still manual or inconsistently defined. And this topic may create like dependencies on individual, on specific individuals within your organization, right? The knowledge owners that know how to do this process, but it's not clearly documented. It's not clearly defined. And that makes this setup like very fragile.

And on top of that, something that comes up is that communication and change management might be underestimated in IAM programs. So the key insight, it is that these IAM challenges, they are more sort of, I would call it structural and not just technological. Meaning the problem sits like in the way IAM is organized through ownership, through processes and through governance. And that leads to the conclusion that technology alone cannot, I mean, technology, that's sort of like a low brainer. Technology alone cannot fix unclear ownership or missing alignment between teams, right?

And for me, that's one reason why these programs start to struggle or under deliver. And so the question that sort of like naturally appears is like, how can we approach IAM differently? And with that being said, and to make this a bit more tangible, I created this sort of simplified and illustrative project approach. And what you can see here is that some projects, they start with some sort of like trigger. There might be an audit finding, there might be a security initiative or a business requirement. And one reaction might be the decision, okay, we need a new tool.

So the process begins with selecting and buying an IAM solution. And after that, after you bought the solution, right, hypothetical scenario, the organization defines a project scope, the timelines and implementation plan. But once this project then gets underway, it's the point where something interesting might happen. You start to like sort of see gaps, gaps start to appear. You realize that identity data is not as clean or as complete as you expected it in the first place. Or you come across that roles and entitlements are not clearly defined, or also that ownership is unclear.

Or from a process perspective that your processes are not fully aligned. And these points that I was just talking about, they are not technological issues. They are more like sort of structural gaps that simply weren't visible at the beginning when you plant your project. And so what happens next is that you need to rework, right? The scope increases, timelines may extend, and your project overall slows down. And this is exactly why those IAM programs may become more complex, more expensive, and they ultimately take longer than expected.

And my key takeaway here is that the problem is not the tool in and of itself. The problem is sort of this like mindset where we need this mindset shift of not to start with the tool, but instead first understand what capabilities do we actually need. So the shift to make is to think in capabilities first, and only then to think about tools.

Yeah, and now that we've looked at why IAM programs struggle, let's shift the perspective a bit. So instead of starting with tools and solutions, the question is, how do we actually, or what do we actually need to, what do we need IAM to deliver? And what we just saw on the previous slide is that organizations may invest in new IAM platforms, expecting improvements, but underlying issues still remain. So instead of starting with tools, we need to start with this like sort of structure. And that is where capabilities come in.

And in my experience, successful IAM programs really come down to three questions at a very high level that I put together on this slide. So the first question is, how should our IAM actually look like? And this sounds quite simple, but in practice, not all organizations have a clear answer to this, right? You need to understand what capabilities do we actually need. What does good IAM mean for your organization or for my organization, right? And this is where the reference architectures and capability models, they become very valuable because they help you to structure the whole IAM space.

They also give you a common language. And furthermore, they help to align different stakeholders, like we just saw business, security, IT, and to get a common understanding of things. And the second question is, where do we stand today? And this is where things become very real, right? Because once you start assessing your current state, you may uncover those gaps, right? Not just the technical ones, but also in processes, in governance, and also when it comes to data quality.

So for example, you may realize that identity data is inconsistent, or that entitlement models are not clearly defined, or responsibilities are simply unclear across teams. And this transparency is quite critical, because without the transparency, you are essentially navigating blindly. And the third question, which is also a very important one, is how do we move forward from here? And this is where organizations may make this sort of mistake of trying to do everything at once. So instead, what works much better is a structured phased approach.

You define a realistic target state, you prioritize based on risk, or business value, or whatever your sort of primary driver is, and you build a roadmap that closes those gaps step by step. And an important part of this is also defining responsibilities, and bringing the right stakeholders to the table, as well as making sure that ownership is clear. So when you look at these three questions together, this is where this mindset shift comes in that I was talking about earlier.

We need to think in IAM capabilities, and not just tools, because the capabilities define what you actually need to achieve, right? And only once that is clear, it makes then sense to implement the right technology.

And yeah, this ultimately gives you something important. It introduces this structured way to approach IAM, right, instead of just having another tool discussion.

Okay, so now let's move to the next step. What does a structured IAM approach actually look like? We've talked about challenges and capabilities. Now it's about bringing this together into something actionable.

Yeah, so what we've discussed so far is that IAM challenges are not just technology challenges, but a lack of structure. So the question becomes, how do we bring structure into IAM? And this is where the Köppinger Core Identity Fabric becomes very useful. And what you see here is the identity fabric. And it's not meant to be read in full detail right now, but taking as a way to structure IAM into manageable, right, into building blocks. And at the core, the dark blue section, you see that we differentiate between three different sort of layers.

So we have the capabilities, they show you what you need to be able to do. We have then next to it the services, which indicate like how you organize and deliver those capabilities. And then we have tools. So which technologies do you actually use to provide these services and how to implement them? And on the left, you see the different types of identities you need to manage, which is not just workforce, but we also have partners, customers. We have non-human identities, devices, you name it. And on the right, you see the systems IAM needs to integrate with, right, the target systems.

We have applications, platforms, infrastructure, and also legacy systems and OT. And the idea is that IAM is not just one sort of like system, but a set of capabilities delivered as services and ultimately using tools across your environment. And once you structure IAM in this way, a few things will become clearer and more visible. You will see what you actually need to build. You will also see where your gaps are and how different tools fit together into this bigger picture.

So again, instead of starting with tools, this gives you a structured way to think about IAM from an end-to-end perspective, from the user to the target system. And to take a deeper look at what those capabilities actually encompass, we have the reference architecture. And what this slide shows is the sort of like full breadth of IAM capabilities. And we can also see why this is more than IGA, right? So you see at the top, there are these four areas, which is administration, analytics and risks, authentication and authorization.

And these four areas is what most organizations typically associate with IAM, sort of like at a high level. But when you look closer into it, in this sort of like horizontal layers, you see that IAM also touches privilege capabilities, we have extended capabilities, we have integrations, also specific security capabilities and the identity API layer. And for me, this is sort of one stumbling block where programs might run into pitfalls, is that the focus might be on one domain or one tool, instead of understanding sort of like the whole set of capabilities, which are actually needed.

And if you don't have this full picture, you might miss some critical capabilities that are actually necessary. Or you may create gaps between specific areas that eventually you have to rework later. And you might end up stitching things together with a lot of rework, as I just mentioned.

And yeah, that's why having such a reference architecture is important, because it gives you like this complete map of capabilities. And it also helps you structure your program. And based on this, we can go back to the question, like what does good IAM actually look like for your organization. And this can be very different from organization to organization based on your specific requirements and based on your actual state. With that being said, I'd like to get a quick sense of where you stand today. So now we just looked at the capabilities.

I don't want to talk about like tools now, but in terms of like how structured your capabilities really are. After you saw this overview of IAM capabilities, how would you rate the maturity of your capabilities? This is sort of an intuitive impulse, right? Because we didn't have time to go into detail. But maybe you have a first indication like based on your feeling. Is it still largely reactive and ad hoc, right? Like let's say low maturity. Are there defined processes, but they are not consistently implemented? Or would you say you're already operating in a more integrated and automated way?

And of course, if it's hard to assess, that also might be a useful signal in and of itself. Let's also give it a couple more seconds here. Okay.

Next, what you see here is an example of how your, or let's say this example IAM landscape can be visualized when you map it against this structured capability model. We applied the maturity rating here. So each box you see here is, it represents a specific IAM capability. And the color indicates the current maturity where we have green, which is high maturity. So we have well-established capabilities.

We have yellow, which represents medium maturity, and we have red, which represents low maturity, and also the gray areas that are not in scope or which represents low maturity and also the gray areas that are not in scope or not yet assessed. And what sort of like typically stands out is that maturity is not uniform.

Instead, you can also see it here. It is quite uneven or fragmented, right? To give you an example, you might be quite strong in specific areas. For example, identity life cycle management. At the same time, you can see gaps in, for example, excess governance or it's red, it's low maturity, excess governance, or some authorization capabilities or the analytics part.

And with that being said, it's completely sort of like normal because most organizations, they didn't build IAM from a blueprint, but instead it evolved over time, driven by projects, driven by new tools, and also by immediate needs. But when you visualize it like this, there are two things that sort of like become clear. You see where you have real gaps, right? And where capabilities are sort of like missing or unbalanced. And once you understand that, you can prioritize much more effectively.

And you can also use this to align stakeholders around this sort of like shared view, and then ultimately build a roadmap that is well-defined, that is structured and not just reactive. And this is also where we now want to talk about the next step. So how do you move from this sort of like status quo view to a defined target state and ultimately a roadmap? So once you have this structured view of your IAM capabilities and the maturity, the next step is to translate that into priorities. And this slide shows exactly that.

On the horizontal axis, you see the maturity level of each capability, which is applied there. Which is applied there. And on the vertical axis, the priority or need for action. And with that being said, an important question you may ask yourself is, how can I define that need for action, right, or the priority? And in practice, it sort of typically comes from a combination of different factors. We have business impact. So how critical is this capability for my key processes, right? You may ask this question. Or we have risk exposure. Are there some other security or compliance gaps?

Then we also have operational pain points. So where do you see your biggest inefficiencies? Where is the most manual work? Where is the most user friction? And we also have strategic relevance, which means if this capability supports your sort of like future state, right, is this capability still relevant? Or is this something that will be not relevant in a couple of months? Then you might ignore it or simply deprioritize it. And by combining these aspects, you can then assign a priority to each of these capabilities. But this also depends on your organization, right?

Then we have the dashed horizontal line, which represents the balance point between maturity and priority. And as you can see, everything above that line indicates areas where maturity is relatively low, like compared to the need for action. Or in other words, where you should focus, right? And everything below this dotted line indicates areas that are already in a good state relatively to their importance. And what typically emerges are three clusters that are also indicated here in the different colors. So on the left-hand side, you see high priority topics.

These are capabilities with low maturity but high need for action. In this example, areas like entitlement management or access governance, we have privileged access management or NHI management that like sort of stand out. And these might be the key drivers for your roadmap. Then in the middle, you see capabilities that are already somewhat mature but still important. So these are not the critical gaps, but they are areas where areas where sort of like further improvement can still deliver value. In this example, we see identity lifecycle management or user self-service.

And the third one on the right-hand side, you find the so-called sweet spots. And these are capabilities with high maturity and lower urgency or lower need for action. They are important, but they are not where you need to invest first, right? So the takeaway is that this type of visualization helps you move from this sort of like broad capability map to a prioritized action plan. And it also allows you to focus efforts where they matter most instead of just trying to do everything at once. And this is ultimately what enables a structured and also realistic roadmap.

And another important step or the next important step is to define action items, right? Out of what we just learned. So this is an example of how one of these action items can look like. And in this case, focusing on entitlement management and a structured authorization model. And on the left, you see typical challenges, right? It says no consistent role model or limited automation. We have fragmented processes and no common language around authorization. And the goal, the project goals that we see here is to introduce a clear authorization model, typically based on roles or something else.

This will then also improve efficiency, right? By applying sort of like this structured access model. And it will also strengthen security with concepts like least privileged and segregation of duties. And to get there, you start by assessing the current state, defining specific roles and governance, and also align stakeholders to launch this sort of like initiative, right? That's what the specific action section points out. And then important impact if not done. If this is not addressed, inefficiencies and security gaps may remain.

And it becomes harder to move towards broader goals like access governance or zero trust. And yeah, this is really the key point here. It's not just defining capabilities on a slide or in some sort of framework, but the value comes from translating those capabilities into concrete, yeah, prioritized actions that can be executed. And this is how IAM becomes tangible, but also tangible, but also measurable. And in my opinion, this will lead towards a successful project approach.

And once you've defined the priorities and translated them into concrete actions, or action items, the next step is then to make this executable by putting dependencies, by putting them into dependencies, and ultimately then put them on a roadmap. Because this list of action items alone is not enough, right? You need to understand when to do what and in which sequence.

And yeah, this is where the roadmap comes into play. So what you see here is an example of how these sort of like initiatives or action items, where I just showed you the example, how they can be structured over time with clear timelines, with phases, and dependencies between those initiatives. And why is this important? Because IAM transformation or IAM programs, they can be quite broad, and it's not a single like action item that you execute. It is a set of initiatives that need to be aligned, and also they need to be sequenced, right?

So some activities can run in parallel, others depend on foundational capabilities being in place first. So the goal of this step is to turn these priorities into a realistic and also phased roadmap. And it should be one that not only considers like effort and dependencies, but also your team's capacity. And this is like ultimately how you operationalize this sort of broader IAM strategy and make sure it can actually be delivered.

All right, so let's do one last quick poll. Now it's time to look forward. After seeing this information, what would help you most to move IAM forward in your organization? Is it getting a better understanding of your capabilities by accessing them? Is it defining a clear target state? Is it building the prioritized roadmap? Or is it strengthening like processes, governance? Maybe it's improving data quality, or is it still buying a new tool, which might be true.

And again, just pick the option that resonates most with your current situation. Yeah, and let's leave it here a couple of seconds.

Yeah, all right. So before we close, let me briefly summarize the key takeaways from today.

Yeah, so let's reflect on the message I've been building throughout this session. So first, the most important takeaway from my perspective is that IAM challenges are not just technological. In organizations, the instinct might be to add another tool, but we learned that tools alone won't fix IAM. But what makes a difference is clear ownership, clear processes, and a good understanding of what IAM should actually deliver, right? We need to have a structure.

Second, this leads to a mindset shift. Capabilities come first and tools come second. So instead of starting with technology, you may start by asking, what do we actually need IAM to do? Another question might be, then what capabilities are required to support the business teams, the security, and also compliance requirements? And only after that, you decide how to deliver those capabilities through services, right? And then ultimately by choosing the right tools. And the third point is about execution, but realistic execution.

So what I see is that organizations may, not all, some may jump straight into large IAM programs without putting the foundations in first place, right? So a lot of value can be unlocked before the program even starts. These are things like aligning the right stakeholders or clarifying ownership, also to establish a common understanding of goals and priorities, and very practical cleaning up what already exists, right? Think of it as like cleaning out your closet to improve data quality, reduce obvious issues, and bring some structure into existing processes.

And these foundational steps, they are usually not that glamorous, but they reduce complexity, and they also reduce risks that might appear in the project later on. Yeah, so overall, what we are really talking about is this sort of like shift from reacting to IAM complexity to managing IAM in a structured, capability-driven way.

Yeah, and that already brings us to what's the end of this session. And now I'd like to open it up to you. I'm interested in your perspectives, in your questions, and also your experiences, as well as the poll results, of course.

So again, feel free to use the chat to post your questions. I'm also happy to go deeper on any of the topics. Let me just see what I have here. Some related research, but you will also get the slides afterwards. And if you want to discuss these topics in more detail, I will be in Berlin at the EIC conference in May this year. So you can also book a session there So you can also book a session there with me, and then we can also discuss some practical insights.

All right, give me a second to look at the chat. So our first question was, what would help you?

No, that was the last one. Okay, let's start with this one. So the first question was, what's your biggest challenge in IAM today? And we have 33% with too many competing priorities or limited resources. Then we have 26% lack of clear strategy or target architecture. Then we have unclear ownership, too complexity, and last but not least, poor identity or entitlement data quality. I find the point interesting that, yeah, most of you voted for too many competing priorities or limited resources, which is exactly the pool that I like described in the first place.

I also have a background in enterprises, and this is also what I sort of like experienced in IAM, right? Because sometimes you have all of these things on the table, everything is super urgent, you need to get everything done tomorrow.

And yeah, these competing priorities can be a real challenge. So that's why prioritization is so important. Let's take a look at the second one. How do you currently prioritize IAM investments? We have 38% based on security risk reduction, followed by based on compliance audit requirements. 21% don't have a prioritization approach yet. Then we have the urgent business needs with 8% and based on a defined target set only with 4%.

And yeah, what we see here, based on the poll, is that security risk reduction is the primary driver based on the voting, which of course makes sense. I mean, if someone would ask me, I don't have a prioritization approach yet, where should I start? I would say start with your high risk gaps, right? I think that just makes sense. Then we of course have compliance driving requirements. And we still have some who have a defined target state, which is actually, yeah, which is actually great, because then you can also resolve the issue that you have too many competing priorities.

So what do we have next? How would you rate the maturity of your IAM capabilities today? We have 54% medium maturity, so they are defined processes, but inconsistent. We have 29% with high maturity, which is great. We have 17% with low maturity and 0% difficult to assess. And these 50, sorry, no, it's 54.

Yeah, I'm mixing German and English now. 54% medium maturity, which is what I described that, I mean, this was just a very impulsive first indication. And this basically shows that maturity can be sort of a mix, right? There might be topics that are going well, there might be topics that are going not so well.

But yeah, overall, this is sort of like a common view. Then the last question is what would help you most to move your IAM forward? We have 27% strengthening governance, ownership and processes. Then we have 23% assessing IAM capabilities. Same 23% defining a target state, 18% building a prioritized roadmap, 5% improving data quality and 5% buying a new tool still.

But yeah, that's that is also nicely aligned with what I said at the beginning. If we strengthen the processes, right, the ownership, the governance, this will, in my perspective, also help to move IAM forward, right? And this also indicates that we need that the sort of like structural approach will also support to help your organization forward. Because if you have clear ownership, people who take accountability, they can also drive things forward.

If the processes are clear, there will not be so many questions, not so much confusion, for example, with the end users, and then the adoption will also increase. All right, thank you so much for voting on the polls. Let me see if there is a question that I can take. Give me one second.

Okay, we have one question from Alberto. There are other ones, but this one, how should the adoption of decentralized identity technologies be factored in IAM plans, coexisting with current federation identity investments?

Yeah, interesting question. Thank you. So this is something where I would highly recommend you to, yeah, visit EIC, because there is a whole track about decentralized identities. And this would be the perfect place to learn more about this and also to raise your questions. With that being said, I would like to thank you for your time. One more thing is that I want to share my yeah, my LinkedIn with you or my email address. So if you have further questions, you can reach out to me. You can connect with me on LinkedIn. That's what I'm trying to say.

And if you're interested, I would be happy to meet some of you at EIC and shake hands in reality. And yeah, with that being said, thank you for your time and attention and hope to see you soon.