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

Why This Matters for Security Teams

When a former user still has SaaS access, the issue is not just whether the account was disabled in one directory. The real risk is lingering entitlement across apps, tokens, group memberships, and delegated access paths that were never tied back to offboarding. That makes accountability a governance problem spanning identity, SaaS administration, and application ownership. The OWASP Non-Human Identity Top 10 is useful here because it frames identity sprawl and credential persistence as systemic control failures, not isolated mistakes.

NHI Management Group research shows only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotation. The same pattern appears in user access cleanup: a single termination event can leave behind valid access in SaaS platforms, support tools, and API-connected workflows. The question of accountability matters because the owner of the identity lifecycle is accountable for proving removal, while the application owner is accountable for ensuring the application actually honours that removal. In practice, many security teams discover residual access only after an audit, incident, or data export has already exposed the gap.

The underlying lesson is that offboarding is only complete when every identity binding, session, and delegated token has been reconciled across the full estate, not when the HR record says the user is gone.

How It Works in Practice

Accountability should be mapped to control ownership, not to whichever team notices the problem first. Identity teams typically own the joiner-mover-leaver workflow, but SaaS and application owners must ensure their systems consume termination signals, revoke active sessions, and remove direct and indirect entitlements. That includes SSO assignments, local SaaS accounts, OAuth grants, API keys, shared mailboxes, and service integrations. If an application can retain access after the source identity is closed, the application owner shares accountability for the gap.

In mature environments, the offboarding process is event-driven and verified. HR or an authoritative system triggers a workflow, the identity platform propagates the change, and the receiving SaaS application confirms removal. Where possible, access is checked through periodic reconciliation rather than assumed from a ticket closure. NHI Management Group’s Ultimate Guide to NHIs notes that 68% of organisations do not know how to fully address NHI risks, which is a useful signal that visibility and ownership boundaries are often unclear across both human and non-human access paths.

• Define one accountable owner for termination orchestration and one accountable owner per SaaS application for enforcement.
• Revoke active sessions, refresh tokens, API keys, and delegated grants, not just the primary login.
• Verify removal with post-offboarding checks against SaaS audit logs and entitlement inventories.
• Escalate exceptions where local admin rights or shadow accounts bypass central identity controls.

For breach patterns that show how token persistence becomes real exposure, NHI Management Group’s analyses of the Salesloft OAuth token breach and the Snowflake breach are especially relevant. These controls tend to break down when SaaS is provisioned outside central IAM, because local app administrators can preserve access after the enterprise offboarding workflow has completed.

Common Variations and Edge Cases

Tighter offboarding often increases operational overhead, requiring organisations to balance rapid removal against business continuity and application-specific exceptions. That tradeoff is especially visible in SaaS portfolios where some access is shared, delegated, or tied to third-party integrations rather than a single named user.

There is no universal standard for this yet, but current guidance suggests treating every residual access path as an owned control failure until proven otherwise. If a former user can still access data through a long-lived session, an app-specific password, or a connected OAuth app, the issue is not merely stale provisioning. It may also indicate poor segregation between human accounts and automated access paths, which is why the same governance model used for NHIs should inform offboarding reviews.

This is where evidence matters. The accountable owner should be able to show when access was removed, which systems confirmed removal, and what exceptions remain open. If no one can produce that chain of custody, accountability has not been assigned in a way that can survive an audit or incident review. The Ultimate Guide to NHIs — Key Challenges and Risks is a strong reference point for understanding how hidden access and poor visibility turn a simple offboarding miss into a broader governance failure.

Related resources from NHI Mgmt Group

• Who is accountable when former employees still have SaaS access after offboarding?
• Who is accountable when former employees still have admin access?
• Who is accountable when a former employee still has access after offboarding?
• Who is accountable when a departing user still has access to applications?