Offboarding gaps leave OAuth grants alive after IdP disablement

At a glance

What this is: This is an analysis of why offboarding stops at the IdP while downstream SaaS access can continue through OAuth grants, tokens, and cached sessions.

Why it matters: It matters because IAM, PAM, and NHI programmes need to treat revocation, detection, and lifecycle closure as one control plane, not separate handoffs.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Abnormal AI's analysis of post-offboarding phantom access in SaaS

Context

Offboarding often looks complete at the identity provider, but that does not mean access has actually ended. In practice, OAuth grants, API tokens, and cached SaaS sessions can persist after an account is disabled, which means identity shutdown and access revocation are not the same control.

For IAM and NHI programmes, the failure is structural: the disabling event is handled centrally, while the active credentials and delegated sessions often live in downstream applications that never receive a clean revocation signal. That leaves a post-offboarding access window that conventional deprovisioning logic can miss.

The article focuses on how deactivated identities can still act through lingering grants and tokens, including vendor-compromised OAuth paths and unmanaged sessions. That is a typical enterprise pattern, not an edge case, especially where SaaS, SCIM, and token lifetimes are treated as separate operational domains.

Key questions

Q: How should security teams handle access after offboarding an employee?

A: They should assume the IdP disablement is only the first step and verify that OAuth grants, API tokens, delegated access, and cached sessions are also revoked. The practical control is end-to-end lifecycle closure, because downstream SaaS platforms often continue to honor credentials even after the user can no longer sign in through SSO.

Q: Why do disabled accounts still create security risk in SaaS environments?

A: Disabled accounts still matter because the account state in the directory does not automatically invalidate every credential already issued to apps. If refresh tokens, OAuth grants, or cached sessions survive, the identity can still act in the target service, which creates phantom access outside normal offboarding controls.

Q: How do teams know whether offboarding controls are actually working?

A: Measure whether deactivation events propagate into every downstream system that can still accept the identity. The right signals are revoked grants, shortened token lifetime, blocked delegated access, and alerts on post-offboarding activity from identities that should be dormant.

Q: Who is accountable when an offboarded identity keeps accessing data?

A: Accountability usually spans IAM, application owners, and the teams that manage SaaS integrations, because the failure sits between directory disablement and downstream revocation. If one team assumes another closed the loop, phantom access persists. The control owner must be explicit for every credential type.

Technical breakdown

Why IdP disablement does not equal token revocation

Identity provider disablement usually stops interactive sign-in, but it does not automatically invalidate every credential already issued elsewhere. OAuth grants, refresh tokens, API keys, and cached sessions can remain accepted by the target SaaS until the application itself receives a revocation event or the token expires. That separation between authentication control and downstream authorization state is the core architectural gap. In federated environments, SCIM deprovisioning, SSO lockout, and application token state are often loosely coupled, so the removal of the human account does not remove every way to act as that identity.

Practical implication: map every offboarding step to the credential type it actually affects, not just the IdP account.

How lingering SaaS sessions create phantom access

A phantom access condition exists when the identity is marked inactive in one system but still functions in another. Personal devices, long-lived browser sessions, and vendor-side OAuth grants can all keep an identity operational after the user leaves. In Microsoft 365 without Continuous Access Evaluation, refresh tokens can remain valid for days, which means revocation latency becomes a security window. This is less a password problem than a session continuity problem: the stack stops watching once the account is disabled, while the SaaS may continue honoring previously issued session state.

Practical implication: keep session telemetry and token state under monitoring after deactivation, not only before it.

Why post-offboarding detection needs behavioral baselines

Traditional detection models are tuned to active users with stable baselines, so they often suppress or ignore identities that have already been disabled. That creates a blind spot where abnormal activity from a supposedly removed identity is treated as outside the detection path. Behavioral baselines can close that gap by continuing to watch historical patterns after offboarding and flagging use from new geographies, unusual delegates, or dormant API paths. The key shift is to treat removal as a monitoring state, not a monitoring stop condition.

Practical implication: preserve deactivated-identity baselines long enough to detect residual token abuse and delegated misuse.

Threat narrative

Attacker objective: The attacker’s objective is to preserve access after offboarding and use a valid-looking credential path to keep reaching SaaS data or actions without triggering normal deprovisioning controls.

1. Entry occurs when an attacker obtains a still-valid OAuth grant, API token, or cached session after the identity has been disabled in the IdP.
2. Escalation happens when the stolen or lingering credential is used against the downstream SaaS, which has no revocation signal from the original directory.
3. Impact follows when the attacker continues acting through phantom access, reaching data or workflows that the offboarded user should no longer control.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Offboarding is a revocation problem, not a disablement problem. The identity provider can turn off the login, but that does not end the authority already delegated to SaaS apps, API tokens, or cached sessions. This is the same governance failure that appears in many NHI incidents: control is assumed to end where authentication ends. Practitioners need to treat lifecycle closure as a distributed revocation state, not a directory event.

Phantom access is a governance blind spot because most detection stacks stop watching the moment an identity is deactivated. That creates a control assumption that removal and invisibility happen together, when in reality the residual credential may still be active. The article exposes a failure mode where deactivated identities fall out of monitoring before their access has actually expired. The implication is that offboarding must remain a monitored identity state until downstream grants and sessions are demonstrably gone.

Ephemeral identity closure debt: when offboarding is faster than revocation, the enterprise inherits hidden access debt. The article shows that token lifetimes, vendor integrations, and unmanaged sessions can outlast the person or account they were tied to. That debt accumulates across IAM, NHI, and SaaS governance because each team assumes another system handled the final cleanup. Practitioners should read this as a lifecycle integrity issue, not a narrow token-management bug.

Deactivated users are still a live identity class if behavioral evidence says otherwise. The article’s strongest lesson is that identity state should be measured by observable access behaviour, not by a checkbox in the IdP. That is why NHI and human identity governance are converging around the same question: can the organisation prove that no executable authority remains after offboarding? The answer has to be operational, not declarative.

OWASP-NHI and Zero Trust thinking both point to the same broken assumption. Access is often provisioned as if it can be centrally ended once and for all, but distributed credentials keep their own clocks. That assumption fails whenever SaaS and delegation layers are allowed to outlive the source identity event. Practitioners should treat offboarding as an end-to-end revocation workflow, not a directory toggle.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• For the operational playbook behind that gap, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding practices.

What this signals

Ephemeral credential trust debt: offboarding creates a governance liability when the business treats account disablement as the end of access rather than the start of revocation verification. The practical consequence is that token state, session state, and delegated access must be tracked as first-class lifecycle objects, not hidden implementation details.

The programme signal is clear: teams that cannot prove downstream revocation will keep missing post-offboarding misuse, especially where SaaS integrations and third-party OAuth apps are involved. That risk is amplified by the visibility gap in third-party access, which is why offboarding needs to be measured as a cross-domain control, not an IAM ticket closure.

For control design, align offboarding with the NIST Cybersecurity Framework 2.0 and Zero Trust principles so that identity removal is validated continuously rather than assumed once. The fastest improvement usually comes from connecting deprovisioning events to direct revocation checks and sustained anomaly detection across dormant identities.

For practitioners

• Inventory every downstream credential type Map OAuth grants, refresh tokens, API keys, delegated sessions, and vendor-issued access to the identity that created them. Use the map to see which applications can keep working after IdP disablement and which ones need separate revocation workflows.
• Treat deactivation as a monitored state Continue behavioural monitoring after offboarding so that a disabled identity still has an alerting baseline. Flag access from new regions, unusual delegate paths, or endpoints the identity never used during normal employment.
• Test revocation propagation end to end Run controlled offboarding tests across SCIM, SSO, SaaS tokens, and cached sessions to verify where disablement stops. Document which applications require direct revocation calls and which ones only stop interactive logins.
• Separate session expiry from account expiry Set policy so token and session lifetimes are reviewed independently from user account termination. In environments with long-lived refresh tokens, shorten the exposure window where the business can tolerate it and verify the control actually changes downstream acceptance.

Key takeaways

• Disabling an IdP account does not end access if downstream grants, tokens, and cached sessions remain active.
• The scale of the problem is amplified by low visibility into OAuth-connected third parties and by long-lived credentials that survive normal offboarding.
• Practitioners need lifecycle closure, revocation verification, and post-deactivation monitoring if they want offboarding to actually remove access.

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.
• Downstream Revocation: The process of removing or invalidating credentials in the systems that actually honor them, not just in the source identity platform. In distributed SaaS environments, this includes token invalidation, session termination, and grant removal across connected applications.
• Lifecycle Closure: The point at which an identity is no longer able to authenticate, authorize, or delegate action anywhere in the environment. For offboarding, lifecycle closure requires the directory event, the application revocation, and the verification step to all complete successfully.
• Behavioral Baseline: A record of how an identity normally behaves so deviations can be detected later. For deactivated identities, the baseline must persist long enough to reveal post-offboarding activity that would otherwise disappear from standard active-user monitoring.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme design, it is worth exploring.

This post draws on content published by Abnormal AI: Key Insights on post-offboarding phantom access and identity revocation gaps. Read the original.