Why do departed users still retain access in SaaS-heavy environments?

Because access is often spread across many applications, local roles, and unmanaged subscriptions. If the organisation does not maintain a complete inventory, revocation will miss some systems. The more fragmented the SaaS estate, the more likely access persists after employment ends.

Why This Matters for Security Teams

Departed-user access is rarely a single IAM failure. In SaaS-heavy environments, revocation depends on complete discovery, accurate ownership mapping, and timely deprovisioning across dozens of apps that often sit outside central IT. The risk is amplified when shadow SaaS, personal subscriptions, and app-local role stores create identities that do not follow HR offboarding workflows. NHIMG’s Ultimate Guide to NHIs highlights how fragmented identity surfaces undermine control, while the OWASP Non-Human Identity Top 10 shows the broader pattern: identities persist when governance assumes one system of record exists.

The practical issue is that SaaS access is often granted through multiple paths, including direct login, SSO assignment, OAuth consent, API tokens, and local admin roles. If any one of those paths is missed during offboarding, access can remain active long after employment ends. In practice, many security teams encounter lingering access only after an audit, an incident, or a licence review reveals accounts that should have been removed weeks earlier.

How It Works in Practice

Effective revocation starts with identity inventory, not ticket closure. Security and IT teams need a current map of which users can authenticate to which SaaS applications, which of those applications trust the IdP, and which maintain separate local accounts or delegated admin roles. The NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because access removal, account management, and audit logging need to be treated as operational controls, not one-time admin tasks.

In a mature offboarding flow, HR termination events should trigger a sequence of actions:

• disable the primary directory account and active SSO sessions;
• revoke OAuth grants, app passwords, and API tokens;
• remove local SaaS roles and tenant-level admin rights;
• transfer ownership of shared workspaces, mailboxes, and automation accounts;
• verify completion through application logs or SCIM-driven reconciliation.

That verification step matters because SaaS vendors do not all behave the same way. Some revoke access immediately through the IdP, while others leave existing sessions, mobile app tokens, or locally created accounts intact until a separate process runs. NHIMG’s 52 NHI Breaches Analysis is a reminder that identity sprawl is often exposed after access has already been abused, not before. Mature teams therefore combine automated deprovisioning with periodic entitlement reconciliation, because a clean HR record does not guarantee clean SaaS revocation.

These controls tend to break down when SaaS procurement is decentralised and no authoritative inventory exists for app owners, token issuers, and local admins.

Common Variations and Edge Cases

Tighter offboarding often increases operational overhead, requiring organisations to balance revocation speed against app ownership complexity and business continuity. The hardest cases are not standard employee accounts but shared mailboxes, contractor identities, acquired-company tenants, and service accounts that look human in the SaaS admin console. Best practice is evolving, but there is no universal standard for every app family yet, especially where vendors do not support SCIM, granular session revocation, or reliable audit exports.

Another common edge case is “ghost access” created by user-managed integrations. A departed user may no longer have an active password, yet an OAuth grant, refresh token, or delegated workspace role can still allow access to data and downstream tools. For that reason, current guidance suggests treating access as a lifecycle problem, not a login problem. A periodic review should include licence assignments, app-specific roles, privileged groups, device trust, and any personal or unmanaged SaaS subscription tied to corporate data.

Where SaaS estates are highly federated, teams should prioritise systems that can prove revocation through logs, not just admin console status. NHIMG’s The State of Secrets in AppSec reinforces the fragmentation problem: multiple secrets stores and uneven practice create blind spots that delay remediation. The same pattern applies to departed-user access, and it becomes especially stubborn when local tenant admins can recreate access outside central IAM.

Related resources from NHI Mgmt Group

• How should teams reduce SaaS licence waste without breaking access for users who still need it?
• Who is accountable when former users still retain access?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams run access reviews for non-human identities?