SaaS offboarding: closing the apps the directory never reached
When someone leaves, IT disables their account in the identity provider. For apps connected through single sign-on, that is often enough: no directory login, no access. The problem is everything that is not connected that way.
A large share of the typical SaaS estate sits outside single sign-on. In a typical corporate stack, roughly a third of applications are disconnected, CSV-only tools that standard identity tooling never sees (Stitchflow, 2026). Those apps have their own logins, their own passwords, and their own sessions, none of which the directory controls. Disabling the directory account does nothing to them, and the former employee can still log in, because the app never knew they left.
- Disabling the directory account is the easy part of offboarding. The risk is everything that account never controlled, which is where a departing person's most useful access usually lives.
- In a typical corporate stack, roughly a third of applications are disconnected, CSV-only tools that standard identity tooling never sees (Stitchflow, 2026). Those apps have their own logins, passwords, and sessions, none of which the directory controls.
- About 40% of organisations report a security incident caused by incomplete offboarding (Reco, 2025-2026), and most former employees keep access to at least one company app after leaving.
- An active OAuth grant or API token can keep working after the login is closed, so grants and tokens have to be revoked explicitly.
- Bringing apps into SSO and SCIM is the highest-leverage fix, but 57% of enterprise SaaS apps have no built-in SCIM and 42% paywall it behind enterprise tiers (Stitchflow, 2026), so part of any stack stays manual and needs a checklist.
- You can only offboard from apps you know exist, which links a live SaaS inventory directly to clean offboarding.
why saas is where offboarding breaks
This is why most former employees keep access to at least one company app after leaving, and why about 40% of organisations report a security incident caused by incomplete offboarding (Reco, 2025-2026). The directory closes reliably. The SaaS that the directory never reached stays open, and it is exactly where a departing person's most useful access often lives: the CRM, the design tool, the code host, the analytics platform they used every day.
the full saas offboarding scope
Closing SaaS access on a leaver means working through several distinct layers, because each closes differently. SSO-connected apps are handled when you disable the directory account, provided single sign-on is genuinely enforced and there is no local-password backdoor, which is worth verifying rather than assuming. Apps with direct logins, where people sign in with an email and password outside single sign-on, each need their access removed in that app, not in the directory; these are the ones offboarding most often misses. Apps the person signed up for themselves, shadow SaaS adopted on a work email and never in the asset register, can only be closed if they were discovered first. OAuth grants and tokens the leaver connected to your workspace or generated may keep working after the account is gone, so they get revoked explicitly. Shared accounts the person had the password to should be rotated, because disabling their personal account does nothing to a credential several people use. And data and ownership, the files, automations, and integrations the person owned, need to transfer before the account is fully removed, or they break or become inaccessible.
the sequence
Order matters, because some steps depend on others and some are time-sensitive. Before the account is removed, capture what the person owns: their OAuth grants, the apps they administer, the automations and files tied to them, because once the account is gone this gets much harder. Then revoke OAuth grants and API tokens explicitly, so nothing keeps authenticating after the login is closed. Disable the directory account to close the SSO-connected apps. Work the apps outside single sign-on, removing the person's access in each one, using the discovered SaaS inventory as the checklist. Rotate shared credentials the person knew. Transfer ownership of data, automations, and admin roles to someone current. Finally, record what you closed, so the offboarding can be proven; this is the evidence auditors sample under SOC 2 CC6.2 and ISO 27001 A.5.18.
why it stays hard, and how to make it easier
SaaS offboarding is hard for a structural reason: the apps outside single sign-on have no central control point, so each one is manual. Two moves shrink the problem over time. Bringing apps into single sign-on, and provisioning through SCIM, converts a manual step into an automatic one for every future leaver, which is the highest-leverage fix. The limit is real, though: 57% of enterprise SaaS apps have no built-in SCIM and 42% paywall it behind enterprise tiers (Stitchflow, 2026), so part of any stack stays manual and needs a checklist. Keeping a live SaaS inventory, fed by ongoing discovery, is what turns SaaS offboarding from hoping you remembered them all into a checklist you can actually complete. The two reinforce each other: discovery finds the apps, and single sign-on brings the important ones under automatic control, leaving a smaller manual tail each time.
let's start with a conversation
Most first conversations start with not quite knowing what you have or where to begin. That's normal, and it's exactly where we're useful.
Tell us what prompted this. An upcoming audit, an incident, a client's security questionnaire, or just a sense that things have gotten messy.
We'll take it from there
+48 783 762 997
julian@unshadowit.com
