SaaS offboarding

what it is

SaaS offboarding is the process of closing or deactivating a departing employee's access in every application they used, not only in the central identity directory.

Standard offboarding closes the Microsoft 365 or Google Workspace account. Applications connected to that account via SSO are then unreachable. But applications that operate on independent credentials, that were added to the employee's toolkit without going through IT, or that do not support SSO, are not touched by closing the directory account.

The employee's credentials in those tools remain valid. Their sessions may remain active. If they saved their password locally, they can log in from any device.

Beyond Identity research found that 83% of employees admit they still have access to at least one account from a previous employer (Beyond Identity, 2022, self-reported). The directory account is the visible part of the offboarding. The application layer is where the gaps form.

why it accumulates

SaaS offboarding gaps accumulate for the same reason shadow SaaS accumulates: the application layer grows faster than any manual process can track it.

An employee who has been with the company for two or three years has typically connected to a range of tools, some sanctioned by IT, some adopted independently for their own work. IT's offboarding checklist covers the tools IT knows about. The others are not on any list.

Even for known tools, manual offboarding requires someone to log into each application's admin panel, find the account, and deactivate it. As the number of applications grows, this becomes a time-consuming task that often runs in parallel with urgent work. Steps get deferred or missed.

The problem compounds at every offboarding. Each departure leaves a potential residue of open accounts. Over time the environment holds accounts from former employees, contractors, and consultants in tools that nobody is actively managing.

what it costs you

Direct access risk. A former employee with access to a CRM, a project management tool, a document platform, or a communication system can continue to read, export, or modify data. The risk is higher when the departure was contentious or when the person moves to a competitor.

Retained access. Beyond Identity research found that 83% of employees admit they still have access to at least one account from a previous employer (Beyond Identity, 2022, self-reported). In any environment with significant SaaS usage, that means most departures leave at least one open account behind.

241-day detection gap. IBM's research puts the average time to identify and contain a breach at 241 days. Open accounts from former employees are rarely monitored. If access is used, it is likely to go undetected for months.

Audit failure. SOC 2 Trust Services Criteria, ISO 27001 control A.9.2.6 (user access removal), and DORA access management requirements all expect timely deprovisioning. Auditors check this. Finding multiple active accounts for former employees is a direct non-conformity.

Data residency and GDPR implications. If a former employee retains access to a tool that processes customer personal data, the organization's responsibility for that data does not end with their departure. Unmanaged former-employee access to data processors creates GDPR exposure.

what works

A defensible cleanup starts from the departures list: everyone who left in the past 12 to 18 months, with dates and, where available, roles and departments. Roles map to applications, applications map to user lists, and the comparison between who left and who still holds an account in each tool is the whole method. It is tedious in exactly the places that matter most, which is why the gaps formed in the first place.

Two layers need separate handling because they fail separately. In the IdP, deactivating a directory account does not revoke that account's OAuth grants; the grants survive deactivation and need explicit removal, which makes a search for active grants on deactivated accounts one of the highest-yield checks available. Outside SSO, nothing central exists to query at all, so each independently-authenticating tool requires its own admin console check against the departures list. That second layer is where manual offboarding most reliably breaks down, since it depends on IT knowing the tool exists and remembering it at every departure. Cleanup naturally begins with the applications that hold sensitive data or carry high OAuth scope, where an open account does the most damage.

The process that prevents recurrence has two properties. The first is named ownership: one person responsible for confirming, per departure, that application access is closed and not only the directory account, because a checklist nobody owns drifts back toward the directory-only offboarding it was meant to replace. The second is automation where it exists: SCIM provisioning deactivates application accounts from the directory event itself, removing the manual dependency entirely for the applications that support it and leaving human attention for the shrinking list that do not.