They assume managers can make accurate decisions from entitlement lists alone. In practice, managers need identity history, role context, and business justification to avoid rubber-stamping. Without that support, certifications become a bottleneck that preserves unnecessary access instead of removing it.
Why manager-led certification breaks down
Manager-led access certification fails when it treats review as a simple approval task rather than a decision about whether access still fits the job. Entitlement lists show what exists, but not why it exists, how it was granted, or whether it is still needed. That gap is why reviews drift toward rubber-stamping, especially in large or fast-changing teams.
The core problem is not that managers are careless, but that they are often under-informed. A reviewer needs enough context to tell the difference between legitimate inherited access, temporary elevation, and stale privilege. Without that context, certification becomes a record-keeping exercise instead of a control that removes unnecessary access.
Good certification depends on decision quality, not just decision ownership. Where organisations only ask managers to validate names and entitlements, they create an unrealistic expectation that business supervision alone can compensate for poor identity data, weak role design, or missing justification trails.
What information managers need to decide correctly
Effective review decisions require identity history, role context, and business justification. Identity history shows whether access was recently granted, inherited from a prior role, or left behind after a transfer. Role context shows what the user is supposed to do now, while justification explains why the access was approved in the first place.
That context also helps managers spot when entitlement volume is hiding risk. A long list of access rights is hard to evaluate if the reviewer cannot see which permissions are privileged, which are shared, and which belong to systems the employee no longer supports. Access reviews and certification guidance should therefore centre on evidence that helps remove access, not merely approve it.
Managers also need a usable model of ownership and role design. If business roles are vague, overbroad, or inconsistently applied, the reviewer cannot tell whether a permission is necessary or just historically convenient. That is why access certification and role governance belong together rather than being treated as separate administrative chores.
How to make certifications remove access instead of preserving it
Certification works best when it is tied to lifecycle and governance data, not just a snapshot of current entitlements. A reviewer needs to know whether the user moved teams, changed duties, lost a project, or inherited access through a role that no longer fits. IAM and IGA basics provide the underlying model for combining provisioning, entitlements, and review into one governance flow.
Review design should also reduce cognitive load. Narrow the number of items per decision, group access by application or business function, and surface exceptions that deserve attention first. That is the practical difference between a certification campaign that scales and one that merely creates backlog.
When the organisation cannot supply enough context, the review process should not pretend the decision is sound. In those cases, the right response is to enrich the data or route the item for investigation, rather than asking the manager to guess. Identity visibility and intelligence platforms are useful here because they help connect access, role, and usage signals into a reviewable picture.
Risk and Threat Considerations
Weak certifications do not just waste reviewer time, they preserve access that should have been removed. The result is privilege creep, dormant access, and a larger blast radius when a user account is compromised or misused. In shared or high-change environments, the same failure mode can also leave toxic permission combinations untouched.
Failure mechanism: The reviewer lacks enough context to challenge the entitlement, so the access is approved by default or deferred into backlog. Over time, the certification program becomes a bottleneck that normalises excess access instead of eliminating it.
Impact: Unnecessary access remains active, remediation slows down, and audit evidence becomes weaker because the organisation cannot show that approvals were informed, risk-based, and actually effective.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Manager-led certification is a periodic account and entitlement review activity. |
| AC-6 — Least Privilege | The page centres on stopping excess access from surviving review. | |
| IA-5 — Authenticator Management | Certification often uncovers stale credentials and access paths that should be revoked. | |
| Recommendation — Require periodic review and removal of unnecessary account access. Limit access to only what current duties justify. Revoke or rotate authenticators when access is no longer needed. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access reviews are part of governing who should retain access. |
| A.5.18 — Access rights | The question is about deciding whether access rights remain appropriate. | |
| Recommendation — Review access rights on a defined schedule and remove unjustified access. Validate that access rights still match business need and role. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | CIS prescribes managing and reviewing access so excess rights do not persist. |
| Recommendation — Centralise access review and remove permissions no longer required. | ||
Practitioner Guidance
What to prioritise: Put the highest-risk decisions first, such as privileged access, access tied to sensitive systems, and entitlements that outlive role changes. Review volume matters less than whether the items most likely to cause exposure are handled with enough context to produce a real decision.
What to verify: Before trusting a certification cycle, verify that each reviewed item includes current role, business owner, grant reason, and a clear path to removal. If reviewers cannot see why access exists, they are not in a position to certify it responsibly.
Common mistake: Treating manager approval as proof of necessity. A manager can usually confirm business relevance, but not always entitlement design, system-specific privilege, or whether the access should have expired already.
Practitioner takeaway: The goal of certification is not to ask managers to recognise entitlement names, it is to give them enough decision context to confidently remove access that no longer belongs.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org