How should teams measure identity governance maturity across human and non-human identities?

Why This Matters for Security Teams

Identity governance maturity is not just about counting accounts. It is about proving that access is owned, reviewed, and removed consistently across people, service accounts, API keys, workloads, and agents. NHI Management Group research shows how often that breaks down in practice: the Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts. That is a governance problem before it becomes a security problem.

For humans, many teams already measure joiner-mover-leaver timing, access review completion, and privileged access removal. For NHIs, the same discipline often disappears into code repositories, CI/CD systems, and unmanaged secrets stores. The result is a mixed maturity model where human access is reviewable but machine access is effectively invisible. The NIST Cybersecurity Framework 2.0 is useful here because it forces teams to tie identity governance to outcomes, not just inventory. In practice, many security teams discover NHI drift only after a secrets leak or incident review, rather than through intentional governance measurement.

How It Works in Practice

Start by defining a single governance scorecard that covers both identity classes, then segment results where the lifecycle mechanics differ. For humans, measure whether access is assigned through approved roles, reviewed on schedule, and revoked promptly after role change or termination. For NHIs, measure whether each identity has an owner, purpose, expiry, secret rotation path, and revocation workflow. The key is not to use identical controls for both, but to use comparable governance questions.

A practical maturity model usually tracks five dimensions:

• Ownership: every identity has an accountable owner or system owner.
• Visibility: the organisation can enumerate identities, entitlements, and secret locations.
• Reviewability: access is periodically validated against business need.
• Revocability: access removal is tested, timely, and observable.
• Lifecycle automation: onboarding, rotation, and offboarding are enforced through process or tooling.

For NHI-specific depth, the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is a useful reference point because lifecycle control is where maturity becomes measurable. A strong programme can show how often service accounts are reviewed, whether long-lived credentials exist, and how quickly access is removed when a workload is decommissioned. On the human side, align the same scorecard to established governance expectations in the NIST Cybersecurity Framework 2.0.

Operationally, maturity improves when teams use evidence rather than policy intent: review logs, owner assignments, expiration dates, rotation events, and revocation test results. If the organisation cannot answer who owns an identity, when it was last reviewed, and how quickly it can be removed, maturity is still immature even if formal policies exist. These controls tend to break down when NHIs are created ad hoc in CI/CD pipelines because ownership and revocation are not embedded in the delivery workflow.

Common Variations and Edge Cases

Tighter governance usually increases operational overhead, so teams have to balance control depth against delivery speed and system volatility. That tradeoff becomes sharper when comparing human identities with NHIs that may be short-lived, highly automated, or embedded in third-party services.

Current guidance suggests that maturity scoring should not penalise legitimate differences in lifecycle length, but it should penalise inconsistency. For example, a human access review every 90 days may be acceptable, while an NHI with no expiry, no owner, and no rotation path is a clear maturity gap. Similarly, some machine identities will not fit classic RBAC cleanly; in those cases, the control question becomes whether the entitlement is still justified and revocable, not whether it maps neatly to a job role.

Edge cases include shared service accounts, vendor-managed identities, and emergency access. These often create false confidence because they appear operationally necessary. The right maturity question is whether the organisation can still attribute usage, review necessity, and remove access without waiting for a manual cleanup project. The 52 NHI Breaches Analysis and the Top 10 NHI Issues both reinforce the same pattern: maturity fails when identity governance is fragmented by system type instead of measured through a common control lens.

Related resources from NHI Mgmt Group

• How should security teams evaluate identity platforms that cover both human and non-human identities?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?