Intro  

“We’ll just use groups.” That’s how many IAM projects begin.  

It sounds like a sensible approach, and for a while, it usually works. Then the organization grows, it brings in more applications and starts accumulating additional exceptions. Before you know it, managing access becomes much more difficult than anyone expected. 

At some point – and especially once problems start appearing – many organizations start asking themselves where they are in their IAM journey. That’s what an IAM maturity model helps answer.  

In this article, I’ll walk through the different stages, explain where organizations typically get stuck, and share what I’ve learned from helping them move forward. By the end, you’ll have a better understanding of where your organization stands today and what the next step should be. 

In a nutshell:  

What is IAM maturity – and why does the score matter? 

Identity and access management maturity describes how well an organization manages identities and access. It shows how far it has gone from manual, disconnected processes to a structured approach that’s built on clear ownership, governance, and automation. 

IAM maturity is how far an organization has progressed from ad-hoc, manually managed access toward automated, policy-driven, continuously verified identity control. A maturity model maps that journey into stages so you can benchmark where you are and prioritize what to fix next. 

Now, I’d like to pose an important question here, straight away:  

Can an organization have a successful IAM implementation and still score low on maturity? Yes, because delivering a platform on time and within scope doesn’t necessarily mean identity is managed consistently across the whole business. 

That distinction has become much more important in recent years. Regulations such as NIS2, DORA, and ISO 27001 expect organizations to demonstrate control over identities and access. At the same time, every new application, cloud service, or acquisition adds more identities and permissions to manage, making it harder to maintain that control. 

From my experience, maturity depends just as much on ownership, governance, and business processes as it does on technology. Some of the biggest gaps remain invisible for years because nobody has looked at identity from an organization-wide perspective. They only become apparent during an audit, after a merger, or when another IAM project uncovers them. 

The, perhaps encouraging, news is that low maturity isn’t unusual. Every organization starts somewhere, and the first steps often bring the biggest improvements. A structured approach helps you uncover the issues that have been holding the program back, prioritize them, and build a stronger foundation for everything that comes next. 

The IAM maturity model – understanding the journey 

I recently came across a LinkedIn post by Josh Sargel, Head of Identity & Access Management at 3M, that presents a nine-level IAM maturity ladder. This framework resonates strongly with me, because it reflects how IAM programs typically evolve in the real world. Namely, organizations solve one challenge only to uncover the next. Here are the steps Sargel mentioned, along with my observations from working with IAM programs over the years.  

IAM maturity ladder – the nine key steps 

Level What it looks like 
1. Groups Access relies on security groups with little governance. 
2. Group sprawl Groups multiply until ownership and purpose become unclear. 
3. RBAC Access starts to follow business roles instead of individual requests. 
4. Role explosion Poor role design recreates the same complexity as groups. 
5. ABAC Access decisions rely on attributes rather than static roles (RBAC vs ABAC). 
6. Governance Access governance introduces ownership, certification, policies, and least privilege. 
7. Non-human identities Non-human identities such as service accounts and bots become part of identity management, following the same least privilege principles. 
8. Zero Trust Zero Trust continuously evaluates access based on context and risk. 
9. Identity as the control plane Identity becomes the foundation of security across the organization. 

Here are a few of my main findings that refer to this proposed 9-step structure. 

Most organizations spend longer than they think in the early stages 

When we start working with a new client, I usually find them somewhere between Levels 1 and 4. Every now and then, I see elements of Level 5, such as dynamic access based on user attributes, but it’s still rare to find an organization that has adopted a mature, organization-wide approach to identity. 

Part of the reason is simply how IAM has changed. For years, organizations focused on automating joiner, mover, and leaver processes or group management. Governance wasn’t the priority, because there were fewer regulatory requirements. Also, cyber threats weren’t as sophisticated, and identity wasn’t yet viewed as one of the core pillars of security. 

Today, the situation looks very different. Organizations need stronger control over identities and access, but many still don’t have the experience or internal expertise to design a long-term identity strategy. That’s why so many programs get stuck in the early stages of the maturity ladder. 

The biggest mistake? Turning 4,000 groups into 4,000 roles 

One of the most common traps is when organizations move from groups to role-based access control. Instead of simplifying access management, they recreate the same problem under a different name. That’s where the four thousand groups mentioned by Sargel become four thousand roles, and very little actually changes. 

From my experience, a successful RBAC implementation starts with the business, and not with the technical permissions. That’s also the reason why role mining is such an important step. The goal is to understand how people work and build roles around business functions instead of individual entitlements. 

Take someone in marketing as an example. They shouldn’t have to know they need access to Google Analytics, Figma, SharePoint, Jira, and several other systems. They simply request the appropriate business role. Behind the scenes, that role needs to map to everything they need to do their job. 

When you design roles this way, thousands of technical permissions often become a few hundred meaningful business roles.  

I would argue that the hardest part is cleaning up years of accumulated exceptions and legacy decisions. That usually requires organizational change, and that’s also where many initiatives lose momentum. 

Maturity depends on both technology and governance 

Many organizations that find themselves in access management trouble start by looking for a new IAM platform. I usually recommend taking a step back first. 

Before choosing a tool, you have to understand your business processes, know where the biggest gaps lie, and define what success looks like for your company. Only then will it make sense for you to compare platforms. 

I’ve seen situations where organizations selected a solution simply because that’s what a particular implementation partner specialized in. In my opinion, the process should work the other way around. Choose the tool that fits your organization, because every company has different priorities, budgets, and expectations. The “right” answer depends on much more than a feature list. 

Don’t overlook identities that aren’t people 

Service accounts, bots, APIs, suppliers, and contractors all need the same level of attention as employees. 

A good starting point is to extend your JML processes to these identities as well. Every account should have: 

Non-human identity accounts should have an expiration date or a review cycle, just like employee access does. That simple change makes it much easier to keep the environment under control as the number of identities continues to grow. 

How do you actually assess your IAM maturity score? 

If you want to properly measure identity and access management maturity, you cannot rely on a single gut-feel number or treat it as a one-time compliance checkbox. Instead, you need to look at specific operational dimensions and uncover your hidden risks and structural gaps. An accurate IAM maturity assessment helps you evaluate how identities move through your organization, how your team approves access, and whether your critical systems stay protected from unnecessary exposure. 

Core assessment domains 

When you look at established scoring models, they check your identity posture across four distinct dimensions: 

Diagnostic questions: spotting your gaps 

Answering a few practical diagnostic questions will help you surface immediate blind spots before you dive into a formal audit: 

  1. How long does full provisioning take for your new hires, and what percentage of JML tasks require manual IT work? Automated JML processes save you time, but your coverage matters just as much. If your automation covers internal staff while leaving contractors, temporary guests, or non-human accounts (NHIs) completely unmanaged, you leave a major security gap wide open. Once an attacker compromises an unmonitored guest account, climbing the ladder toward higher privileges gets much easier. 
  1. Are you recording administrative and third-party sessions for full auditability?Privileged access management demands strict controls. You need real-time oversight and session recording for high-level accounts so your security team maintains complete visibility into every administrative action. 
  1. How do you manage system and application access – through structured role models or one-off approvals? Granting permissions on a piecemeal, permanent basis leads straight to access collection. If you don’t run mandatory access reviews every six to twelve months, your users will naturally gather excess rights over time. 
  1. How much password sprawl are your users dealing with every day? Forcing people to manage dozens of separate credentials creates constant friction and bad password habits. When you consolidate login flows through a well-secured Identity Provider (IdP) with Single Sign-On (SSO) and robust MFA, you strike the right balance between smooth daily usability and strong, centralized protection. 
  1. Can your current setup instantly handle access changes during a sudden organizational shift or M&A deal? Your identity systems need enough built-in flexibility to onboard hundreds of new accounts or adapt to fresh compliance rules without breaking your existing security policies. 

Want to put a clear benchmark on your core dimensions? Run through One Identity’s free IAM Maturity Survey. It scores your IAM maturity score across these operational domains in just six targeted questions, giving you an immediate baseline for your next team discussion. 

Why IAM maturity still eludes most organizations 

Although cybersecurity budgets are rising along with strict regulatory pressure, many organizations still hit an invisible ceiling. They start with strong momentum, only to stall halfway up the IAM maturity model. They buy enterprise-grade software, yet daily operations remain messy and security teams still struggle to answer basic audit questions. 

Why do so many identity initiatives hit a wall? 

Reaching advanced maturity takes more than acquiring licenses. Most plateaus happen because of structural missteps: 

What high performers do differently 

Those who want to break through an identity plateau should shift away from quick fixes toward real access governance. Organizations that actually climb the ladder look at the problem through a practical, battle-tested lens: 

Moving up the ladder requires identity management as a continuous discipline. Process alignment with real access habits builds an identity architecture that stays secure, compliant, and ready to scale. 

From score to plan – how to climb the next rung 

Nobody jumps from level 2 straight to level 9. IAM maturity is a step-by-step climb, and the goal for any given quarter is simply to reach the next rung. 

Moving forward requires shifting from a raw score to a targeted action plan. A proper IAM maturity assessment does not just hand over a number; it uncovers the operational gaps holding the organization back. 

When I advise IT and security teams on their next move, the starting point always depends on where they currently stand on the ladder. For teams sitting between levels 1 and 4, progress comes down to answering two fundamental questions: How do I handle things right now? and How should they look instead? 

My approach focuses on finding the root cause rather than treating surface symptoms: 

Answering these core questions creates a clear roadmap. Plugging these gaps automatically moves the organization up the ladder. 

Get your real maturity picture with QWEY 

An IAM maturity survey gives you a rough number, but a thorough IAM maturity assessment uncovers root causes and outlines exact steps to take. The move from self-assessment to expert evaluation bridges the gap between a score and a fix for underlying gaps. 

Partner with QWEY for dedicated IAM consulting to get a clear roadmap tailored to your environment. Share the current setup and top challenges to receive a suggested plan with rough estimates within days – completely free with no obligation. 

Book a free 60-minute consultation 

FAQ  

What is an IAM maturity model? 

IAM maturity model is a framework to check where an organization actually stands with identity and access security. Instead of guessing, it measures processes, like user onboarding, privileged access, and permission reviews against clear standards to show what works, where security gaps hide, and what step to take next. 

How do I measure my IAM maturity score? 

Forget gut feelings. A real score comes from asking hard questions about daily operations across key areas: 

What are the levels of IAM maturity? 

Most models break progress down into logical stages: 

What’s the difference between RBAC and ABAC? 

RBAC assigns access based on predefined roles, while ABAC makes access decisions based on attributes such as department, location, or employment status. In practice, the two models solve different problems: 

Many mature IAM programs combine both approaches, using RBAC as the foundation and ABAC where more flexibility is needed. 

Why do most organizations get stuck on IAM maturity? 

Most organizations get stuck because IAM maturity depends on governance, ownership, and business processes as much as it does on technology.  

From my experience, technology is rarely the biggest obstacle. Organizations often lack clear ownership of identity, carry years of legacy access and inconsistent processes, or underestimate how much organizational change an IAM program requires. As a result, they implement a platform but never address the underlying issues that limit progress. That’s why many companies remain in the early stages of maturity, even after investing in IAM. 

How long does it take to move up a maturity level? 

There’s no fixed timeline because every organization starts from a different point and faces different challenges. The pace depends on factors such as: 

Some organizations make noticeable progress within a few months, while larger transformation programs can take years. The goal is to build a solid foundation that supports the next stage of maturity, and not just pacing up the ladder regardless of the consequences. 

I recently came across a social media debate that perfectly captures a dilemma we face in the IAM community – where exactly does the line sit between partial success and partial failure? Practitioners rarely agree on when a project actually crosses the finish line as a success. And this is the question I am going to take a closer look at today. 

To clarify the scope, my analysis focuses on deep IAM and Identity Governance and Administration (IGA) deployments – specifically complex platforms like One Identity Manager – rather than standard Single Sign-On (SSO) or basic access tools like Microsoft Entra. 

In my experience, true identity management project delivery success means client satisfaction at the tail end of the deployment, backed by clear business value. The platform must deliver faster, better processes. For example, shorter onboarding times, smoother compliance audits, and more integrated applications. 

In a nutshell: 

Defining IAM project success – why practitioners rarely agree 

I have been in the IAM space long enough to know that project success is highly subjective, and the definition changes depending on the engagement model. 

Success in staff augmentation vs. full identity transformation 

When a client hires my team simply for extra hands on deck – as pure staff augmentation – success is straightforward. We deliver the requested labor, the client remains satisfied, and they pay the invoice. 

But a true identity transformation requires a completely different benchmark. I cannot measure this type of success on the day of go-live. Instead, I evaluate the implementation months or even a year down the road to see how the platform actually operates. 

The three signs of long-term IAM success 

A successful identity management project delivery reveals itself through long-term operational health: 

Three signs of long-term IAM project success – role stability, process discipline, team capability

A common, critical mistake is to buy a complex IGA tool and assume a single system administrator who previously managed Active Directory can run it alone. This approach fails, pretty much always. 

The most common reasons IAM projects fail 

In major deployments, failure rarely comes from a single catastrophic mistake. It accumulates from predictable issues that most organizations recognize too late: 

Skipping the discovery phase 

Many organizations skip a dedicated discovery phase and go straight to budgeting. That’s little more than an educated guess. Estimating the exact effort before a thorough discovery is incredibly difficult, and those estimates almost always miss what’s actually hiding in the environment. 

Assumptions vs. reality: when clean data doesn’t exist 

Typical project agreements assume the client will provide clean HR data, assign system owners, and organize internal stakeholders before the implementation begins. Many consulting firms treat these clauses as legal shields. If a deadline slips or the budget runs over because the client failed to meet these prerequisites, these vendors simply point to the contract, secure in their legal coverage, and charge for change requests. 

I take a different approach. I actively discuss these critical IAM project management success factors with the client on day one. 

For example, clients often begin to clean their data just two weeks before the scheduled launch. They quickly discover thousands of Active Directory groups with names like “AD_Group_0015” that have no designated owner. Locating those owners and cleaning that data can easily take six months. When this happens, the entire project grinds to a halt. 

Cohesive teams vs. paper experts 

Ultimately, the people on the project dictate the outcome. My practice relies on a tight-knit, internal team of experts with proven, collaborative experience. 

In contrast, large consulting firms frequently assemble a group of strangers specifically to staff a new contract. They select people based on impressive resumes. However, fifteen years in IT looks excellent on paper but guarantees absolutely nothing if the individuals cannot deliver as a cohesive unit. These assembled collections of contractors represent a massive risk, and they fail far more often than structured, experienced teams. 

How to plan an IAM project that doesn’t fail 

Start with measurable business goals, not security slogans 

Many organizations kick off an IAM initiative because they want better security. That’s a reasonable goal, but it doesn’t make a strong business case. Security alone isn’t measurable, and if you can’t define success before the project starts, you won’t know whether you’ve achieved it. 

From my experience, successful IAM project management success factors start with specific business problems. You can ask questions like: 

These objectives give everyone a shared definition of success. 

Run a dedicated IAM assessment before budgeting 

Build an initial budget, but make it clear that it’s preliminary. Once you’ve analyzed the current identity landscape, application inventory, business processes, and technical constraints, you can produce a more realistic implementation plan. That estimate may increase by 20%, 50%, or even more, but that’s far better than committing to unrealistic expectations that will derail the project later. 

Deliver an MVP first: JML + critical applications 

Many organizations try to deliver every IAM capability – provisioning, certification campaigns, access reviews – in a single implementation. That approach rarely works. 

Instead, I recommend delivering a focused MVP first. In many projects, that means implementing the Joiner, Mover, Leaver (JML) lifecycle together with identity provisioning for a limited number of critical applications (often around ten). Once the platform proves its value, you can expand into access reviews, certification campaigns, additional integrations, and more advanced governance capabilities. 

The 80/20 rule for automation 

When planning the IGA implementation timeline, trying to automate every single edge case from day one is a recipe for project delays. I always advise clients to apply the 80/20 rule, especially when building a Minimum Viable Product (MVP). 

We prioritize automating the standard 80% of daily transactions and handle the highly complex, rare exceptions differently. 

The 80/20 automation strategy 

Process Phase Automation approach 
The standard 80% Full automation. Standard joiners, lateral movers, and standard terminations execute instantly without human intervention. 
The complex 20% Semi-automated notifications. Instead of spending weeks programming a highly complex automation for a rare scenario, we automate the detection of the event and trigger a notification requesting manual intervention. 

This hybrid approach keeps the project moving. If a client is not operationally ready for fully automated decision-making on complex exceptions, we do not force it. Instead of manual spreadsheets, we use the system to flag the exception and assign it to a human owner. This strategy is one of the most critical IAM project management success factors, which keeps the initial launch simple, clean, and on schedule. 

Phased IAM means more time to build experience 

An ideal scenario is when an organization gradually takes ownership of application integrations, while the implementation partner continues to provide guidance and quality assurance. That creates a much more sustainable identity management project delivery model than handing everything over at the end of the project. 

Don’t underestimate the complexity hiding beneath the surface. Modern IAM projects extend beyond employee identities and also cover: 

Currently, they often represent a significant portion of the identity ecosystem, but many business cases barely acknowledge them. The same applies to application integration. Legacy applications and decades of technical debt can dramatically change the implementation effort. 

The earlier you identify these complexities, the more realistic your roadmap becomes. 

Why every successful IAM project starts with an assessment 

An IAM assessment answers the question: what does your identity environment actually look like today? 

Before you automate anything, you need a clear understanding of your systems, data, and processes. Otherwise, you’ll build workflows around assumptions. 

What an IAM assessment covers – step by step 

The four steps of an IAM assessment – inventory, review, map, outcome

You start off with inventorying systems and business processes. Then, you run a review of your HR data, Active Directory, access policies, and the roles that exist. This lets you understand how identities move through the organization. 

From there, map out the entire user lifecycle. This means covering all the steps from onboarding and access provisioning to role changes and offboarding, to identify any potential inconsistencies and bottlenecks. 

Of course, most organizations don’t start from scratch. Many already have someone internally who has researched IAM and defined a target state before bringing in someone to handle the implementation itself.  

In those cases, the role of an experienced IAM implementation partner is to validate the assumptions, identify any gaps, and make sure the implementation reflects the organization’s real environment. 

What standardized identity lifecycle (JML) processes look like in practice 

In theory, every organization has a policy for managing how employees enter, move through, and exit the company. The Joiner-Mover-Leaver (JML) process defines this identity lifecycle. Unfortunately, in practice, these JML processes often exist only on paper. 

A mature, well-functioning identity lifecycle must be standardized, automated, and highly resistant to ad-hoc workarounds. When I evaluate an organization, I look at the operational backbone. True stability relies on practical tools like RACI charts (Responsible, Accountable, Consulted, Informed), gap analysis templates, and rigid process templates. These tools turn abstract security policies into a repeatable, daily reality, which directly impacts the overall identity management project delivery. 

What to look for in an IAM implementation partner 

A good IAM implementation partner should be accountable for more than just technicalities. Look for a team that: 

For reference, one of the smoothest projects I’ve worked on succeeded because both sides worked as partners. We discussed risks early, agreed on priorities, and had open communication throughout the implementation. 

It was a two-way street, because the client also trusted our recommendations instead of treating us purely as extra hands. That allowed us to solve problems before they turned into blockers. 

If I were to add something unorthodox to the list above, I’d say that another good indicator of the right partner is their willingness to say “no.” 

I often advise clients against customizing IAM processes unless there’s a strong business reason. The more exceptions you introduce, the harder the solution becomes to maintain, extend, and upgrade. 

I remember one project where a client wanted to use a built-in SCIM connector for Workday while also heavily customizing the data after it arrived. At that point, the standard connector added very little value because the custom logic became the real implementation. We recommended simplifying the underlying process instead. The client decided against it because there wasn’t enough time to change the business process, which ultimately made the solution more complex. 

The best implementation partners explain the trade-offs and push back when necessary. You might not like their answer in the given moment, but that’s the aspect that influences successful identity management project delivery over the long term. 

Why the human layer decides IAM success more than the technology does 

This is, arguably, the most heated topic on IAM-related forums. And I understand why, because technically sound IAM projects often struggle when the organization isn’t ready for the change. This exposes that, right next to the more apparent technical gap, companies are also struggling with organizational ones. As one Redditor said, “people make or break an IAM program“.