Who is accountable when former users still retain access?

Why This Matters for Security Teams

Former-user access is not a minor housekeeping issue. It is a control failure that can turn an approved business change into an active exposure window. When joiner-mover-leaver processes are fragmented, the revocation event can be triggered on time while the actual removal lags across SaaS apps, directories, and API-driven systems. That gap creates residual access that bypasses intent and undermines accountability. OWASP’s OWASP Non-Human Identity Top 10 highlights how unmanaged identities and credentials become persistent attack paths, and NHIMG research on the Ultimate Guide to NHIs shows how quickly identity sprawl erodes visibility once ownership is unclear.

The practical risk is simple: if access survives the employee, contractor, or partner relationship, it can be reused, forwarded, or abused long after the business no longer expects it. That matters for privileged accounts, shared admin roles, machine credentials, and shadow integrations alike. In practice, many security teams encounter former-user access only after an audit finding, a suspicious login, or a breach investigation has already exposed the gap.

How It Works in Practice

Accountability should be assigned to the party that owns the access lifecycle end to end, not just the team that receives the termination notice. HR, procurement, or vendor management usually triggers the event, but IAM, IGA, application owners, and platform administrators are responsible for making revocation complete, timely, and verifiable. Good control design separates notification from enforcement: the business event starts the workflow, while system owners confirm every dependent entitlement has been removed.

Practitioners usually need four steps:

• Define the authoritative source for termination, role change, or contract end.
• Map every identity to the systems where access must be removed, including SaaS, VPN, SSO, PAM, and service accounts.
• Automate deprovisioning with approval tracking, exception handling, and evidence capture.
• Reconcile post-deprovisioning reports to detect orphaned accounts and stale entitlements.

This becomes especially important for non-human identities because former employees often leave behind API keys, shared tokens, CI/CD credentials, or delegated admin rights that are not tied cleanly to a single human account. The same pattern appears in NHIMG analysis of the 52 NHI Breaches Analysis, where delayed revocation and poor ownership repeatedly show up as root causes. Current guidance also aligns with identity assurance thinking in CISA’s Zero Trust Maturity Model and NIST SP 800-207, which both emphasize continuous verification and minimized standing access. These controls tend to break down when applications keep their own local accounts and no one owns the final deprovisioning step because revocation then depends on manual follow-up rather than an enforced workflow.

Common Variations and Edge Cases

Tighter revocation control often increases operational overhead, requiring organisations to balance faster removal against business continuity and exception handling. That tradeoff becomes visible in environments with shared accounts, legacy systems, outsourced operations, and federated SaaS platforms where the identity owner cannot directly remove every permission.

There is no universal standard for this yet, but current guidance suggests a few patterns. First, when the account is shared, accountability shifts toward the service owner and the control owner, because no single employee departure cleanly maps to removal. Second, when access is tied to a regulated workflow, such as finance, healthcare, or critical infrastructure, evidence of completion matters as much as the removal itself. Third, for machine identities and tokens, revocation must account for TTL, rotation, and downstream caches, or an old credential may remain valid even after the human relationship ends.

One common failure mode is assuming SSO logout equals full access removal. It does not. Local application roles, cached API tokens, service-to-service trust, and backup admin paths often survive. NHIMG guidance in the Ultimate Guide to NHIs — Key Challenges and Risks and the DeepSeek breach research both reinforce the same operational lesson: residual access is usually a process failure, not a single technical miss. Organisations should treat exceptions as time-bound, named, and auditable, because permanent exceptions quickly become invisible standing access.

Related resources from NHI Mgmt Group

• Who is accountable when former employees still retain access?
• Who is accountable when a shared device still contains the prior user's access?
• Who is accountable when former employees still have Microsoft 365 access?
• Who is accountable when a former employee still has SaaS access?