Identity security maturity is still missing the security problem

At a glance

What this is: This analysis argues that identity security maturity has been built around compliance assurance, leaving a structural gap between control deployment and actual risk reduction.

Why it matters: It matters because IAM, NHI, and human identity programmes can look mature on paper while still failing to constrain modern access paths, compromise windows, and review lag.

By the numbers:

• 71% of organizations experienced a security breach last year.

👉 Read Clarity Security's report on the three stages of identity security maturity

Context

Identity security maturity is the way an organisation organises access control, governance, and review across its identity estate. In this article, the primary keyword is identity security maturity, and the core claim is that most programmes were shaped to satisfy compliance requirements rather than reduce security risk in real time.

That matters because the standard toolkit can be deployed without closing the gap between entitlement and exposure. SSO, MFA, and access reviews all have value, but they do not automatically solve the structural mismatch between scheduled governance and continuous attack pressure.

Key questions

Q: How should security teams measure whether identity security maturity is actually reducing risk?

A: Measure whether identity controls reduce standing privilege, excess entitlement, and time-to-revoke, not just whether reviews and approvals happened. A mature programme should show that access can be identified, challenged, and removed quickly enough to matter during active compromise. If the main evidence is completed reviews, the programme may be compliant without being materially safer.

Q: Why do SSO, MFA, and access reviews still leave organisations exposed?

A: Because those controls can be correctly deployed inside a governance model that was built to document access rather than continuously constrain it. They help, but they do not automatically resolve inherited permissions, federated access, overbroad roles, or the delay between compromise and review. Exposure persists when the programme proves process instead of limiting live attack paths.

Q: What do teams get wrong about non-human identity governance?

A: They often manage service accounts, tokens, and API keys with the same lifecycle assumptions used for human users. That breaks down when credentials are created automatically, owned ambiguously, and retired inconsistently. NHI governance needs separate inventory, ownership, rotation, and offboarding discipline because these identities do not follow HR-driven lifecycle patterns.

Q: Who is accountable when identity reviews confirm access was approved but a breach still happens?

A: Accountability sits with the identity and security owners who defined the control model, not just the reviewers who completed the checklist. If a programme treats review completion as success, it can miss the fact that access was already unsafe. Frameworks such as the NIST Cybersecurity Framework 2.0 expect controls to support protection and response, not merely evidence generation.

Technical breakdown

Why the compliance-first identity model misses real risk

The article’s central technical argument is that identity security platforms were shaped by auditability, not by adversarial timing. Provisioning workflows, separation-of-duties checks, and scheduled access reviews are designed to prove that access is being managed according to process. That works when the goal is documentation. It is weaker when the security problem is continuous compromise, credential replay, federated overreach, or access that changes faster than review cycles can observe. The issue is not that the tools are useless. It is that they were optimised for a different control objective than live risk reduction.

Practical implication: evaluate whether your identity controls reduce exposure in-session, not just whether they create evidence for auditors.

Conditional trust, human lifecycle governance, and NHI blind spots

Conditional trust describes the common IAM pattern where access is granted, changed, and removed through lifecycle stages tied to people and roles. That model works reasonably well for joiner-mover-leaver processes, but it does not naturally fit service accounts, API keys, OAuth tokens, or AI agents. Non-human identities are often created automatically, owned ambiguously, and retired inconsistently, which means their lifecycle is easier to start than to govern. In practice, the same governance structure that handles human access reviews can leave machine identities over-permissioned or forgotten.

Practical implication: separate human lifecycle controls from NHI lifecycle governance so machine identities are inventoried, owned, and retired on their own terms.

Access review is a governance record, not a breach control

The article makes a useful distinction between proving access is managed and actually preventing misuse. Access reviews can show that entitlements were checked on a schedule, but they do not stop a valid credential from being abused before the next review. This is especially important in cloud and SaaS environments where permissions can be broader than intended, nested, or inherited through federated structures. A review that happens after compromise has begun is evidence of governance, not evidence of containment.

Practical implication: treat access reviews as one control in a broader risk model, not as the mechanism that closes active security exposure.

NHI Mgmt Group analysis

Compliance assurance is not the same as security reduction. Identity programmes built to satisfy auditors create evidence of control activity, but evidence is not the same as reduced attack surface. The article shows that organisations can deploy SSO, MFA, and access reviews and still experience breach activity at scale. The practitioner conclusion is that identity maturity has to be measured against exposure reduction, not process completion.

Conditional trust was designed for a slower, more legible identity environment. That assumption fails in cloud and SaaS estates where access is inherited, federated, and continuously changing. The implication is not simply that more tooling is needed, but that the programme’s core success metric must move from review completion to effective privilege containment.

Identity security maturity has a visibility problem, not just a control problem. The article’s stage model shows that many organisations can see whether a workflow ran, but not whether the access pattern is actually safe. Human IAM, NHI governance, and lifecycle management all suffer when the programme is measured by audit artefacts instead of operational exposure. Practitioners should treat maturity claims as incomplete until they can show what access exists, who or what owns it, and how quickly it can be removed.

Non-human identity growth makes the old maturity model structurally incomplete. Service accounts, tokens, API keys, and AI agents expand faster than legacy identity governance assumptions. The governance lesson is that a programme cannot call itself mature if the largest and least visible class of identities sits outside its control model. The practical conclusion is to assess maturity by actor type, not by checkbox coverage.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• For a broader governance lens, see Ultimate Guide to NHIs , Key Challenges and Risks for the control gaps that make maturity claims hard to sustain.

What this signals

Identity security maturity needs to be segmented by actor type. A programme that is strong for human lifecycle governance can still be weak for service accounts, tokens, and AI agents. The practical signal is simple: if your review, ownership, and revocation processes do not differ by actor type, you are measuring administration, not resilience.

The widening gap between documented control and actual exposure suggests that access governance is moving toward continuous, risk-based enforcement. Teams that still rely on periodic review alone will struggle to prove that they can respond faster than the attack can move.

For practitioners

• Re-baseline maturity against exposure reduction Replace audit completion as the primary success measure with indicators that show whether access is actually shrinking risk, such as standing privilege, unused entitlements, and time-to-revoke.
• Separate human and non-human identity lifecycle controls Run distinct governance processes for employees, service accounts, API keys, and tokens so machine identities are inventoried, owned, and retired without depending on human HR workflows.
• Shorten the path from entitlement change to enforcement Reduce the delay between a role change, a privilege change, and policy enforcement so scheduled review cycles do not become the only point at which excess access is detected.
• Audit federated and inherited access paths separately Map permissions granted through SSO, federation, and nested groups because those paths often create broader access than the direct assignment record suggests.

Key takeaways

• The article’s core warning is that identity programmes can look mature while still being structurally misaligned with security outcomes.
• The evidence point is that 71% of organisations still reported a breach even though most had SSO, MFA, and access reviews deployed.
• Practitioners should judge maturity by how quickly identity controls reduce exposure across human and non-human actors, not by whether a governance workflow completed.

Key terms

• Identity Security Maturity: The stage of an identity programme’s development as measured by how well it controls real access risk, not just how well it documents process. In practice, maturity should reflect visibility, enforcement speed, and governance across human and non-human identities.
• Conditional Trust: An identity model where access is granted and reviewed through scheduled governance processes after trust has already been established. It is useful for compliance, but it can leave gaps when attackers move faster than review cycles or when machine identities do not fit human lifecycle assumptions.
• Non-Human Identity: A digital identity used by software, services, workloads, or automation rather than a person. This includes service accounts, API keys, tokens, certificates, and AI agents, all of which need ownership, lifecycle control, and privilege management that are separate from human access processes.

What's in the full report

Clarity Security's full report covers the operational detail this post intentionally leaves for the source:

• Stage-by-stage maturity model detail for Inherent Trust, Conditional Trust, and Adaptive Trust
• Supporting breach data and the underlying survey breakdown behind the 71% figure
• The report's full explanation of how governance priorities shifted from security to compliance
• More context on the specific control gaps affecting human and non-human identity programmes

👉 Clarity Security's full report covers the maturity model, breach evidence, and the control gaps behind it

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.