Why do access reviews often fail to reduce identity risk?

Why This Matters for Security Teams

Access reviews are meant to catch entitlement drift, but they often measure paperwork rather than exposure. When reviewers are only shown job titles, group names, or last year’s approvals, the process can miss inherited permissions, service-account privilege, and app-specific entitlements that actually drive risk. That gap is why guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both emphasizes current, verifiable access data rather than static administrative records.

This matters even more for NHI and agentic environments, where identities accumulate tokens, API keys, and delegated permissions outside of the usual HR lifecycle. NHIMG’s research on the Ultimate Guide to NHIs shows that these identities often sit across cloud, code, and automation layers, making stale certification output especially misleading. In practice, many security teams encounter excess privilege only after an incident review, rather than through intentional entitlement reduction.

How It Works in Practice

Effective reviews start with a live entitlement inventory, not a spreadsheet of assigned roles. The reviewer needs to see what an identity can actually do at the moment of certification: direct grants, inherited group access, resource policies, OAuth scopes, API key permissions, and any exceptional SoD conflicts. For non-human identities, that also includes whether the credential is still active, where it is used, and whether it is tied to a workload that still exists. NHIMG’s NHI Lifecycle Management Guide is useful here because lifecycle state and access state must be reviewed together.

Practically, the control works best when certification is driven by business context and technical evidence at the same time. Reviewers should not just approve or reject access; they should answer whether the access is still needed, whether the identity has a current owner, and whether the privilege is compatible with the workload’s function. The 52 NHI Breaches Analysis is a strong reminder that weak identity hygiene tends to become an incident pattern, not a one-off exception.

• Pull live entitlements from the source systems, including nested and inherited permissions.
• Flag dormant, orphaned, and over-provisioned identities before the review starts.
• Require owners to validate both business need and technical scope.
• Auto-revoke or route for remediation when the evidence is incomplete.

Current guidance suggests that certification should be continuous where possible, because monthly or quarterly reviews lose accuracy quickly in fast-changing cloud and SaaS environments. These controls tend to break down when entitlement data is fragmented across multiple directories and apps because reviewers cannot establish a trustworthy baseline.

Common Variations and Edge Cases

Tighter review controls often increase operational overhead, requiring organisations to balance better risk visibility against reviewer fatigue and remediation backlog. That tradeoff is especially sharp for privileged service accounts, break-glass access, and shared automation identities, where a simple yes or no approval model can hide the real risk.

There is no universal standard for this yet, but best practice is evolving toward exception-based reviews for stable low-risk access and deeper validation for high-impact privileges. In NHI-heavy environments, some permissions are embedded in CI/CD pipelines, orchestration systems, or application logic, so a human reviewer may not even see the full access path unless telemetry is stitched together first. NHIMG’s Top 10 NHI Issues captures this operational reality well: the failure is rarely the review form itself, but the incomplete identity graph behind it.

For organisations with heavy automation or delegated admin models, access reviews should be paired with periodic entitlement attestation, ownership validation, and deletion of inactive identities. Where that data cannot be produced reliably, the review should be treated as an assurance signal, not proof of least privilege.

Related resources from NHI Mgmt Group

• Why do entitlement reviews often fail to reduce access exposure?
• Why do access reviews alone fail to control identity risk?
• Why do GRC tools often fail to reduce identity risk on their own?
• Why do access reviews often fail to reduce real risk?