What happens when a departing employee or compromised user keeps active access to cloud applications?

Active access after offboarding or compromise leaves enterprise accounts exposed even if passwords are changed later. The user may still reach SaaS applications, view sensitive files, or misuse stored sessions. A strong control revokes access tokens at the session level, which closes that gap faster than relying on manual follow-up or password changes alone.

Why Active Cloud Access After Offboarding Becomes a Security Problem

When access remains active after a departure or compromise, the issue is not just that a password might be stale. Cloud applications often keep authenticated sessions, refresh tokens, delegated grants, and app-specific authorisations alive independently of the user’s original sign-in. That means the user can continue to reach SaaS data, workflow tools, and shared content even after the organisation believes the account has been “handled.” For that reason, offboarding and incident response must treat session and token revocation as first-class controls, not as a clean-up step. A useful baseline discussion of control expectations appears in NIST SP 800-53 Rev 5 Security and Privacy Controls, which is helpful when teams need to align account revocation with broader access governance. In practice, many organisations discover this gap only after a former user or compromised account has already retained access through a live session or an unattended OAuth-style grant.

How Session-Level Revocation Closes the Gap

Cloud access usually persists through more than one mechanism, so the response must also be layered. Changing a password may block future interactive logons, but it does not necessarily invalidate browser sessions, mobile tokens, API tokens, or third-party application consents. The correct operational sequence is to identify the account, revoke active sessions, invalidate refresh tokens where the platform supports it, remove application grants, and then confirm that the account can no longer authenticate through alternate paths.

For SaaS-heavy environments, that sequence matters because the attack surface is distributed across identity provider state, application session state, and connected application permissions. If any one of those remains active, the user may still access files or continue background actions even after the account appears disabled in one system. This is why offboarding and compromise handling should be measured against observable revocation completion, not just ticket closure or password reset status.

Prioritise session invalidation where the platform exposes it, because it shortens the exposure window immediately.
Remove delegated grants and connected app permissions, since those can survive a simple password change.
Verify that high-value SaaS platforms reflect the disable action consistently, especially where single sign-on and direct app logins coexist.
Retain evidence that revocation completed, including timestamps and the systems involved.

Where organisations rely on manual follow-up, the guidance breaks down quickly during large offboarding waves, incident response pressure, or multi-cloud application sprawl.

Edge Cases in SaaS, SSO, and Shared Application Access

Tighter revocation often increases operational overhead, requiring organisations to balance speed against false interruption of legitimate shared workflows. This is especially true when applications support long-lived sessions, offline tokens, or separately managed vendor integrations.

Not every cloud application behaves the same way. Some will honour a central identity provider sign-out immediately, while others keep local sessions alive until expiry or until a specific API call is made. Shared mailboxes, team workspaces, and delegated admin functions can also complicate offboarding because the account may no longer be needed for personal use but still be linked to group ownership or automation. The correct interpretation is that “disabled” is only meaningful when it removes all practical paths back into the application.

Guidance vs consensus: there is broad agreement that password changes alone are insufficient, but some platforms still require provider-specific revocation steps to fully close existing sessions. Teams should therefore verify how each critical application handles logout, refresh-token invalidation, and consent removal rather than assuming uniform behaviour.

The OWASP Non-Human Identity Top 10 is not directly relevant to this question because the core issue is human account offboarding and compromise, not machine identity governance. Likewise, broad identity control advice is only useful here when it explains the persistence of sessions and grants across cloud applications. For teams managing mixed SaaS estates, the practical question is not whether access was disabled somewhere, but whether every remaining access path was actually eliminated.

Risk and Threat Considerations

Active access after offboarding or compromise creates a direct exposure window for data theft, unauthorized actions, and account misuse. The primary risk is persistence: the user may continue to operate inside cloud services through sessions or tokens even after the organisation believes access has been removed.

Failure mechanism: Password resets and account disables do not always revoke browser sessions, mobile tokens, API tokens, or third-party application grants, so the attacker or former employee can keep using already-issued trust credentials until they expire or are explicitly invalidated.

Impact: Sensitive files can be viewed or exported, messages and workflows can be altered, and privileged SaaS functions can be abused before defenders realise the access path is still live.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AA-1 — Identity and Access Management	Cloud offboarding depends on timely removal of active access paths.
Recommendation — Enforce rapid deprovisioning and session revocation for users leaving or compromised.
CIS Controls v8	5.3 — Disable Dormant and Expired Accounts	Stale cloud access after departure is an account lifecycle failure.
	6.3 — Account Management	Account state must reflect removal of all active cloud access rights.
Recommendation — Disable and verify removal of access for departing or compromised accounts. Revoke active sessions and application grants when account status changes.
MITRE ATT&CK	T1078 — Valid Accounts	Compromised or retained accounts let actors use legitimate cloud access.
Recommendation — Hunt for misuse of valid cloud accounts and invalidate retained sessions quickly.
NIST SP 800-63	AAL2 — Authentication Assurance Level 2	Assurance is undermined if authenticated sessions survive account removal.
Recommendation — Tie assurance decisions to session invalidation, not just credential reset.

Practitioner Guidance

What to verify: Confirm that your offboarding and incident-response process revokes live sessions, refresh tokens, and app consents for every high-value cloud application. A disabled account that still authorises an active session should be treated as incomplete remediation, not a successful closure.

Common mistake: Treating a password reset as equivalent to access removal. In cloud environments, that shortcut misses the state that actually keeps the user inside the application, which is why post-change validation matters more than the change itself.

Practitioner takeaway: The control is only effective when it removes the whole access chain, not just the primary login credential, so teams should validate revocation at the application session level before declaring an account safe.