How do organisations know if their identity metrics are actually useful?

Why This Matters for Security Teams

Identity metrics only become useful when they support a decision, not when they simply describe activity. For NHI governance, that means a metric should help answer whether risk is shrinking, whether controls are working, and whether operational cost is moving in the right direction. NIST Cybersecurity Framework 2.0 frames this as an outcomes problem, not a counting exercise, which is why a number with no decision path rarely survives contact with incident response, audit, or budget review.

The practical test is whether different stakeholders can use the same metric without translating it three different ways. A security lead needs risk meaning, a platform owner needs operational meaning, and finance needs cost meaning. When one metric cannot support all three, it often turns into reporting noise. NHIMG research shows why this matters: the Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which makes low-quality metrics especially dangerous because they create false confidence.

In practice, many security teams discover metric failure only after an audit, a breach review, or a pricing dispute has already exposed the gap.

How It Works in Practice

Useful identity metrics are usually built from three checks: they are measurable in a repeatable way, they map to a control objective, and they change behaviour. If a metric cannot be recalculated from the same source data next week, it is not dependable enough for governance. If it does not map to a control such as access review, rotation, or offboarding, it may be interesting but not actionable. If it does not affect a decision, it belongs in a dashboard appendix, not an executive report.

Security teams often start by separating leading indicators from lagging indicators. Leading indicators help predict risk, such as the share of NHIs with excessive privileges or the percentage of secrets outside approved vaults. Lagging indicators show realised harm, such as secret exposure incidents or delayed revocation after termination. Both matter, but they serve different audiences. The Top 10 NHI Issues is useful here because it highlights the recurring failure modes that metrics should actually track, not just the conditions teams wish they had.

A practical evaluation method is to ask four questions:

• Can the metric be calculated from systems of record without manual interpretation?
• Can two teams produce the same result from the same inputs?
• Does the metric map to a control owner and an action threshold?
• Would the metric still matter if it increased, decreased, or stayed flat for a quarter?

For identity programs, this often means preferring ratios, time-to-revoke measures, and coverage measures over vanity totals. A count of identities is less useful than the percentage that are orphaned, overprivileged, or unrotated. NIST guidance on program measurement in NIST Cybersecurity Framework 2.0 supports this outcome-driven approach, where the point is to inform risk treatment rather than produce status theatre. These controls tend to break down in fragmented environments where identity data is split across cloud accounts, CI/CD systems, and legacy directories because no single team trusts the underlying source.

Common Variations and Edge Cases

Tighter identity measurement often increases reporting overhead, requiring organisations to balance precision against the cost of collection and reconciliation. That tradeoff becomes visible in mixed environments where some identity types are well-managed and others are not.

Best practice is evolving for metrics that span humans, service accounts, API keys, and AI agents. There is no universal standard for this yet, so organisations should be explicit about scope. A metric that is excellent for cloud service accounts may be misleading for short-lived workload identities. Likewise, a metric built for security operations may not be suitable for chargeback or vendor management unless the denominator is stable and agreed in advance.

Another common edge case is metric gaming. If a team is measured only on the number of credentials rotated, it may rotate low-risk secrets while leaving high-risk ones untouched. If the team is measured only on access review completion, it may approve large batches without scrutiny. The better test is whether the metric can be tied to a decision threshold, a named owner, and a remediation SLA. Where that is not possible, the metric should be treated as descriptive reporting, not governance evidence. NHIMG’s 52 NHI Breaches Analysis is a reminder that weak measurement usually becomes visible only after exposure, not before.

Related resources from NHI Mgmt Group

• How do organisations know if identity risk scoring is actually useful?
• How do organisations know whether identity visibility is actually improving?
• How do organisations know whether AI identity monitoring is actually working?
• How do organisations know if their AI eval rubric is actually useful?