How do you know if an identity metric is actually working?

Why This Matters for Security Teams

An identity metric is only useful if it changes behaviour: tighter access, faster rotation, shorter review cycles, clearer ownership, or earlier escalation. If the number looks good on a dashboard but never influences a decision, it can conceal the exact conditions that drive identity abuse. That is especially true for non-human identities, where hidden credentials and excessive privilege often sit outside normal IAM review patterns.

The risk is not abstract. NHIMG’s Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges and only 5.7% of organisations have full visibility into their service accounts. Those are the kinds of conditions a weak metric can normalise instead of exposing. A metric that tracks inventory but not privilege reduction, or counts reviews without measuring remediation, often rewards activity rather than control outcome. The NIST Cybersecurity Framework 2.0 reinforces the same principle: measurement should support governance, not just reporting.

In practice, many security teams discover a metric has failed only after a breach review shows it was never tied to access decisions, rather than through intentional control validation.

How It Works in Practice

A working identity metric has three properties: it is decision-linked, outcome-linked, and action-linked. Decision-linked means someone has a defined threshold or interpretation. Outcome-linked means it reflects a security result, not just activity. Action-linked means a change follows when the metric crosses a boundary. For example, “percentage of NHIs with standing privilege above policy” is more useful than “number of identities reviewed this month,” because it points directly to remediation.

For NHI programmes, the most useful metrics often sit close to lifecycle controls. The “Top 10 NHI Issues” research is most valuable when it is used as a prioritisation lens, not a retrospective summary. Metrics should answer questions like:

• Did excess privilege decrease after the review cycle?
• Did stale secrets get rotated within the target window?
• Did offboarding actually revoke access, or only mark ownership change?
• Did a high-risk identity trigger containment before misuse?

That approach aligns with incident-driven evidence from the 52 NHI Breaches Analysis, where visibility failures and credential sprawl repeatedly turn into access exposure. Good metrics also map to control domains in NIST CSF 2.0, especially governance, access control, and continuous monitoring. Current guidance suggests that metric quality should be judged by whether it shortens the time between detection and correction, not by the elegance of the dashboard.

These controls tend to break down in environments with fragmented ownership and no authoritative inventory because no single team can trigger remediation when the metric crosses a threshold.

Common Variations and Edge Cases

Tighter measurement often increases operational overhead, so organisations have to balance signal quality against reporting burden. Not every identity metric needs to be real-time, but the higher the risk, the closer the metric should be to the control action.

There is no universal standard for this yet, especially across hybrid environments. A metric may be “working” for audit preparation but still be weak for defence if it lags too much or lacks ownership. For example, a monthly count of rotated secrets may satisfy reporting needs, while a daily exception rate for overprivileged service accounts may be the metric that actually drives risk reduction. Best practice is evolving toward a smaller set of metrics that are tied to thresholds, escalation paths, and named owners.

Edge cases matter. In delegated engineering environments, teams may resist metrics that expose their own backlog, so governance needs explicit escalation rules. In high-churn CI/CD pipelines, a metric can look healthy while ephemeral credentials are still being overused if the system measures issuance but not revocation. The practical test is simple: if the metric cannot be traced to a policy decision, a workflow step, or a control owner, it is only documentation. Metric design should therefore be reviewed alongside identity governance rather than treated as a separate reporting exercise.

Related resources from NHI Mgmt Group

• How do you know if ITSM is actually improving identity governance?
• How do you know if an airport biometric programme is actually working?
• How do you know whether passwordless is actually reducing identity risk?
• How do you know if PAM is actually working?