Who is accountable when a departed user still has access?

Why This Matters for Security Teams

A departed user with live access is not just an HR cleanup miss. It is a control failure across identity lifecycle, application ownership, and approval governance, and it often becomes visible only after data access, privilege misuse, or audit findings. The risk is amplified when human offboarding and non-human access revocation are treated as separate problems, even though both are part of the same trust boundary. NHI Management Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal offboarding and key-revocation processes, which helps explain why access lingers after departure. OWASP’s Non-Human Identity Top 10 also treats lifecycle governance as a core exposure area, because stale credentials and orphaned access are usually organisational failures, not isolated technical bugs. In practice, many security teams encounter the problem only after an access review or incident has already exposed how incomplete the offboarding chain was.

How It Works in Practice

Accountability should be assigned to the people who can actually remove the access, verify the removal, and prevent recurrence. That usually means HR owns departure notification, IAM operations executes deprovisioning, application owners confirm local access removal, and the business manager validates whether any residual access is still justified. Where there is a privileged path, PAM owners may also need to revoke shared or elevated credentials. Current guidance suggests this should be handled as an end-to-end workflow, not as a single ticket. The practical control set is straightforward:

• Trigger offboarding from a trusted departure event, not from manual follow-up.
• Revoke directory access, SSO sessions, tokens, and application-specific entitlements in the same workflow.
• Confirm that secrets, API keys, and service accounts tied to the departed user are rotated or removed.
• Require evidence of completion from the identity owner and the system owner before closure.
• Escalate exceptions where the business wants temporary retention with explicit time limits.

This aligns with the lifecycle and governance emphasis in the Ultimate Guide to NHIs — Key Challenges and Risks and with the operational risk framing in OWASP’s Non-Human Identity Top 10. For application teams, the key point is that revoking a central account does not guarantee revocation everywhere else; local entitlements and cached secrets often survive the departure. These controls tend to break down in federated environments with unmanaged SaaS apps and long-lived API credentials because no single team has full visibility into every access path.

Common Variations and Edge Cases

Tighter offboarding control often increases operational overhead, requiring organisations to balance speed of termination against completeness of revocation. That tradeoff is real when the user holds access across many systems, especially where some applications lack SCIM, API-based deprovisioning, or central logging. In those cases, current guidance suggests treating the application owner as accountable for confirming manual removal, while IAM remains accountable for orchestrating and proving the workflow. There is also an important distinction between human access and shared or delegated access. If a departed user was the only person who knew a credential, the issue is not just account closure but secret recovery, rotation, and possible compromise assessment. If a manager approved temporary post-departure access, the manager shares accountability for the exception until it expires. If legal hold or investigations require retention, that exception should be documented, time-bound, and reviewed separately from standard offboarding. The 52 NHI Breaches Analysis is a useful reminder that stale identities and forgotten credentials commonly become persistence paths rather than harmless leftovers. The practical rule is simple: if no named owner can prove who approved, who removed, and who verified, then accountability has not been assigned at all.

Related resources from NHI Mgmt Group

• Who is accountable when a departed user or service account still has access?
• Who is accountable when a departing user still has access to applications?
• Who is accountable when a former user still has SaaS access?
• Who is accountable when a user can sign in but still cannot access the required API?