Subscribe to the Non-Human & AI Identity Journal

When does access review fail as a compliance control?

Access review fails when it produces attestations without changing entitlement state. If reviewers cannot confirm ownership, business need, and revocation authority, the process becomes a reporting activity rather than a governance control. The strongest indicator of failure is repeated approval of access that no one can justify.

Why This Matters for Security Teams

Access review is often treated as evidence that entitlement governance is working, but that assumption breaks when the review cannot change state. If approvers only click through a list, the control records intent without proving ownership, business need, or revocation authority. That is exactly where compliance and actual risk diverge. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives frames this as a lifecycle problem, not a checkbox problem.

The issue is sharper for non-human identities because service accounts, API keys, tokens, and agent credentials often outlive the people who requested them. In those environments, a review that does not identify the owner and the revoker leaves dormant access in place. The OWASP Non-Human Identity Top 10 treats excessive and ungoverned NHI access as a recurring failure mode, while the NIST Cybersecurity Framework 2.0 emphasizes that access governance must be enforceable, not merely documented. In practice, many security teams discover review failure only after an audit exception, a privileged misuse event, or an account that nobody can actually justify.

How It Works in Practice

A review fails as a compliance control when it cannot drive a concrete entitlement decision. That means the process must be able to answer three questions at the moment of review: who owns the access, why is it still needed, and who has authority to remove it. For human users, that is already hard. For NHIs, it is harder because the “user” may be a pipeline, bot, workload, or AI agent whose access is distributed across cloud IAM, secrets stores, and application permissions.

Operationally, the control should connect review to identity state changes. A valid review workflow should do more than send notifications. It should:

  • bind each entitlement to a named business owner and technical custodian
  • require explicit approve, revoke, or certify decisions for every item
  • write revocation actions back to the source system, not just the audit log
  • prove that deleted access was actually removed from IAM, secrets, or token stores
  • retain evidence of the rationale and the timestamp of the state change

This is where lifecycle governance matters. NHIMG’s NHI Lifecycle Management Guide and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both reinforce that review is only one checkpoint in a broader control chain. If the entitlement cannot be traced from issuance to revocation, the review is just a reporting layer. For measured governance claims, that distinction matters more than the approval count.

Current guidance suggests aligning reviews with the authoritative source of truth for each identity type, then automating removal where possible. Manual attestation alone is too weak for fast-moving workloads. A strong review program also cross-checks stale access patterns against the findings in the Top 10 NHI Issues, because repeated approvals of unexplained access usually indicate the review has lost operational meaning. These controls tend to break down when access is spread across multiple systems with no unified ownership because reviewers cannot confirm whether revocation will actually propagate everywhere.

Common Variations and Edge Cases

Tighter access review often increases administrative overhead, requiring organisations to balance audit certainty against operational speed. That tradeoff becomes visible in environments with thousands of short-lived NHIs, ephemeral secrets, or CI/CD pipelines where access changes faster than review cycles. In those cases, a quarterly certification can satisfy a policy requirement while still failing as a security control if the access has already expired, rotated, or been reused elsewhere.

There is no universal standard for this yet, but current guidance suggests treating different identity classes differently. Long-lived administrative access may justify a formal attestation workflow. High-churn machine access often needs automated lifecycle controls, time-bound entitlements, and event-driven revocation instead of human sign-off alone. The Ultimate Guide to NHIs — Standards is useful here because it places review alongside enforceability, not just documentation.

One practical edge case is delegated approval. If an approver can only confirm familiarity with the system but cannot revoke access, the review is incomplete. Another is inherited access through groups or roles: if the reviewer sees only the role name and not the downstream entitlements, the control can miss excess privilege. In both cases, the control fails when it cannot prove that the entitlement state changed after the decision. That failure is most common in mixed human and NHI estates where ownership, authority, and tooling are split across teams.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-03 Access review often fails when NHI entitlements are not truly removed.
NIST CSF 2.0 PR.AC-4 Least-privilege access governance requires review outcomes to affect entitlement state.
NIST AI RMF AI governance depends on accountable, reviewable access decisions for autonomous systems.

Apply governance controls that verify ownership, authority, and revocation for AI-linked access.