Why do access certifications fail when organizations rely on manual review alone?

Why This Matters for Security Teams

Manual access certification fails because reviewers are being asked to judge entitlement quality without the evidence that makes the decision meaningful. A human can approve or revoke a list item, but a spreadsheet rarely shows whether an access path is still active, whether the identity is a human or an NHI, whether the secret has been used recently, or whether the entitlement matches current workload behaviour. That gap is exactly why approval becomes the default outcome.

This is not just an administrative weakness. When access review cannot distinguish dormant access from actively abused access, they do not reduce risk at the pace the business expects. NHI governance research from Ultimate Guide to NHIs shows that machine identities multiply quickly across services and environments, and the OWASP Non-Human Identity Top 10 reinforces that visibility and lifecycle control are core failure points, not edge cases. Manual certification is weakest where access changes fastest and context is most fragmented. In practice, many security teams discover the review gap only after a secret or privilege path has already been used, rather than through an intentional certification signal.

How It Works in Practice

Effective certification depends on evidence, not just attestation. For NHI and workload access, that evidence should include last use, scope, owner, system-to-system dependency, secret age, rotation state, and whether the entitlement is still justified by the workload’s function. NIST SP 800-53 Rev. 5 expects access control and accountability mechanisms to be operating, but current guidance suggests those controls need automation when the population is large or volatile. For that reason, manual review should be treated as a exception-handling layer, not the primary control.

In a stronger workflow, access data is enriched before a reviewer sees it. A certification task can show whether a credential is tied to an application, whether it is a long-lived static secret or a short-lived token, and whether it has been exercised recently. That is especially important for NHIs because stale access often remains hidden behind service accounts, API keys, and automation runners. NHIMG’s The State of Secrets in AppSec notes that organisations maintain an average of 6 distinct secrets manager instances, which fragments oversight and makes central review less reliable. If the access review cannot aggregate those sources, the certification result is only as good as the least visible system.

• Pull entitlement data from IAM, PAM, secrets managers, and workload platforms before the review starts.
• Present last-used timestamps, owner, business purpose, and peer comparison to reviewers.
• Auto-expire or quarantine access that has no verified owner or no recent legitimate use.
• Route unusual or high-risk entitlements to a separate approval path instead of the standard quarterly batch.

These controls tend to break down in distributed environments with many cloud accounts, multiple secrets stores, and service accounts that are shared across pipelines because the reviewer cannot reliably reconstruct real usage from a static access list.

Common Variations and Edge Cases

Tighter certification often increases operational overhead, requiring organisations to balance governance depth against the time it takes to keep systems running. That tradeoff is why best practice is evolving toward risk-based review rather than identical treatment for every entitlement.

For low-risk human access, periodic sampling may still be acceptable. For NHIs, long-lived tokens, and privileged automation, the standard answer is less useful because the access may be technically “approved” while still being operationally dangerous. In those cases, continuous signals matter more than quarterly sign-off. Access should be reviewed when ownership changes, when the workload changes purpose, or when a secret has not been used within its expected lifecycle. OWASP’s guidance and NIST-aligned controls both point in the same direction: the control objective is not the review itself, but timely removal of unjustified access.

Edge cases also appear when organisations inherit access from mergers, vendor integrations, or legacy automation. Those environments often have no clean owner, no clear business justification, and no reliable usage telemetry. The right response is not to force a binary approve decision, but to classify the entitlement as unverified and move it into remediation. Where telemetry is unavailable, reviewers should treat the absence of evidence as a risk signal, not a green light.

Manual review also fails when the same reviewer is asked to certify both application access and underlying secrets. Those are different control problems, and conflating them hides whether the issue is stale entitlement, poor rotation, or poor inventory. The 52 NHI Breaches Analysis shows how often weak identity lifecycle practices compound once attackers find one exposed credential path.

Related resources from NHI Mgmt Group

• Why do data classification programs fail when organizations rely on manual review alone?
• When should organizations review access controls?
• When should organizations review their NHI policies?
• Why do manual access review reports fail in practice?