Most organizations rate themselves a level higher on IAM maturity than the evidence supports. This guide defines the 4 maturity levels by what you can prove, not what you aspire to, with an evidence test for each level.
Maturity models have a credibility problem, and it's self-inflicted. The classic format describes each level in adjectives: level 1 is "chaotic," level 3 is "proactive," level 4 is "optimized and ingrained in culture." Teams read the descriptions, recognize fragments of themselves in the higher levels, and self-assess accordingly. The organization that runs quarterly access reviews (covering the applications its IdP happens to know about) reads "proactive risk anticipation" and files itself at level 3.
Then an audit, or an incident, applies a different test: not "how would you describe your program?" but "show me." Show me the deprovisioning timestamp for every departure last quarter. Show me the review record for that service account. Show me the complete application inventory. The gap between the described level and the demonstrated level is usually one full level, sometimes two.
So this guide defines the four maturity levels the way an auditor or an attacker would: by what the program can demonstrably do, with an evidence test for each level across the three dimensions that matter (visibility, lifecycle management, and governance). Use it as a self-assessment instrument, not a brochure.
How to Use This Model
For each level, check the evidence criteria against what your program can produce today, not what's on the roadmap. Your level is the highest one where you meet all the criteria, not the highest one where you meet some. A program with excellent automation but a 65%-complete inventory is a level 2 program with good tooling, because everything downstream of the inventory inherits its gaps.
The three dimensions assessed at every level:
Visibility: how completely you know your identity population (human and non-human) and application estate.
Lifecycle: how reliably access is provisioned, updated, and revoked as identities join, move, and leave.
Governance: how continuously access appropriateness is verified, and what evidence that verification produces.
Level 1: Ad Hoc
Identity and access management happens, but as a side effect of other work rather than as a program. Access is granted by whoever owns the application, through whatever channel the request arrives in. Offboarding runs on a checklist that covers the accounts IT remembers. Nobody can say with confidence how many applications are in use.
What it looks like in practice: a new hire's manager emails IT and three application owners to get them set up. A departing employee's known accounts are closed within a week; the unknown ones are never closed. An auditor's request for an access roster triggers a two-week spreadsheet-assembly project with known gaps.
Evidence test (level 1 is the floor; you're here if you cannot pass the level 2 test):
- No reconciled application inventory exists.
- Provisioning has no consistent approval record.
- Deprovisioning completeness cannot be demonstrated for the last quarter's departures.
- No access review has been completed in the last 12 months, or reviews exist only as informal spot checks.
The exit move: build the inventory. Nothing else at level 1 is worth fixing first, because every fix applied to a partial inventory is a partial fix. Discovery through multiple methods (not just the IdP catalog) is the entry ticket to level 2.
Level 2: Defined
The program exists on paper and partially in practice. There is an IAM policy, role definitions for the major job families, and provisioning that runs through a defined workflow for the core applications. The IdP is deployed and the SCIM-connected applications are under lifecycle automation. The gap: the defined program covers the visible, well-behaved portion of the estate, and the rest runs on level 1 rules.
What it looks like in practice: onboarding works smoothly for the 40 SSO-connected applications and by email for the other 60. Access reviews happen, on the IdP's population. Deprovisioning is automated where SCIM reaches and manual (with the usual failure rate) where it doesn't. Orphaned accounts accumulate specifically in the applications outside the automation perimeter.
Evidence test (you're at level 2 if you can produce all of these):
- A documented, management-approved IAM policy with specific rules (SLAs, review cadences, SoD pairs), not just principles.
- Role definitions mapped to entitlements for core applications.
- Provisioning records with approver attribution for workflow-processed grants.
- Access review completion records for at least the IdP-visible population, on a defined cadence.
What keeps you here: the inventory boundary. Level 2 programs typically govern 60 to 80% of the real estate and have limited insight into the remainder: non-SCIM applications, shadow SaaS, contractor accounts provisioned outside the workflow, and effectively all non-human identities.
The exit move: close the gap between policy scope and enforcement scope. That means discovery that surfaces the ungoverned estate, and integration reach that brings non-SCIM applications under the same lifecycle automation as the federated ones.
Level 3: Managed
The program's enforcement scope matches its policy scope. The identity inventory is complete and continuously updated, including non-human identities. Lifecycle automation covers the full application estate, so deprovisioning SLAs are met across everything a departing user touched, not just the IdP's subset. Access reviews cover the full population, and flagged items get remediated because automation can execute the revocations.
What it looks like in practice: a departure triggers deprovisioning across every connected application within the SLA, with a timestamped record. Access reviews run at defined scopes (by application, by group, by user) against the complete inventory. SoD conflicts are checked across applications, not just within the ERP. The audit evidence package is an export, not a project.
Evidence test (you're at level 3 if you can produce all of these):
- A reconciled identity inventory including NHIs, with the IdP-versus-reality gap measured and closed.
- Deprovisioning SLA compliance at or near 100% across the full inventory for the last quarter, with timestamps.
- Access review completion and remediation records covering the complete population, including service accounts and contractors.
- A cross-application SoD ruleset with detection and remediation records.
- Day-one provisioning evidence for role-based access.
What keeps you here: cadence. Level 3 governance is thorough but interval-based. Drift that occurs between review cycles (a risky OAuth grant in week 2 of a quarter, a permission accumulation after an informal role change) waits for the next cycle to be caught. The program is complete in space but not in time.
The exit move: continuous monitoring. Risk detection has to move from the review calendar to the event stream.
Level 4: Continuous
Governance runs in the present tense. The identity estate is monitored continuously for risk signals: dormant accounts, permission drift, SoD conflicts, anomalous access patterns, risky new OAuth grants. Findings trigger remediation as they emerge, so the formal review cycles (which still run, for the compliance record) find progressively less. Posture is a live dashboard with a trend line, not a quarterly report.
What it looks like in practice: a service account that goes dormant for 60 days is flagged and scoped for retirement before any review cycle asks about it. A permission combination that creates an SoD conflict is detected the week it's granted. The board question "what is our identity risk posture?" has a current, quantified answer. Audit findings trend toward zero because the audit examines a continuously remediated estate.
Evidence test (you're at level 4 if you can produce all of these):
- Continuous risk detection records: findings surfaced and remediated between formal review cycles, with time-to-remediation metrics.
- A declining trend line in findings per review cycle over at least a year.
- Posture metrics (orphaned account rate, standing privilege footprint, NHI review coverage) tracked as live indicators with owners and targets.
- Compliance evidence exportable on demand for every framework in scope, with no pre-audit assembly phase.
What level 4 is not: a static achievement. The identity population keeps changing (AI agents are the current frontier), so a level 4 program is defined by its ability to bring new identity classes under continuous governance quickly, not by having finished.
Where Organizations Actually Land
Applied honestly, this model produces a humbling distribution. Most organizations with a deployed IdP and a written policy self-describe as level 3 and test at level 2, because the evidence criteria expose the inventory boundary: the reviews, SLAs, and automation are real but cover a subset of the estate. Genuinely level 3 programs are the minority; level 4 programs are rare and concentrated among organizations that treated identity as a security control surface rather than an IT admin function.
The useful takeaway is not the label but the diagnosis. The evidence test tells you which specific artifact you cannot produce, and that artifact is the next project: the inventory (1→2), the enforcement-scope gap (2→3), or the monitoring cadence (3→4). Maturity advances one missing artifact at a time. The IAM audit readiness checklist operationalizes this same evidence-first logic as a runnable instrument, and the IAM strategy guide sequences the projects.
How Zluri Moves Programs Up the Model
Zluri is an identity security platform whose architecture corresponds to the level transitions, which is why its typical effect is moving a program two levels in one deployment cycle of 2 to 3 months.
The 1→2 and 2→3 transitions both run on visibility and reach. IVIP, Zluri's identity visibility and intelligence layer, builds the complete inventory through 8 discovery methods, surfacing the shadow applications, non-SCIM tools, contractor accounts, and non-human identities that define the level 2 boundary. The Access Management module then extends lifecycle automation across that full inventory (300+ integrations, over 1,500 granular workflow actions, SCIM and non-SCIM alike), which is precisely the enforcement-scope closure that level 3 requires. Access Reviews at application, group, and user level cover the complete population, and the Segregation of Duties module runs the cross-application conflict detection that level 3's evidence test demands.
The 3→4 transition runs on IRIS and Zluri's Identity Security Posture Management: continuous monitoring of the identity estate for dormant accounts, permission drift, SoD conflicts, and risky grants, with automated remediation so findings close in days rather than waiting for the next cycle. Every action generates the timestamped evidence that makes level 4's export-not-assemble compliance posture real.
One scoping note: Zluri sits above your identity provider, not in place of it. Authentication, SSO, and MFA remain the IdP's job. The maturity dimensions this model assesses (visibility, lifecycle, governance) are exactly the layer Zluri owns.
Book a demo and run the evidence test against your actual estate
Frequently Asked Questions
What are the levels of the IAM maturity model?
Four levels: Ad Hoc (identity work happens reactively with no program structure), Defined (a documented program covering the visible portion of the estate), Managed (enforcement scope matches policy scope across the complete inventory, including non-human identities), and Continuous (risk detection and remediation run in real time, with formal reviews serving as the compliance record over an already-clean estate). Each level in this model is defined by evidence criteria rather than descriptive adjectives.
Why do organizations overestimate their IAM maturity?
Because descriptive maturity models invite self-assessment against aspirations, and because the most common gap (the boundary between the governed inventory and the real inventory) is invisible from inside the program. A team that runs disciplined reviews over its IdP's population experiences itself as thorough; the 20 to 40% of applications outside the IdP's view don't generate any signal that contradicts that experience until an audit or incident does.
How long does it take to move up a maturity level?
The 1→2 transition (inventory plus documented policy) can be accomplished in 4 to 8 weeks with modern discovery tooling. The 2→3 transition depends on integration reach: extending lifecycle automation across the full estate takes 2 to 3 months with a platform built for non-SCIM coverage, and substantially longer with connector-development-heavy legacy suites. The 3→4 transition is primarily a tooling capability (continuous monitoring with automated remediation) and lands within the same deployment when the platform supports it.
Is level 4 necessary for every organization?
The compliance floor for most regulated organizations is a solid level 3: complete inventory, full-scope lifecycle automation, and review cycles with remediation evidence. Level 4 is increasingly the expectation for organizations where identity is a primary attack surface concern (which, given current breach patterns, is most organizations above a few hundred employees) and for those facing mature audit regimes that probe between-cycle behavior. The cost gap between running level 3 and level 4 has also collapsed: continuous monitoring is a platform feature now, not a program.
How does this maturity model relate to an IAM strategy?
The maturity model is the assessment instrument; the strategy is the plan it informs. Running the evidence test tells you which level you're at and which specific artifact you can't produce. The strategy sequences the work to produce it: visibility first, then policy, then automation, then continuous governance, which corresponds to the level transitions in order. See the IAM strategy guide for the sequenced roadmap.
Do non-human identities affect maturity scoring?
Directly. In this model, a program cannot test at level 3 without NHIs in its inventory, its review scopes, and its deprovisioning logic, because a "complete" inventory that excludes the largest identity population isn't complete. This is deliberately stricter than older maturity models, which were written when machine identities were a footnote. In 2026 they are the majority population, and a maturity model that ignores them certifies programs against the estate of a decade ago.
.svg)
