What should teams measure to know whether NHI governance is working?

Why This Matters for Security Teams

Metrics are the difference between an NHI programme that exists on paper and one that changes risk in production. Ownership coverage, credential age, revocation latency, and the ratio of shared or orphaned identities show whether control actually exists across the lifecycle. Without those measures, teams tend to confuse inventory growth with governance maturity, even when privileged secrets remain overexposed and no one can prove timely removal.

NIST Cybersecurity Framework 2.0 frames this as an ongoing governance and measurement problem, not a one-time configuration exercise, and NHIMG research shows why that matters: in The 2024 ESG Report: Managing Non-Human Identities, 72% of organisations said they have experienced or suspect a breach tied to NHIs. That is a measurement failure as much as a control failure. If the programme cannot answer who owns each identity and how quickly it can be removed, the reported coverage numbers are likely overstating real security.

Teams often discover that governance gaps were present long before an incident, but the evidence only becomes visible after a privileged token is abused or an orphaned service account is reused unexpectedly.

How It Works in Practice

Effective measurement starts with defining each NHI as a managed asset with an owner, purpose, scope, and expiry logic. The core question is not simply "how many identities exist?" but "how many identities can be explained, defended, and retired on demand?" That usually means tracking the full chain from creation to rotation, suspension, and deletion, then comparing actual behaviour against policy. The Lifecycle Processes for Managing NHIs guidance is useful here because lifecycle state is where governance either holds or leaks.

At minimum, teams should instrument the following:

• Ownership coverage: percentage of NHIs with a named business and technical owner.

• Credential lifespan: median and maximum TTL for secrets, tokens, and certificates.

• Revocation speed: time from trigger to invalidation across all dependent systems.

• Orphan and shared identity rate: identities with no owner, unclear purpose, or multiple unrelated users.

• Rotation compliance: whether rotation actually happens on schedule, not just whether a policy exists.

Current guidance suggests pairing those indicators with alert quality and exception handling, because raw counts alone do not show whether control is effective. For example, a short-lived secret may still be unsafe if it can be copied, reused, or reissued without approval. The Top 10 NHI Issues page is a useful reminder that poor rotation, weak visibility, and overprivilege often appear together rather than in isolation. In practice, measurement should be wired into the CMDB, secret manager, and ticketing system so that drift is visible as a change in state, not a quarterly audit surprise.

These controls tend to break down in environments with ephemeral infrastructure and unmanaged third-party integrations because ownership, revocation, and lineage are distributed across systems that do not share a single source of truth.

Common Variations and Edge Cases

Tighter measurement often increases operational overhead, requiring organisations to balance visibility against the cost of collecting and normalising identity data. That tradeoff is real, especially where legacy apps, SaaS integrations, and machine-to-machine workflows all use different authentication patterns. Best practice is evolving, and there is no universal standard for every metric yet, so teams should prefer a small set of defensible indicators over broad dashboards that cannot be acted on.

One common edge case is service accounts that are technically owned by a platform team but functionally used by multiple product teams. Those identities should be treated as high-risk shared credentials, even if the CMDB says they are "assigned." Another is API keys embedded in CI/CD pipelines: they may look temporary because the pipeline is ephemeral, but the secret itself may live far longer than the build. The Regulatory and Audit Perspectives section helps frame why evidence quality matters as much as technical control.

For broader governance framing, organisations can map these metrics to the NIST Cybersecurity Framework 2.0 and use NHI-specific research such as 52 NHI Breaches Analysis to validate which patterns recur. If the programme cannot distinguish temporary exceptions from permanent exceptions, the metrics may look healthy while the exposure remains unchanged.

Related resources from NHI Mgmt Group

• What should identity teams measure to know if lifecycle governance is working?
• How do security teams know whether machine identity governance is actually working?
• How do teams know whether NHI governance is working for PCI compliance?
• How do security teams know whether NHI governance is actually working?