Offboarding gaps leave OAuth grants alive after IdP disablement

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Abnormal AI's blog post: IdP disablement often stops login but leaves OAuth grants, API tokens, and cached SaaS sessions alive, creating phantom access after offboarding.

Why it matters: IAM, IGA, and SaaS governance teams need to treat offboarding as a cross-system revocation problem, not just an account-deactivation task, because surviving grants can keep data access alive.

By the numbers:

• In Microsoft 365 without Continuous Access Evaluation, refresh tokens can survive for days after an account is disabled.

Context

Offboarding is supposed to end an identity's usable access, but in practice the revocation event often stops at the IdP boundary. OAuth grants, API tokens, delegated access, and cached SaaS sessions may remain valid in downstream applications that never receive a matching revoke signal.

This is an identity governance problem, not just an authentication problem. When access lives in the application layer after the account is disabled, monitoring that only tracks active identities will miss post-offboarding activity and create a blind spot for IAM, IGA, and SaaS governance teams.

Key questions

Q: What breaks when an IdP account is disabled but OAuth grants still remain active?

A: The assumption that account disablement equals access removal breaks down. The user can no longer sign in through the IdP, but the downstream app may still trust existing OAuth grants, refresh tokens, or cached sessions. That creates phantom access, where the identity looks gone in the directory but still has usable access in the application layer.

Q: Why do offboarding failures create security risk even when accounts are eventually removed?

A: Because delayed revocation creates a window where access remains valid after the business need has ended. During that window, the user can still act in SaaS apps, shared systems, or delegated workflows. The shorter the delay between exit and revocation, the smaller the residual risk to data and operations.

Q: How can security teams detect phantom access after a user leaves?

A: By continuing to baseline and monitor the disabled identity instead of stopping at status change. Look for token use from new locations, delegate paths that were dormant before offboarding, and API activity from credentials that should have been retired. Detection has to follow behaviour, not just account state.

Q: Should organisations prioritise token revocation or account disablement first?

A: Account disablement is necessary to stop interactive access, but revocation of OAuth grants, API tokens, and sessions is what closes the residual access window. If you have to sequence the work, disable the account to contain the user, then verify revocation in every application that can keep the credential alive.

Technical breakdown

Why IdP disablement does not revoke downstream OAuth grants

Disabling an identity provider account usually blocks interactive sign-in, but it does not automatically invalidate every token or grant issued to connected SaaS applications. OAuth grants are authorization artefacts held by the relying app, not by the IdP alone, so revocation depends on the application receiving and processing a separate event. If the app never gets that signal, the access path can persist even though the user is offboarded in the directory. This is why account shutdown and access shutdown are not the same thing.

Practical implication: Map every offboarding step to the systems that actually hold the grant, token, or session, not just the directory entry.

How cached sessions and refresh tokens outlive deactivation

A session is a live authentication state, while a refresh token is a longer-lived credential that can mint new access tokens without the user signing in again. In environments without Continuous Access Evaluation, Microsoft 365 refresh tokens can remain valid for days after deactivation, and some SaaS platforms keep their own session lifetimes even longer. That means the org may disable the human identity while the application still trusts the existing token or session until expiry or explicit revocation.

Practical implication: Treat token lifetime and session lifetime as offboarding dependencies, especially where CAE is not enabled.

Why deactivated identities need continued behavioural monitoring

Most detection stacks baseline active users and stop paying attention once an account is marked disabled. That assumption breaks when a stolen OAuth token, unmanaged API key, or cached session continues generating legitimate-looking traffic after offboarding. The mechanism is simple: the access is now phantom access, so the security event appears to come from an identity the system already considers gone. Detection therefore has to move from user status to behaviour against the pre-offboarding baseline.

Practical implication: Keep monitoring disabled identities for anomalous token use, unusual geographies, and delegate paths that should have disappeared.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Offboarding gap is the wrong label for a control boundary problem: this issue is not that leaver processing failed at the HR or IdP step, but that downstream authorisation state survived where the IdP had no direct control. OAuth grants, refresh tokens, and cached sessions live in different trust stores, so deactivation is only partial unless each relying system receives and enforces revocation. The practitioner conclusion is that offboarding must be modelled as distributed access removal, not directory cleanup.

Phantom access is the governance blind spot modern IAM still underestimates: once an identity is disabled, many monitoring and recertification workflows stop treating it as an active subject. That assumption leaves post-offboarding activity outside normal review cycles, especially when access continues through a token, a delegate path, or a SaaS session cache. The implication is that lifecycle governance has to extend beyond status change into post-disablement verification and anomaly detection.

Phantom access debt: the article exposes a simple but durable failure mode where access outlives the identity record that was supposed to terminate it. This is not a theoretical edge case, because the same pattern applies to tokens stolen from vendor environments and to consumer-style SaaS grants that persist independently of the IdP. Practitioners should treat any surviving grant after disablement as retained access debt until proven otherwise.

Revocation must be provable, not assumed: the control objective is not whether an offboarding ticket closed, but whether every effective credential and session tied to that identity actually lost validity. Without that proof, the organisation is depending on best-effort propagation across systems that may never synchronise. The practitioner conclusion is to make revocation evidence a first-class governance artefact.

From our research library:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to the State of Secrets Sprawl 2026.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• Read next: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

Offboarding programmes need to be redesigned around effective access removal, not just identity disablement. When SaaS grants, delegated access, and refresh tokens survive the deactivation event, the control boundary has moved out of the IdP and into each relying application.

Phantom access debt: the practical risk is that a disabled account still produces valid traffic long after the leaver process is complete. Teams should assume that any post-disablement activity is a governance failure until revocation is confirmed at the application layer.

For practitioners

• Inventory every downstream grant created by the identity Build an offboarding inventory that includes OAuth grants, API tokens, delegated access, cached sessions, and unmanaged device sessions, then reconcile each item against the account disable event.
• Verify revocation in each relying application Confirm that every SaaS application receiving federated access can actually process revocation, and document where tokens remain valid after directory disablement.
• Keep behavioural monitoring active after offboarding Continue watching disabled identities for activity that deviates from the pre-offboarding baseline, including new geographies, unusual delegate usage, and API calls from stale credentials.
• Shorten the exposure window for refresh tokens and sessions Where possible, reduce token lifetime, require conditional reauthentication for sensitive apps, and use revocation-capable controls such as Continuous Access Evaluation where supported.

Key takeaways

• Disabling an IdP account does not necessarily terminate the access paths that matter most in SaaS environments.
• The article's evidence shows that refresh tokens can remain valid for days and that app-layer grants can outlive directory status changes.
• The control that matters is verified revocation across downstream systems, backed by continued behavioural monitoring after offboarding.

Key terms

• Phantom Access: Access that continues after an identity has been marked inactive in the directory or IdP. It often survives through OAuth grants, refresh tokens, delegated sessions, or cached SaaS state, creating a mismatch between governance records and actual ability to act.
• OAuth Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup detail.
• Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.