Why do access reviews fail when they become too manual at scale?

Why This Matters for Security Teams

Manual access reviews fail because the control becomes a human throughput problem, not an identity governance problem. Once reviewers face long entitlements lists, overlapping approvers, and repetitive decisions, they start optimising for speed instead of scrutiny. That is especially dangerous for non-human access, where service accounts, API keys, and automation identities often outlive the workflow that created them. Guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s Ultimate Guide to NHIs both point to the same operational issue: governance weakens when identity review depends on memory and spreadsheet discipline rather than continuous, evidence-based controls. One NHIMG research finding underscores the scale problem: only 44% of developers are reported to follow security best practices for secrets management in The State of Secrets in AppSec, showing how easily weak practices accumulate faster than teams can review them. In practice, many security teams discover stale access only after an audit exception, incident, or failed certification cycle has already exposed the gap.

How It Works in Practice

At scale, the core failure is not that reviews exist, but that they are too expensive to execute with sufficient judgment. Each manual campaign forces reviewers to answer the same question repeatedly: does this principal still need this access, and can that decision be justified now? For human users, that is already tedious. For non-human identities, the problem compounds because access is often technical, indirect, and poorly understood by business owners.

Practical review design starts by reducing the reviewer’s cognitive load before asking for a decision. Mature programs typically pre-populate entitlement context, group related permissions, flag unusual privilege, and separate business-critical access from routine low-risk access. For NHIs, that means tying review records to workload purpose, owning system, last-used signals, and expiry date rather than presenting a flat list of credentials. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is a useful reference for understanding why these identities drift when ownership is weak or lifecycle controls are missing.

• Use risk-based scoping so reviewers see only access that is unusual, privileged, or stale.
• Attach evidence such as last authentication, last secret rotation, or workload ownership to every review item.
• Use time-bound approvals for temporary access and force revalidation when the task changes.
• Route technical entitlements to the people who can actually validate them, not just the nominal manager.

Current guidance suggests that automation should not replace accountability, but it should remove repetitive manual sorting so reviewers can focus on exceptions and true privilege. This aligns with the NHI lifecycle approach described in NHIMG’s NHI Lifecycle Management Guide. These controls tend to break down when entitlement data is fragmented across multiple directories and ticketing systems because reviewers cannot verify ownership quickly enough to make accurate decisions.

Common Variations and Edge Cases

Tighter review control often increases operational overhead, requiring organisations to balance evidence quality against reviewer fatigue. That tradeoff is real, especially in environments with thousands of entitlements, short-lived automation jobs, or many delegated approvers. There is no universal standard for this yet, but best practice is evolving toward tiered review models rather than one blanket campaign for every identity.

One common edge case is “approved by default” behaviour when campaigns are too large or too frequent. Another is delegated review, where approvers lack enough system context and rubber-stamp items to avoid bottlenecks. A third is blind spot coverage, where service accounts and machine credentials are excluded from human access reviews because owners assume the engineering team is already managing them. That assumption is usually wrong.

For non-human identities, the review question should be narrower and more operational: is this credential still needed for this workload, and does its scope still match the current job? In mature programs, this is paired with expiry, rotation, and ownership checks so the review is not the only line of defence. The OWASP Non-Human Identity Top 10 remains relevant here because stale access and poor lifecycle hygiene are usually symptoms of the same governance gap. In practice, review programs tend to fail when they try to cover every identity equally instead of focusing human attention on the highest-risk exceptions.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• When do NHI access reviews create more value than a one-time cleanup?
• When does an NHI become too risky to keep as-is?
• When do user access reviews become too risky to run manually?