· Yair Knijn
The leaver who still has access to three SaaS apps, 90 days after their last day
The CISO signs off on the offboarding because the ticket says the leaver's Entra account was disabled at 17:00 on their last day. That is the assumption that gets people in trouble: that one toggle in the identity provider pulls the floor out from under every system the person ever touched. It does not. A disabled IdP account stops new interactive sign-ins through that provider. It does almost nothing to the access that was minted out of band.
DoControl found that 31% of former employees still have access to at least one company SaaS app after they leave. The number you will care about is the one you discover three months later, when one of those accounts logs in and your SIEM has no idea who that is anymore.
What a disabled Entra account does not revoke: local logins, OAuth grants, API keys
An app that supports SSO almost always also keeps a local password path, because someone needed a break-glass login the week the IdP was flaky. Disable the federated identity and the local credential is still valid. The leaver set one during onboarding, or reset it, and it survives. SSO was the front door. The local login is the side door nobody locked.
OAuth grants are worse, because they outlive the session and often the account. When the user clicked "allow" on a third-party tool reading their mailbox, that issued a refresh_token that keeps minting access independent of whether their primary account is enabled. Revoking the session does not revoke the grant. The same goes for personal access tokens and API keys the person generated inside individual apps. Those are credentials the IdP never issued, so disabling the IdP account cannot touch them. You have to go into each app and kill them by hand, which means you have to know they exist.
The apps your JML process never knew existed
Your joiner-mover-leaver workflow can only revoke what it provisioned. It provisioned the dozen apps in the SSO catalog. It never saw the analytics tool a team lead expensed on a corporate card, the niche vendor portal procurement set up directly, or the GitHub org someone joined with a work email and a personal password. Grip Security, analyzing 29 million accounts in its 2025 report, found that around 90% of applications sat outside IT's management entirely. SCIM deprovisioning, where it is even wired up, only fires for apps inside that catalog.
So the honest enumeration is not "what did we provision." It is "what did this human ever authenticate to with a company identity." Those are different lists, and the gap between them is exactly the set of apps where your leaver still has a working login.
Building a single revoke action across the whole estate
The fix is not a tighter SSO catalog. It is one operation that, given a person, walks every app in the estate and revokes everything in each: federated link, local account, active OAuth grants, every token and key. That requires a per-person inventory that is built continuously from what each app actually reports about its own users, not from what your IdP believes it pushed out.
- Federated identity disabled in the IdP, the necessary first step and nothing more.
- Local accounts in each app deactivated, including break-glass logins.
- OAuth grants revoked at the resource, so refresh tokens stop minting access.
- Tokens and keys the user created inside apps rotated or deleted.
If any of those four lives in a console an admin has to remember to open, it will be the one that gets skipped, and it will be the one the auditor finds.
Proving to the auditor that access actually ended, with timestamps
"We disabled the account" is a claim. The auditor wants evidence, and the evidence is a timestamp per app showing the specific access ended, who ended it, and confirmation nothing has authenticated since. That is the difference between an offboarding you assert and one you can produce on demand. If your answer is ten separate exports stitched together the night before the review, you do not actually have the answer, and neither does the auditor.
Spot Suite treats every person's footprint across the estate as state that hangs off one record, so a leaver's access in each Customer Environment is enumerated, revoked in a single action, and stamped with the time it ended. Offboarding stops being a thing you hope happened and becomes a thing you can show.