What should IAM leaders measure if they want to know whether controls are actually working?

IAM leaders should measure adoption, bypass behaviour, and support burden together. If password resets, duplicate accounts, and shadow application use are rising, the control design is creating friction that users are escaping. Effective security should reduce risk without pushing people out of the governed path.

Why This Matters for Security Teams

IAM controls only matter if they change real behaviour, reduce risky workarounds, and hold up under operational pressure. Leaders often focus on policy coverage or login success rates, but those metrics can hide failure: users may be bypassing controls, creating duplicate accounts, or escalating support tickets to escape friction. NIST Cybersecurity Framework 2.0 frames this as a governance and outcomes problem, not just an access configuration problem.

For NHI and agentic environments, the gap is even sharper. Static access models do not reveal whether service accounts, API keys, or agents are operating inside the intended control path. NHIMG research shows how common that gap is: Ultimate Guide to NHIs — Standards reports that 88.5% of organisations say their non-human IAM practices lag behind or only match human IAM maturity, while only 19.6% feel strongly confident in securing workload identities. That is a control effectiveness problem, not just a tooling problem.

In practice, many security teams discover controls are failing only after shadow access, duplicate credentials, or exception-heavy support queues have already become normal operating patterns, rather than through intentional measurement of control outcomes.

How It Works in Practice

The most useful measurement model combines three views: adoption, bypass behaviour, and operational burden. Adoption shows whether people and workloads are actually using the intended path. Bypass behaviour shows where they are escaping it. Support burden shows whether the control is sustainable at scale. If one improves while the others deteriorate, the control may be technically “working” but operationally failing.

For human access, leaders should measure MFA completion, self-service success, password reset volume, duplicate account creation, and exception requests by application or population. For NHI and agent access, the same logic applies to secret issuance, secret rotation success, workload identity adoption, and the volume of long-lived credentials still in circulation. NHIMG’s Azure Key Vault privilege escalation exposure is a useful reminder that privilege paths can become invisible if teams only track vault presence and not who can actually use what, where, and why.

A practical scorecard often includes:

• Adoption rate of the governed path versus legacy or shadow paths
• Bypass indicators such as shared accounts, local admin grants, or unmanaged API keys
• Help desk ticket volume tied to access friction
• Mean time to approve, issue, rotate, and revoke access
• Percentage of access requests requiring exception handling
• Number of standing privileges versus time-bound or just-in-time access

For agentic systems, current guidance suggests measuring runtime authorisation decisions, not just whether an identity exists. A control is healthier when the agent gets the right access only when needed, with a short-lived token or workload identity, and when denied actions are explainable in policy terms. That aligns with zero trust thinking in the NIST Cybersecurity Framework 2.0 and with the broader lifecycle discipline documented in Ultimate Guide to NHIs — Standards.

These controls tend to break down in highly distributed environments with many SaaS apps, CI/CD pipelines, and autonomous workloads because access paths multiply faster than teams can normalize telemetry across systems.

Common Variations and Edge Cases

Tighter measurement usually increases reporting overhead, requiring organisations to balance better assurance against data quality, integration cost, and analyst fatigue. That tradeoff is real, especially when identity, endpoint, ITSM, and cloud logs do not share a common schema.

There is no universal standard for this yet, but best practice is evolving toward outcome-based metrics that are segmented by use case. A mature enterprise will not treat the same thresholds as valid for employees, contractors, service accounts, and agents. For example, a high password reset rate may indicate poor user experience for humans, while a high secret rotation failure rate may indicate brittle automation for NHIs. Those are different problems with different control responses.

Edge cases matter. A spike in support tickets can mean users are resistant to a good control, but it can also mean the control is mis-scoped, poorly integrated, or failing for one business-critical application. Similarly, low bypass rates can be misleading if the organisation has simply made approved access so slow that users stop reporting their workarounds. Leaders should pair quantitative metrics with exception review, application-level telemetry, and periodic control testing. The goal is not just to count activity, but to verify that access decisions are staying inside the governed path as the environment changes.

Related resources from NHI Mgmt Group

• How do IAM teams know if privileged access controls are actually working?
• How do organisations know whether IAM observability is actually working?
• How can organisations know whether device posture controls are actually working?
• How do organisations know whether cloud access controls are actually working?