Why do former employee SaaS accounts create more risk after directory access is revoked?

Why revoked directory access does not end the SaaS risk

Directory revocation only cuts one authentication path. If the former employee still has a local password, a linked social login, a persistent browser session, or access through an app that was provisioned outside central identity control, the SaaS tenant can remain reachable. That is why offboarding must be treated as an application access problem, not just an identity-directory event. The NIST Cybersecurity Framework 2.0 is useful here because it separates identity lifecycle, access control, and asset governance into distinct control concerns rather than assuming one action resolves all three.

The practical risk is that the organisation believes access has been removed when the SaaS record still exists and can still be used. In practice, many security teams encounter this only after a former employee account is found during an audit, incident review, or customer escalation rather than through intentional offboarding validation.

How lingering SaaS access survives after offboarding

SaaS products often support more than one way to sign in, and that is where revocation gaps appear. A user may have started with SSO, then later added a direct password, a backup email factor, or a third-party login. If the directory account is disabled but the SaaS-native identity remains active, the person may still authenticate. The same problem appears when the SaaS application was approved by a business team without central lifecycle controls, because the identity team can revoke directory entitlements without touching the app account.

There is also a time dimension. Existing sessions, refresh tokens, cached device trust, and delegated app permissions can outlast the directory change for some period. That creates a window in which access appears removed in the directory but remains usable in the application. For collaboration tools, CRM systems, file-sharing platforms, and support portals, that lingering access can expose messages, customer records, and internal documents. It can also complicate evidence collection because the access path is no longer obvious from the central directory alone.

• Directory offboarding removes centralized login, but not necessarily SaaS-local authentication.
• Session persistence can preserve access until tokens or browser state are invalidated.
• Shadow IT or business-led app adoption can bypass the identity team’s normal revocation workflow.
• Unreviewed delegated access can remain even when the human account is disabled.

When this guidance breaks down, it is usually because the organisation does not know which SaaS applications accept independent logins or which users have retained alternate authentication methods.

Edge cases that make former employee access harder to see

Tighter offboarding often increases administrative overhead, requiring organisations to balance clean revocation against the reality of decentralized SaaS use. Not every case is the same, and that is where teams can overgeneralize. Some SaaS platforms are fully tied to the directory and revoke access cleanly; others allow multiple authentication paths, local admin ownership, or user-managed integrations. The industry does not always agree on how quickly every token or session should be invalidated across every platform, so the safe position is to verify the actual application behaviour rather than assume uniform enforcement.

Edge cases matter most when the former employee was an app owner, department admin, or power user who created integrations that outlive the account. Shared mailboxes, exported data, and personal devices can also preserve practical access after the primary login is gone. Another common issue is that offboarding is completed for the core productivity suite but not for connected SaaS tools that use separate identity stores. That leaves a partial revocation state, which is often enough for data exposure even if the primary account is disabled.

The main judgment is simple: if the application has more than one authentication or ownership path, directory revocation should be treated as a first step, not a closed case.

Risk and Threat Considerations

Former employee SaaS accounts create residual access risk because the trust boundary shifts from the directory to the application itself. That creates exposure when the organisation assumes a disabled central account equals removed access, even though the SaaS tenant may still permit direct login, persistent session use, or delegated access. The risk is amplified when unmanaged apps sit outside normal offboarding controls.

Failure mechanism: The control failure is incomplete identity deprovisioning. A revoked directory account does not necessarily invalidate SaaS-local credentials, existing sessions, OAuth grants, or app-specific recovery paths, so the former user can continue to authenticate through whichever path remains valid.

Impact: The result can be unauthorized access to customer data, internal documents, support systems, or proprietary information, plus audit gaps when the organisation cannot prove that all access paths were removed at the time of termination.

Practitioner Guidance

What to verify: Treat offboarding as complete only when the SaaS account, all alternate login methods, active sessions, and delegated permissions have been checked. The key test is not whether the directory is disabled, but whether any remaining application-level path still works.

What good looks like: A reliable offboarding process produces evidence that the central identity record, the SaaS account, and any connected access methods were removed or expired in a controlled sequence. Teams should be able to show which applications were in scope, which login paths existed, and what was actually disabled.

Common mistake: Many teams assume federated login means SaaS access disappears automatically. That assumption fails whenever users can authenticate locally, re-link an identity, or keep access through pre-existing tokens and sessions.

Practitioner takeaway: Directory revocation reduces risk, but only application-level verification tells you whether the former employee still has a usable path into the SaaS environment.

Related resources from NHI Mgmt Group

• Why do privileged service accounts and domain controller access create such high risk in Active Directory?
• Why do overprivileged accounts and fragmented SaaS access create so much risk?
• Why do overlooked SaaS accounts and access gaps create such high breach risk?
• Why do Active Directory service accounts create more risk than their labels suggest?