Why do manual access certification campaigns fail in business applications?

Why This Matters for Security Teams

Manual access certification campaigns look simple on paper, but they break down when reviewers are asked to approve technical entitlements without enough operational context. Business applications often expose permission names, inherited roles, and indirect group memberships that do not clearly show what a user can actually do. That makes the review task cognitive, not procedural, and spreadsheets plus email reminders are a poor control for cognitive decisions. The result is stale access, rubber-stamped approvals, and a false sense of governance. This is a recurring issue in entitlement review programs discussed in the OWASP Non-Human Identity Top 10 and in NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks, where identity sprawl and weak visibility are treated as root causes rather than admin inefficiencies. In practice, many security teams encounter toxic access only after an audit finding, a fraud case, or a privilege misuse incident has already exposed the gap.

How It Works in Practice

Effective campaigns fail when the review unit is the permission string instead of the business capability. A reviewer may see “AP-GL-OPS-07” or “Finance Power User” and have no reliable way to judge whether the entitlement still matches the employee’s job function, whether it is inherited through a role, or whether it enables sensitive downstream actions. That is why current guidance suggests enriching reviews with business context, last-used data, approval history, system ownership, and risk scoring rather than simply accelerating the same old spreadsheet workflow.

Practitioners usually improve outcomes by combining three controls: first, map technical entitlements to business-readable descriptions; second, use policy logic to flag dormant, privileged, or conflicting access; third, route only high-risk or ambiguous items to human reviewers. Where possible, review evidence should include access recertification history, application owner attestations, and whether access was recently exercised. NHIMG’s 52 NHI Breaches Analysis shows how weak identity visibility becomes an operational weakness once access is left in place too long, while the Ultimate Guide to NHIs explains why identity sprawl demands richer context than a flat entitlement list. Teams should also align review design with least privilege and authoritative logging, as reflected in NIST asset and access governance guidance. These controls tend to break down in environments with thousands of legacy entitlements, poorly documented role inheritance, or applications that cannot expose meaningful metadata.

• Translate technical permissions into business actions reviewers can understand.
• Prioritise privileged, dormant, and orphaned access for deeper scrutiny.
• Use automation to enrich decisions, not just to batch approvals faster.
• Require clear ownership for each application and entitlement set.

Common Variations and Edge Cases

Tighter access certification often increases operational overhead, requiring organisations to balance review quality against reviewer fatigue and close-cycle deadlines. That tradeoff matters because not every application deserves the same treatment. High-risk systems, regulated data stores, and admin consoles usually need stronger scrutiny, while low-risk application access may be better handled through exception-based sampling or continuous controls. Best practice is evolving, and there is no universal standard for how much context is “enough” for every review.

Edge cases usually appear where entitlements are nested, shared, or assigned through multiple layers of roles and groups. In those environments, a reviewer may approve access they do not fully understand because the UI hides effective permissions behind abstraction. Another common failure mode is service or non-human access being included in human certification cycles, which can create meaningless attestations unless the review is separated by identity type. NHIMG’s research on the Sisense breach and the DeepSeek breach illustrates how poor visibility into access and secrets can become a broader security failure, not just an audit issue. The practical rule is simple: if the reviewer cannot tell what the access actually enables, the campaign is measuring process completion, not access risk.

Related resources from NHI Mgmt Group

• How should security teams reduce manual effort in access certification campaigns?
• Should organisations exclude birthright access from certification campaigns?
• Why do manual access reviews fail for privileged identities?
• Why do manual access reviews fail in growing enterprises?