Subscribe to the Non-Human & AI Identity Journal

What should organisations measure in an identity-centric operating model?

Measure how many systems can independently grant, extend, or fail to revoke access, and track whether lifecycle events propagate everywhere they should. Also review exception rates and orphaned account counts. If those indicators rise while the identity programme is meant to centralise control, the model is not yet unified.

Why This Matters for Security Teams

An identity-centric operating model is only measurable if it exposes where identity still acts like a bypass rather than a control plane. The core question is not how many identities exist, but whether access decisions, provisioning, and revocation are truly converging around a single source of authority. That is why NHI governance has become central to Zero Trust thinking, as reflected in the NIST Cybersecurity Framework 2.0 and NHIMG’s Ultimate Guide to NHIs.

Security teams should measure propagation lag, exception volume, orphaned accounts, and the number of systems able to independently grant or extend access. Those indicators reveal whether lifecycle events are being enforced consistently or merely documented after the fact. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which is a strong signal that many identity programmes still manage policy on paper while enforcement remains fragmented in practice.

In practice, many security teams discover the model is not unified only after a deprovisioning failure leaves access active somewhere no one was monitoring.

How It Works in Practice

An identity-centric operating model should measure identity as an operational dependency, not just a directory object. The most useful metrics are those that show whether identity events are propagating across applications, infrastructure, automation, and third-party integrations without manual intervention. That includes how quickly access is created, how often approvals are bypassed, how reliably revocation lands everywhere, and whether exceptions are shrinking over time.

In mature environments, the identity layer becomes the control point for joiner, mover, and leaver events, but the measurement model must extend beyond humans. For NHIs, the same logic applies to service accounts, API keys, certificates, and workload tokens. If those assets are still minted locally, renewed ad hoc, or revoked only when a human remembers, the operating model is not truly identity-centric. The guidance in Ultimate Guide to NHIs — What are Non-Human Identities is helpful here because it frames visibility, lifecycle, and offboarding as measurable control outcomes, not abstract policy statements.

  • Measure the percentage of systems that consume identity events automatically rather than via ticket-driven updates.
  • Track time to revoke for users, service accounts, tokens, and certificates separately, because their failure modes differ.
  • Count orphaned identities, stale credentials, and policy exceptions that persist beyond their approved window.
  • Review whether access grants are centrally attested or whether downstream teams can still self-authorise.

The NIST Cybersecurity Framework 2.0 is useful as a measurement anchor because it emphasises governed, repeatable outcomes across identity, access, and recovery domains. NHIMG data also shows that 91.6% of secrets remain valid five days after notification, which makes revocation latency a practical metric, not an academic one. These controls tend to break down in hybrid estates where legacy systems cannot consume lifecycle events and remain dependent on manual change management.

Common Variations and Edge Cases

Tighter identity measurement often increases operational overhead, requiring organisations to balance control accuracy against integration cost. That tradeoff matters because not every system can support the same level of automation, and not every exception is evidence of failure. Current guidance suggests separating deliberate exceptions from unmanaged drift, then measuring both with equal discipline.

For example, highly regulated platforms may require extra approval steps, while ephemeral cloud workloads may need much faster automation and shorter credential lifetimes. In those cases, the right metric is not simply “number of exceptions,” but whether exceptions are time-bound, reviewed, and eventually removed. Likewise, a low orphan-account count is only meaningful if discovery coverage is broad enough to find hidden identities in code repositories, CI/CD pipelines, and shadow tooling. NHIMG’s Top 10 NHI Issues and 52 NHI Breaches Analysis both reinforce the same operational lesson: visibility gaps make reassuring metrics unreliable.

There is no universal standard yet for the ideal threshold of exception rates across all identity domains, so the more defensible approach is to trend them by system class, identity type, and business criticality. Identity-centric programmes become misleading when they optimise central dashboards while leaving local systems free to create lasting access outside the governed path.

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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-01 Covers visibility and inventory gaps for non-human identities.
NIST CSF 2.0 PR.AC-1 Access control metrics map to whether identity is the governing control plane.
NIST AI RMF Identity-centric measurement supports governance and accountability for automated systems.

Inventory all NHIs and measure orphaned or unmanaged identities until coverage is complete.