Why do access reviews keep finding the same problems every quarter?

Why This Matters for Security Teams

Quarterly access reviews keep surfacing the same findings when the organisation is using attestation as a detection tool instead of a control fix. If contractor access is never fully removed, if role changes do not trigger entitlement cleanup, or if service account ownership is unclear, the review will simply rediscover the same residue. That is especially true for NHI sprawl, where Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x in modern enterprises. Static review cycles cannot keep pace with dynamic joiner-mover-leaver events or machine identities that never get properly retired.

Industry guidance points in the same direction. The OWASP Non-Human Identity Top 10 treats excessive privilege, credential sprawl, and weak lifecycle controls as recurring risk patterns, not one-time exceptions. In practice, many security teams encounter the same access issue only after the next attestation wave has already confirmed that the workflow still has not been fixed.

How It Works in Practice

The root cause is usually lifecycle management, not the review itself. Access reviews are backward-looking: they verify whether access is still appropriate at a point in time. If provisioning, change management, and deprovisioning are poorly connected, the attestation process keeps inheriting the same stale entitlements, contractor leftovers, and orphaned service accounts. The better control is upstream: remove access automatically when employment status changes, tie entitlements to authoritative sources, and require owners to be accountable for every identity, including NHIs.

For non-human identities, the issue is often even sharper because the identity may be embedded in CI/CD pipelines, applications, or automation tasks. The NHI Lifecycle Management Guide emphasises that visibility, rotation, and offboarding must be treated as continuous operations. Without that, reviewers see the same API keys, certificates, and service accounts every quarter because nothing in the operational flow actually revokes them.

• Connect HR, contractor, and asset systems to entitlement removal so access ends when the source record ends.
• Assign a named owner to every human and non-human identity before the review starts.
• Use policy-as-code or workflow automation to flag and revoke stale access outside the quarterly cycle.
• Track exceptions separately so recurring findings can be traced to a process failure, not just an approver mistake.

Security teams should also distinguish between visibility gaps and control gaps. If a team cannot see all accounts, it cannot attest them accurately. If it can see them but still leaves them in place, the failure is operational. NHIMG research notes that only 5.7% of organisations have full visibility into their service accounts, which helps explain why reviews often become repetitive hygiene exercises rather than remediation events. These controls tend to break down when identity sources are fragmented across HR, IAM, cloud consoles, and CI/CD pipelines because no single workflow owns the full removal path.

Common Variations and Edge Cases

Tighter lifecycle control often increases operational overhead, requiring organisations to balance removal speed against business continuity. That tradeoff is especially visible in shared admin accounts, third-party support access, and legacy applications that cannot yet support automated deprovisioning. In those environments, the right answer is not to accept recurring review findings, but to document compensating controls and a migration plan.

Best practice is evolving for machine identities and agentic workloads. Some teams still treat service accounts like ordinary user accounts, but that model misses the fact that secrets, tokens, and certificates may be tied to pipelines, workloads, or autonomous agents rather than people. For those cases, current guidance suggests pairing attestation with stronger lifecycle controls, such as short-lived credentials, ownership metadata, and automated expiry. The 52 NHI Breaches Analysis shows why repeated exposure matters: unresolved identity weaknesses tend to compound, not self-correct.

There is no universal standard for what counts as an acceptable recurring exception. The practical test is whether the same finding has a named root cause, a control owner, and a dated remediation plan. If not, the next quarterly review will usually find the same problem again.

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?
• Why do access reviews still fail even when completion rates are high?
• How should teams make user access reviews sustainable at scale?