What should organisations do when nobody can explain why a user still has access?

Treat the entitlement as untrusted until a data owner confirms the business need. If the access cannot be justified quickly, move it to removal or temporary restriction. Access that survives only because it was never questioned is exactly how permission sprawl becomes a security and audit problem.

Why This Matters for Security Teams

When nobody can explain why a user still has access, the issue is rarely just housekeeping. It usually means the access review process has lost its link to a real business owner, a real system of record, or a current job function. That is how dormant entitlements, inherited group membership, and old exception paths survive long after the original need has disappeared. OWASP’s OWASP Non-Human Identity Top 10 treats unmanaged identity state as a security failure, not an admin inconvenience, and the same logic applies to human access that cannot be justified.

For security teams, the danger is not only excess privilege. Unexplained access weakens audit evidence, complicates incident response, and makes least privilege impossible to defend. It also creates a false sense of control because the entitlement still appears “approved” in a directory, even when no one can explain the approval chain. NHI Management Group’s Ultimate Guide to NHIs frames identity sprawl as an operational risk, and the same pattern shows up in human access reviews when ownership is missing. In practice, many security teams encounter access drift only after an audit exception, a breach review, or a manager’s resignation exposes how thin the documentation really is.

How It Works in Practice

The safest response is to treat the entitlement as untrusted until a data owner or application owner confirms the business need. If the need cannot be confirmed quickly, the access should move to temporary restriction or removal, depending on the impact to operations. That is the operational point where governance becomes actionable: the burden is on the organisation to prove why the access still belongs, not on the reviewer to preserve it by default.

Practically, teams should work from current source-of-truth data rather than memory or legacy approvals. That means checking the entitlement against role assignments, ticket history, joiner-mover-leaver events, and application logs. If the user’s function changed, the old access should not persist just because it has not caused an incident. Best practice is to document a clear owner for each entitlement and require a time-bound revalidation path for anything ambiguous. This is especially important where broad groups, shared admin roles, and inherited cloud permissions create hidden privilege. The 52 NHI Breaches Analysis shows how unmanaged identity state often becomes visible only after attackers or auditors find it first.

• Confirm the business owner, not just the technical administrator.
• Compare the entitlement to the user’s current role and recent activity.
• Apply temporary restriction if the access is potentially useful but not yet justified.
• Remove the entitlement when no defensible need exists.
• Record the decision so the next review does not start from zero.

For evidence and broader control design, teams can also reference the Ultimate Guide to NHIs — Key Challenges and Risks alongside OWASP guidance, because permission drift behaves like identity sprawl even when the account belongs to a person. These controls tend to break down when entitlement ownership is split across outsourcing, shared services, and stale HR data because no single team feels accountable for deciding removal.

Common Variations and Edge Cases

Tighter access review often increases operational friction, so organisations need to balance revocation speed against business continuity. The hard case is not an obvious excess privilege, but an entitlement that supports an occasional task, an on-call duty, or a brittle legacy application. Current guidance suggests handling these exceptions with explicit expiry, compensating controls, and named ownership rather than leaving them as permanent exceptions, but there is no universal standard for this yet.

One common edge case is privileged access that is technically justified by a rare recovery process. Another is access inherited through nested groups, where no one remembers which group created the privilege in the first place. In both cases, the answer is not to preserve ambiguity. It is to collapse the entitlement to the smallest defensible scope and time box the exception. If the entitlement cannot be explained in one review cycle, it should be treated as an exception requiring executive visibility, not as normal access.

Security teams should also watch for “policy by inertia” in SaaS and cloud environments, where automated provisioning creates access that no one revisits. That pattern is especially risky when audit evidence is split across multiple consoles and teams. The practical test is simple: if the organisation cannot explain the entitlement in plain business terms, it cannot defend it in an audit, and it probably should not keep it.

Related resources from NHI Mgmt Group

• Who is accountable when a terminated user still has access?
• How should organisations govern access when employees, contractors and partners all need systems access?
• How should healthcare organisations manage CIS1 to CIS2 migration without disrupting clinical access?
• What do organisations get wrong when they treat host discovery as access control?