Why does automated access review still fail if approvals do not change live permissions?

Why certification can fail when it does not touch the live entitlement

access review only has governance value when the review outcome changes the authoritative permission state. If reviewers approve, reject, or comment, but the entitlement stays active in the target system, the process produces evidence without correction. That leaves the organisation with a paper trail, not risk reduction, because the exposure remains exactly where it was.

In practice, the failure is usually a workflow design problem. The review campaign is separated from remediation, so the approval record is treated as the finish line instead of the trigger for change. A proper closed-loop design connects certification to provisioning, deprovisioning, or privilege adjustment so the entitlement state matches the decision.

Why “looked at” is not the same as “fixed”

Certification is an assurance control, not a control outcome by itself. It tells you that an owner or manager acknowledged the access, but it does not prove the access was removed, reduced, or re-scoped. If the live system is not updated, stale access, excess privilege, and orphaned entitlements continue to exist after the review closes.

That gap matters even more when access is recertified on a schedule. Repeating a review campaign against unchanged entitlements can create confidence that the estate is being governed, while the actual blast radius stays untouched. For that reason, the question is not whether the review was completed, but whether the entitlement state changed because of it.

What closes the loop on access governance

The control needs an explicit handoff from certification to enforcement. The approval result should either update the entitlement automatically or raise a tracked remediation task with ownership, due date, and verification. In other words, the review must be connected to the system that grants access, not just the reporting layer that describes it.

For machine, service, and other non-human access, that connection is especially important because the same identity can be reused across systems and environments. If a review flags excessive privilege but nothing revokes the credential, key, token, or role, the risky access remains usable. Access Reviews and Certification Guide is useful here because it focuses on closed-loop remediation rather than review activity alone. IAM and IGA Basics helps frame why access review is part of a broader governance lifecycle, not a standalone event.

Risk and Threat Considerations

When approval does not change live permissions, the organisation gets false assurance. Attackers, insiders, and simple operational drift all benefit from the same failure mode: the review says “approved” or “resolved,” but the access path remains open.

Failure mechanism: The certification workflow records a decision in one system while the entitlement remains active in another, so review outcomes do not propagate to the authoritative access control point.

Impact: Excess privilege, stale access, and compromised accounts continue to be usable, which preserves exposure, weakens audit defensibility, and can support later abuse of the same entitlement.

Practitioner Guidance

What to verify: Test a sample of review outcomes end to end. For every revoked or reduced entitlement, confirm the live permission, group membership, role assignment, token scope, or credential state actually changed in the target system.

Common mistake: Treating “review completed” as evidence of control effectiveness. A completed certification campaign is only a control input unless you can show the entitlement was corrected and the correction was verified.

Practitioner takeaway: If the review does not force a state change, it is governance theatre. The control only becomes meaningful when the approval result updates the live access model and you can prove that it did.

Related resources from NHI Mgmt Group

• When should organizations review access controls?
• How do automated lending journeys change access review and accountability?
• Who is accountable when automated IAM workflows make access changes that fail audit review?
• What breaks when an AI agent can review a vendor assessment but also access customer records or change permissions?