Notifications
Clear all
Topic starter
27/06/2026 1:36 pm
TL;DR: Disabling an IdP account does not reliably revoke OAuth grants, API tokens, or cached SaaS sessions, and in Microsoft 365 without Continuous Access Evaluation, refresh tokens can stay valid for days after disablement, according to Abnormal AI. The governance gap is not account shutdown but phantom access that survives offboarding and escapes normal detection.
NHIMG editorial — based on content published by Abnormal AI: Key Insights on post-offboarding phantom access and identity revocation gaps
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Inventory every downstream credential type Map OAuth grants, refresh tokens, API keys, delegated sessions, and vendor-issued access to the identity that created them.
- Treat deactivation as a monitored state Continue behavioural monitoring after offboarding so that a disabled identity still has an alerting baseline.
- Test revocation propagation end to end Run controlled offboarding tests across SCIM, SSO, SaaS tokens, and cached sessions to verify where disablement stops.
What's in the full article
Abnormal AI's full article covers the operational detail this post intentionally leaves for the source:
- How SCIM, SSO, and downstream SaaS token state diverge during offboarding
- Why Microsoft 365 without Continuous Access Evaluation leaves a longer revocation window
- Examples of behavioral baselines used to keep watching deactivated identities
- Operational signals that distinguish normal post-offboarding cleanup from phantom access
👉 Read Abnormal AI's analysis of post-offboarding phantom access in SaaS →
OAuth grants after offboarding: are your controls actually stopping access?
Explore further
27/06/2026 2:59 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Offboarding gaps leave OAuth grants alive after IdP disablement
