Manual recertification fails because it is both point-in-time and easy to rubber-stamp. A manager can approve access based on yesterday’s context, while an employee’s role, exposure, or risk changes moments later. The result is a control that satisfies process requirements but does not reliably prevent overexposure, especially when approvals are rushed or incomplete.
Why manual recertification breaks down as a risk control
Manual recertification is a governance checkpoint, not a live access-control mechanism. It asks a reviewer to judge whether access still makes sense at a moment in time, but the underlying exposure can change immediately after approval. In practice, that makes it useful for audit evidence and policy discipline, but weak as a dependable way to suppress overprivilege or reduce standing access risk.
The control also depends on human context that is often incomplete. Reviewers rarely see the full entitlement set, the actual usage pattern, inherited group membership, shared accounts, or the operational urgency that shaped the original grant. When access lists are long and the business process is noisy, the safest path for a reviewer is often to approve rather than challenge, which preserves process completion but not necessarily access hygiene.
That is why recertification works better when it is paired with lifecycle controls, continuous visibility, and clear ownership of access decisions. When the environment changes quickly, a periodic review can confirm that someone signed off, but it cannot by itself prove that the entitlement is still necessary, appropriately scoped, or safe to retain.
Why point-in-time review struggles with changing roles and exposure
Recertification assumes that yesterday’s answer still maps to today’s risk. That assumption breaks when employees move teams, projects end, contractors roll off, or privileged use is temporary by design. A manager may honestly attest that access was appropriate at review time, while the user’s current role, task set, or sensitivity exposure has already shifted.
This mismatch is especially visible where access is inherited through roles, groups, shared service pathways, or aggregated entitlements. The reviewer may approve a role name rather than the real permissions behind it, which hides privilege creep and makes the review less precise than it appears. The control can therefore pass in form while failing in substance.
Manual review also degrades when the interval between certifications is too long for the pace of change. The longer the gap, the more likely the decision reflects stale business context rather than current need. A periodic checkpoint cannot substitute for timely deprovisioning, scoped entitlements, or automatic expiry when access is temporary.
What a review process can prove, and what it cannot
Recertification is best understood as evidence of oversight, not evidence of effective risk reduction on its own. It can show that the organisation asked an accountable owner to make a decision, which matters for governance, compliance, and auditability. It cannot reliably show that access was accurately evaluated, that all risky entitlements were visible, or that the approval reflected informed challenge rather than routine acknowledgement.
That distinction matters because many access failures are not caused by a missing review, but by a control that is too coarse to catch practical exposure. If the reviewer sees a broad entitlement name, a familiar user, and a deadline to complete the task, the outcome often becomes a rubber stamp. The result is process completion without a meaningful reduction in blast radius.
For that reason, manual recertification should be treated as one control signal among several, not as the primary mechanism for keeping access safe. Continuous inventory, least-privilege design, timely revocation, and usage-aware review all do more to reduce exposure than a stand-alone periodic attestation cycle.
Risk and Threat Considerations
Manual recertification creates a false sense of safety when organisations treat signed approval as equivalent to safe access. The main risk is that stale or excessive permissions remain active long after the business reason has weakened, especially where reviewers lack usage data or entitlement detail.
Failure mechanism: Access changes faster than the review cycle, and reviewers approve based on incomplete context, inherited permissions, or workload pressure. That leaves dormant, excessive, or mis-scoped access in place even though the control appears to have passed.
Impact: The organisation preserves attack surface, increases insider and compromise blast radius, and may miss the chance to remove access before it is abused or misused.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Manual recertification is part of account and entitlement governance. |
| Recommendation — Use CIS-5 to review and remove unnecessary accounts and access on a recurring basis. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | The question concerns recurring review and removal of unnecessary access. |
| AC-6 — Least Privilege | Recertification should reduce excessive permissions and standing access. | |
| Recommendation — Apply AC-2 to recertify, disable, and remove accounts or privileges when no longer needed. Use AC-6 to constrain entitlements to the minimum access required for current duties. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Periodic review of access rights is directly implicated by recertification. |
| A.5.15 — Access control | The topic is about how access control weakens when approvals are stale or superficial. | |
| Recommendation — Review access rights regularly and remove permissions that are no longer justified. Define access approval and review processes that keep entitlements aligned to current need. | ||
Practitioner Guidance
What to prioritise: Treat manual recertification as an exception-handling and governance layer, not the core mechanism for risk reduction. The first question should be whether the entitlement can expire, be auto-revoked, or be reduced to a narrower scope before a human is asked to certify it.
What to verify: Reviewers should see the actual permissions, recent usage, ownership, and business justification, not just the role name or an aggregated access label. If they cannot verify those facts quickly, the control is likely producing administrative comfort rather than meaningful challenge.
Practitioner takeaway: Recertification only reduces risk when it is fed by accurate entitlement data and followed by timely enforcement; without that, it documents approval more reliably than it reduces exposure.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
