An employee leaves. IT runs offboarding the same or next business day. The IdP disables the account, SCIM propagates the change downstream, and SSO logins immediately stop working. That part (usually) works.

The pieces that don't always go down with SSO: OAuth grants for SaaS, API tokens issued out-of-band, sessions cached on personal devices the org doesn't manage, and any delegated access the offboarded user handed to a still-active colleague.

In Microsoft 365 without Continuous Access Evaluation enabled, refresh tokens can survive for days. Some SaaS apps have their own session and grant lifetimes, sometimes measured in weeks.

Attackers know this. When a vendor environment is compromised, the OAuth grants stored there are still valid because the SaaS at the other end — Salesforce, Snowflake, Slack, whichever the vendor was integrated with — has no signal that the tokens were stolen. The same gap exists inside the org: the IdP disables the account, but the apps where the user's session or token actually lives never receive the revocation event.

In practice, this is a detection problem more than a hygiene problem.

Most detection logic spots anomalous activity against an active user's baseline. Once an account is disabled, the same logic mostly stops looking. The risk of phantom access lives in that gap: activity from an identity the stack has already marked as gone.

Catching it means continuing to watch a deactivated identity and flagging anything that doesn't match what it used to do. A token from a previously-inactive geography. A delegate path that hadn't been used in weeks. An API key whose human owner left months ago, now hitting endpoints from a new region.

That kind of detection is what behavioral baselines do: watch what was normal, keep watching after the offboarding, flag anything that moves.

See the latest from Abnormal's product and engineering teams.