What happens when risky SaaS access is revoked without fully offboarding the user?

Partial revocation can leave residual exposure. If access is removed from one app but the user still has dormant accounts, orphaned OAuth grants, or access to other unmanaged services, the organization only reduces one symptom. Complete offboarding should remove standing access, strip sensitive scopes, and confirm that the identity no longer has a path back into the affected applications.

Why Partial Revocation Creates Hidden Access Paths

Revoking a user from one SaaS application often removes the most visible access point while leaving the broader identity footprint intact. That matters because SaaS environments commonly rely on separate account records, delegated consent, linked sessions, and third-party integrations that do not disappear automatically when one entitlement is removed. The result is a security gap between “no longer active in this app” and “fully removed from the environment.”

For practitioners, the key issue is not just authorization drift but residual trust. If the user still exists in another tenant, retains a dormant account, or has an active OAuth grant, they may still reach data, trigger automation, or regain access through a different path. The NIST Cybersecurity Framework 2.0 is useful here because it frames access removal as part of a broader lifecycle control problem, not a single deprovisioning event. In practice, many teams discover the gap only after an audit, a license cleanup exercise, or an incident review reveals that the user was never fully offboarded.

How SaaS Offboarding Actually Breaks Down

Full offboarding is a sequence, not a button click. The first step is to revoke the primary app entitlement, but that only addresses one control surface. Teams also need to remove active sessions, deactivate or delete the user record where the SaaS platform allows it, remove group memberships, and review whether the account is still linked to sign-in methods such as SSO, local passwords, or recovery options. If those relationships remain, the user can sometimes return through a back door even after the “main” access has been removed.

OAuth and API integrations make this more complicated. A revoked human account does not automatically invalidate every consented app, delegated token, or service connection that the user previously approved. That means the organisation may still have a live path to data or actions even after the employee, contractor, or partner is supposedly removed. Where the SaaS platform supports it, administrators should also check whether shared mailboxes, delegated admin roles, or workspace-level permissions still point back to the former user.

Revoke the visible app entitlement and verify the change propagated everywhere the identity is referenced.
Check for dormant accounts in connected SaaS tools, not only the primary application.
Review OAuth grants, API tokens, and delegated access for residual permissions.
Confirm that recovery paths, alternate sign-in methods, and shared roles no longer permit re-entry.

Good offboarding is measurable: the identity should have no standing access, no usable grants, and no unmanaged path back into the environment. OWASP Non-Human Identity Top 10 is relevant only as a secondary lens here, because the same residual-grant problem that affects service connections can also appear in SaaS automation and delegated access. This guidance breaks down when the organisation cannot inventory all linked applications or lacks administrative control over the SaaS tenant boundaries.

Edge Cases That Leave Access Behind

Tighter offboarding usually improves security, but it also increases operational overhead because every extra connection, tenant, and delegated permission has to be verified before the account is considered closed. Organisations must balance that effort against the risk of assuming that one revoked login equals full removal.

Shared licences, contractor accounts, federated sign-in, and invite-based collaboration are common edge cases. A user may no longer have direct access to the source SaaS app but still be present in a downstream workspace, a partner portal, or a shadow IT service that never participated in central provisioning. Another common exception is when the organisation removes access from the identity provider but leaves app-local accounts untouched; in those cases, the SaaS platform may still accept alternate credentials or retained recovery methods. There is no full consensus that every SaaS offboarding workflow must be identical across vendors, but there is broad agreement that the verification standard must match the sensitivity of the data and the scope of the user’s prior access.

The most important edge case is when removal is only partial because the organisation cannot see the full dependency map. If access was granted through a nested group, an external collaboration link, or a token-based integration, the apparent revocation may be cosmetic rather than real. That is why teams should treat offboarding as an evidence problem, not a courtesy task: they need proof that the identity can no longer authenticate, authorise, or be reintroduced through another route.

Standards & Framework Alignment

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

MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC-4 — Access Permissions and Authorizations	Partial revocation is an access lifecycle failure, not a single-app event.
	PR.AC-1 — Identities and Credentials Issuance and Management	Dormant accounts and leftover credentials keep the identity usable after revocation.
	DE.CM-8 — User Activity Monitored	Residual access is often found only by checking whether the old identity still acts.
Recommendation — Verify access removal across every bound system and revoke any remaining authorizations. Retire the identity and its credentials everywhere they can still authenticate. Monitor for any continued activity from identities that should have been fully offboarded.
CIS Controls v8	6.3 — Disable Dormant Accounts	Dormant SaaS accounts are a direct residual-access path after partial revocation.
	6.4 — Manage Access Permissions	Revoking one app without removing other permissions leaves effective access intact.
	6.5 — Account Lifecycle Management	Offboarding requires end-to-end account retirement across the SaaS lifecycle.
Recommendation — Disable inactive accounts and confirm they cannot be reactivated through alternate paths. Review and remove all remaining permissions linked to the departing user. Apply lifecycle controls so account closure also removes tokens, roles, and recovery access.
MITRE ATT&CK	T1078 — Valid Accounts	Orphaned accounts and grants preserve valid-account access after nominal revocation.
	T1098 — Account Manipulation	Residual roles, tokens, and delegated grants reflect account state that still enables access.
Recommendation — Hunt for surviving valid accounts and close every alternate authentication route. Audit account and permission changes to remove lingering delegated access.
OWASP Non-Human Identity Top 10	NHI-01 — Inventory and Ownership	SaaS revocation often fails when linked non-human or delegated identities are not inventoried.
Recommendation — Inventory every associated identity and revoke ownership-linked access paths.

Practitioner Guidance

What to prioritise: Treat offboarding as complete only when you can account for the user’s direct account, delegated grants, recovery paths, and any connected SaaS copies of that identity. The critical judgement is whether the organisation can still re-authenticate the same person through a different trust path.

What to verify: Confirm that the removal is reflected in the identity provider, the SaaS tenant, and any linked application permissions. If one of those layers still shows the user as eligible, the offboarding is not finished.

Common mistake: Teams often stop after revoking the most obvious app access and assume the residual grants will age out on their own. That assumption is weakest in environments with long-lived tokens, app-specific accounts, or federated collaboration.

Practitioner takeaway: Partial revocation reduces visible exposure, but only complete offboarding eliminates the user’s practical ability to return through another SaaS or delegated access path.