Who is accountable when a former employee still has SaaS access?

Why This Matters for Security Teams

Former employees retaining SaaS access is not just a cleanup issue. It is an identity lifecycle failure that creates unauthorized persistence, weakens audit evidence, and makes accountability hard to prove after an incident. The risk is larger when access spans SSO, direct logins, API tokens, and delegated admin roles, because each layer may have a different owner. NHI Management Group’s Ultimate Guide to NHIs shows that only 20% of organisations have formal offboarding and revocation processes for API keys, a pattern that often mirrors broader access hygiene gaps.

Security teams often assume revocation is complete once HR marks a departure or IAM disables a central account, but SaaS environments usually keep their own entitlements, tokens, and shared workspaces alive unless someone explicitly removes them. The practical question is not only who can click revoke, but who owns the full chain from exit notification to proof of removal. The OWASP Non-Human Identity Top 10 is useful here because many SaaS access paths are effectively service identities, not just human logins. In practice, many security teams encounter stale access only after a contractor return, privilege review, or incident response exercise exposes that nobody owned the complete offboarding path.

How It Works in Practice

Accountability usually needs to be split by control point, then reassembled under one named owner for the process. IAM owns central identity deprovisioning, IT operations owns endpoint and directory cleanup, and the application owner or SaaS admin owns license removal, app-specific roles, and data handoff. Without a single process owner, each team can truthfully say it completed its own task while the former employee still has access through another channel.

Best practice is evolving toward explicit offboarding runbooks with evidence at each step. A workable model includes:

• Trigger from HR or manager with a defined exit timestamp.
• IAM disables SSO and federated access first.
• SaaS admin revokes local accounts, API tokens, refresh tokens, and active sessions.
• Operations confirms device access, mailbox forwarding, and shared vault access are removed.
• Application owner validates license reclamation, data transfer, and retention obligations.
• All actions are logged for audit and incident review.

This is where NHI discipline matters even for human leavers. Shared SaaS accounts, service inboxes, bot users, and app-generated tokens can survive a personnel change if the organisation treats them as generic IT tickets. The NHI Mgmt Group Ultimate Guide to NHIs — Key Challenges and Risks is clear that visibility and ownership are recurring gaps, and the same pattern applies when a human departure leaves behind machine-like access. Current guidance suggests tying offboarding to a single accountable owner, while distributing execution across IAM, IT, and the application team.

These controls tend to break down in federated SaaS estates where local admins can create bypass paths faster than central governance can detect them.

Common Variations and Edge Cases

Tighter offboarding control often increases operational overhead, requiring organisations to balance fast separation against business continuity and evidence quality. That tradeoff becomes more visible in high-change environments such as sales, support, and engineering, where people may retain temporary access for data migration or customer handoff. The important distinction is that temporary access should be explicitly approved, time-boxed, and owned, not left implicit.

There is no universal standard for this yet, but most mature programs separate three cases. First, standard employee exits should follow a fixed revocation workflow. Second, privileged SaaS users may need immediate session termination plus post-exit review. Third, shared or delegated accounts need extra scrutiny because the named user may not be the true controller of access. The best signal of accountability is not a policy statement, but a ticket, workflow, or control register that names one process owner and records the revocation outcome. That aligns with the Ultimate Guide to NHIs emphasis on lifecycle ownership and with OWASP’s focus on reducing standing access paths across identity types.

In practice, accountability becomes disputed most often after mergers, outsourced operations, or SaaS apps with weak admin logging, because no single team can prove who still had the effective right to access.

Related resources from NHI Mgmt Group

• Who should be accountable when a SaaS application is retired but access remains?
• Who is accountable when a leaver still has SaaS access after offboarding?
• Who is accountable when former employees still have Microsoft 365 access?
• What is the difference between rotating a secret and revoking access?