What breaks when access reviews do not reflect actual runtime usage?

Why This Matters for Security Teams

Access reviews are meant to prove that entitlement decisions still match business need, but that only works when the review reflects what identities actually do at runtime. For service accounts, API keys, bots, and delegated agents, assigned access can look “approved” even while the real risk sits in dormant permissions, stale tokens, and unattended sessions. That gap is exactly where attackers and accidental misuse find room to operate. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which makes static certification especially fragile.

Security teams often mistake a completed review for control effectiveness. In reality, an access review that ignores runtime usage can bless accounts that have not been used for months while missing active pathways created by inherited permissions, long-lived sessions, or shared credentials. That is a direct governance failure, not just an administrative gap. The OWASP Non-Human Identity Top 10 treats excessive privilege and weak lifecycle control as core risk drivers for this reason. In practice, many security teams encounter the problem only after an incident review reveals that the access was “approved” long after the original need disappeared.

How It Works in Practice

A meaningful review must compare granted access with effective access. That means checking whether an identity actually used the permission, when it last used it, from where it used it, and whether the usage matches the stated business purpose. For NHIs, that includes service account activity, secret issuance, API calls, token refreshes, and cross-system delegation. Current guidance suggests combining IAM records with telemetry from cloud logs, vaults, CI/CD systems, and workload identity providers so reviewers can see both the entitlement and the operational footprint.

Practitioners usually get better results when reviews are built around evidence, not ownership checkboxes. A practical workflow looks like this:

• Map assigned permissions to observed runtime actions over a defined period.
• Flag accounts with no use, unusual use, or use outside the declared role.
• Separate human exceptions from NHI exceptions, since the lifecycle rules are different.
• Revoke stale secrets and sessions automatically when usage no longer justifies access.
• Require reauthorization for high-risk entitlements rather than merely reattestation.

This is where lifecycle discipline matters. The NHI Lifecycle Management Guide frames review as part of a broader create, operate, rotate, and retire process, not a one-time audit event. NIST’s Cybersecurity Framework also reinforces continuous monitoring as a core control expectation, which is why point-in-time attestation alone is rarely sufficient. These controls tend to break down in environments with shared service accounts, unmanaged secrets, or tools that cannot reliably emit usage telemetry because reviewers cannot distinguish real activity from residual entitlement.

Common Variations and Edge Cases

Tighter runtime review usually increases operational overhead, so organisations have to balance stronger assurance against review fatigue and false positives. That tradeoff is especially visible in legacy systems, where detailed telemetry may be incomplete or where one account supports multiple workloads. In those cases, best practice is evolving rather than settled: some teams use compensating controls such as shorter secret TTLs, network scoping, and change-ticket linkage when runtime visibility is limited.

Another edge case is batch processing and ephemeral automation. An account may appear inactive for long periods but still be legitimate if it runs on a schedule. Reviewers should validate cadence, source host, and triggering conditions before marking it unused. The risk, however, increases sharply when an NHI is both long-lived and broadly shared. The NHIMG Key Challenges and Risks section highlights how hidden credentials and poor visibility can sustain access long after business need ends. For that reason, a review process that cannot tie permission to observed use should be treated as incomplete, not merely noisy.

Related resources from NHI Mgmt Group

• Why do runtime identity controls matter more than periodic access reviews?
• How should security teams run access reviews for non-human identities?
• When do NHI access reviews create more value than a one-time cleanup?
• What breaks when SaaS access reviews do not include usage evidence?