By NHI Mgmt Group Editorial TeamBased on Zluri: “Identity & Access Management Maturity Model - A Guide For 2026” (March 12, 2026)

TL;DR: IAM maturity models still assume identities are comparatively stable, reviewable, and lifecycle-managed, but AI agents and other non-human identities expose gaps in provisioning, access review, and governance that human-centric programmes often leave uneven, according to Zluri research. Maturity now depends on governing identities that act at runtime, not just ones that can be reviewed later.


At a glance

What this is: This is an analysis of IAM maturity models that shows why staged IAM programmes break down when AI agents and other non-human identities enter the access model.

Why it matters: It matters because IAM, IGA, and PAM teams cannot treat AI agents like delayed-review human accounts; lifecycle, privilege, and governance controls need to reflect runtime behaviour.


Context

IAM maturity models describe how an organisation moves from ad hoc access handling to more controlled, governed, and optimised identity processes. The problem is that many of those models were built around human users, where access changes are slower, review cycles make sense, and policy assumptions stay relatively stable.

The article's central claim is that AI agents and other non-human identities expose the gaps in those assumptions. When identities can request, use, and release access in machine time, maturity has to be measured by whether governance works at issuance and runtime, not just by whether it exists on paper.


Key questions

Q: What breaks when identity maturity models exclude NHIs and AI agents?

A: They misstate the real control boundary. Human review cadences, onboarding workflows and compliance checks do not govern service accounts, secrets or agent credentials unless those identities are explicitly in scope, so risk stays hidden while the maturity score improves on paper.

Q: Why do AI agents change existing IAM assumptions?

A: AI agents change IAM assumptions because access is no longer a stable state that can be granted, reviewed, and trusted over a session. When an agent can decide and execute actions dynamically, the programme must track runtime authority, not only entitlement assignment. That makes governance, monitoring, and revocation more operationally dynamic.

Q: How can security teams tell whether IAM maturity is real for machine identities?

A: Look for evidence that the programme can trace ownership, purpose, scope, and retirement for every non-human identity. If reporting only covers human access reviews or directory clean-up, maturity is overstated. Strong signals include machine-specific entitlement reviews, revocation workflows, and monitoring that distinguishes service accounts from users.

Q: Should organisations use the same access model for humans and AI agents?

A: No. Human access models are built around stable roles and review cycles, while AI agents often need contextual, task-specific permissions that change quickly. Treating them the same usually leads to over-permissioning or constant exceptions. Organisations should separate identity proof from authorization design and apply resource-level controls for agents.


Technical breakdown

Why IAM maturity models stall when identity becomes runtime-driven

Traditional IAM maturity models assume identities are provisioned, reviewed, and retired on a human governance cadence. That works when access is stable long enough for periodic certification and exception handling, but it breaks when software identities, APIs, and AI agents can act continuously across systems. The control problem is no longer just whether access was granted correctly. It is whether the model can observe, constrain, and revoke behaviour while the identity is active. A maturity framework that treats access as a static state will always understate the risk created by machine-paced execution.

Practical implication: reassess maturity scoring so runtime issuance, monitoring, and revocation are treated as core control outcomes, not supporting features.

How identity lifecycle management changes for AI agents and NHIs

Identity lifecycle management for human users follows a recognisable joiner-mover-leaver pattern. For AI agents and other NHIs, the lifecycle is less about employment status and more about creation, binding to tools, scope changes, and offboarding when a workflow, model, or integration is retired. The article points to the need for centralised lifecycle logic and API-driven identity handling because scripts and manual workflows become fragile as identity volume and change rate rise. In practice, lifecycle maturity depends on whether the organisation can trace ownership, entitlement, and revocation across machine identities without relying on human memory.

Practical implication: map every non-human identity to an owner, purpose, and retirement path before it becomes a permanent exception.

Why governance and access management need different signals for machine identities

Governance in mature IAM programmes is usually expressed through policies, reviews, and reporting. For human identities, that can be enough to show oversight. For NHIs and AI agents, governance must also prove scope control, entitlement hygiene, and the absence of standing privilege. The article's access-management discussion points to ABAC, RBAC, PAM, least privilege, and SIEM-style anomaly detection as maturity markers, but those controls need to be measured against machine behaviour rather than human role assumptions. Otherwise, the programme looks mature while machine identities accumulate unused or overbroad access.

Practical implication: add machine-identity entitlement reviews and anomaly signals to governance reporting instead of relying on user-centric access certification alone.


NHI Mgmt Group analysis

Maturity models built for human access cannot measure machine-paced identity behaviour: The article shows that IAM maturity still tends to reward policy completeness, review cadence, and process consistency. Those are useful indicators for human users, but they understate the control gap when AI agents and NHIs can operate across systems faster than review cycles can react. The implication is that maturity has to include runtime governance, not just lifecycle formality.

Identity lifecycle management becomes a different discipline once access is non-human: Human joiner-mover-leaver thinking does not map cleanly onto AI agents, service accounts, or API-bound identities. Their real lifecycle includes creation, delegation, scope change, and retirement across systems that may never pass through a human ticketing flow. Practitioners should treat ownership, purpose, and offboarding as mandatory metadata for every non-human identity.

Runtime governance gap: The model breaks when access can be exercised before it can be certified. Access review programmes were designed for identities whose privileges persist long enough to be observed and recertified. That assumption fails when an AI agent can obtain, use, and discard access within a task. The implication is that governance must move upstream to issuance, policy, and runtime enforcement, because later review cannot recover what no longer exists.

Access management maturity now depends on whether controls recognise actor type: The article implicitly separates human-centric IAM from machine identity governance by showing that the same maturity level means different things depending on who or what holds access. ABAC, RBAC, PAM, and monitoring are not obsolete, but they must be interpreted through the behaviour of NHIs and AI agents rather than through user roles alone. Practitioners should benchmark controls by actor type, not by generic IAM stage names.

Optimised IAM is no longer just a process state, it is a trust boundary model: Level 4 style maturity only matters if the organisation can continuously prove who or what is authorised, for what purpose, and for how long. In a mixed environment, that means connecting governance, access management, and lifecycle logic into one operating model. The practical test is whether the programme can sustain least privilege across human, non-human, and AI-driven identities without special-casing every new use case.

From our research library:

What this signals

IAM maturity has to be redefined around actor type: The same programme can look mature for human users while remaining weak for NHIs and AI agents. That is because review cadences, role models, and exception handling were designed around slower human governance loops, not machine-paced execution.

Identity lifecycle governance is now the backbone of maturity: Once AI agents and service identities enter the environment, provisioning and offboarding stop being administrative tasks and become security controls. Teams should expect maturity assessments to ask whether non-human identities have explicit ownership, purpose, and retirement paths, not just whether they exist.

Access governance should be measured where decisions happen: If a privilege can be consumed before the next certification cycle, the control has failed at the wrong point in time. Mature IAM programmes will shift attention to issuance, runtime constraints, and actor-specific reporting, especially where human and non-human identities coexist.


For practitioners

  • Rework maturity scoring for non-human access Assess whether your IAM maturity model measures runtime control, entitlement scope, and revocation speed for NHIs and AI agents, not just policy presence and review completion.
  • Inventory machine identities as governed assets Create an ownership, purpose, and retirement record for each service account, API key, token, certificate, or AI agent identity so lifecycle decisions are explicit.
  • Separate human review cadence from machine control Do not rely on periodic access certification to govern identities that can act and disappear inside one workflow. Shift control earlier to issuance and runtime enforcement.
  • Measure privilege by actor type Report least privilege, standing access, and anomaly detection separately for human users, NHIs, and autonomous systems so maturity scores reflect actual governance coverage.
  • Tie governance to offboarding outcomes Verify that deprovisioning closes access paths for integrations, service accounts, and AI agent bindings, not only employee accounts and directory objects.

Key takeaways

  • The article shows that IAM maturity models can overstate control strength when they are built around human review cycles rather than machine-paced identity behaviour.
  • The real gap is not whether policy exists, but whether the organisation can govern non-human identities at issuance, during runtime, and at retirement.
  • Practitioners should measure maturity by actor type, because AI agents and service identities require lifecycle and access controls that human-centric IAM models do not capture well.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-01 — Improper OffboardingThe article centres on lifecycle management for non-human identities and the need to retire them cleanly.
NHI-05 — Overprivileged NHIThe maturity discussion highlights least privilege and scope control for non-human identities.
Recommendation — Treat offboarding of service accounts and AI agent identities as a governance control, not an admin cleanup task. Audit non-human entitlements for standing privilege and reduce access to the minimum required scope.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article is about access governance and entitlement maturity across human and non-human identities.
Recommendation — Use entitlement governance to verify that access permissions match role, purpose, and current need.
MITRE ATT&CKTA0006;TA0008 — Credential Access; Lateral MovementMachine identities expand the attack surface for credential abuse and movement across systems.
Recommendation — Map machine-identity weaknesses to credential access and lateral movement paths in detection and threat modelling.

Key terms

  • Identity Maturity Model: An Identity Maturity Model is a structured way to assess how well an organization manages identities, access, and related controls. It typically measures current practices against defined stages of capability, covering governance, provisioning, authentication, authorization, monitoring, and lifecycle management across human and non-human identities.
  • Identity Lifecycle Governance: Identity lifecycle governance is the set of processes that create, change, review, rotate, and revoke access across human and non-human identities. It matters because access risk usually increases when lifecycle events are slow, incomplete, or disconnected from the systems that rely on them.
  • Access Governance: Access governance is the policy and workflow layer that manages how access is requested, approved, certified, and revoked. In SaaS environments it helps standardise control across many applications, reducing inconsistency between teams. It is most effective when it covers both human accounts and non-human identities.
  • Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org