SaaS deprovisioning: removing leaver access from every SaaS app

Disabling a leaver in the identity provider does not remove them from most SaaS applications: local accounts, open sessions, personal API tokens and OAuth grants survive unless each app is deprovisioned on purpose. The average organisation runs far more SaaS applications than it connects to SCIM, and the gaps are where former staff, contractors and attackers holding their tokens keep access. This guide is the operational how-to for removing leaver access across SaaS: what SCIM deprovisioning actually does, how to make SSO the only way in, how to kill sessions and tokens that outlive the account, how to sweep for orphan accounts, and how to measure the result. It is written for identity governance teams, SaaS administrators and security engineers. The wider leaver process, from the HR trigger to devices and data, is covered in the Employee Offboarding Security Guide; this page goes deeper on SaaS.

Key takeaways

• Deprovisioning has four layers. The account, its sessions, its credentials (API tokens, keys, app passwords) and the OAuth grants it made. Disabling the account in the IdP touches only the first, and only in connected apps.
• SCIM deactivation is not deletion, and its meaning varies. RFC 7643 says the definitive meaning of the active attribute is determined by the service provider. Test what "inactive" really blocks in each app.
• SSO-only enforcement turns the IdP into the off switch. Where an app still allows a local password, a leaver with that password is still in, whatever the IdP says.
• Tokens outlive sessions. GitHub's documentation warns that authorised tokens keep granting access to an organisation after SSO sessions expire. Revoke them explicitly.
• Sweeps catch what automation misses. A regular reconciliation of every SaaS account against the HR record, with an owner for each app, is the control auditors and attackers both test.

The four layers of SaaS access

A leaver is only fully deprovisioned when all four layers are gone in every app they used. Most failures are in layers three and four, because they are created by the user, not by IT.

SCIM deprovisioning: what it does and does not do

SCIM (RFC 7643 schema and RFC 7644 protocol, both IETF Standards Track, September 2015) gives an identity provider a standard way to create, update, disable and delete users in an app. Two details matter for leavers.

• Disable versus delete: a disable sets the user's active attribute to false; RFC 7643 describes it as administrative status, typically meaning the account is suspended, but leaves the definitive meaning to the service provider. A delete under RFC 7644 removes the resource, after which the provider must return 404 for it. Some apps keep data and licences for disabled users; some still accept existing API tokens.
• What triggers it: Microsoft's description of Entra provisioning lists four deprovisioning triggers: the user is soft-deleted or has AccountEnabled set to false, is permanently deleted, is unassigned from the app, or falls out of the app's scoping filter. If the app does not support soft delete, a DELETE is sent. Thirty days after a user is deleted in Entra ID they are permanently deleted from the tenant and a DELETE is sent to the app.
• Timing: provisioning runs in incremental cycles at an interval specific to each application, so deprovisioning is not instant. Microsoft notes that a job whose calls keep failing goes into quarantine, slowing to once per day, and is disabled after four weeks in quarantine. A quarantined job silently stops deprovisioning.
• Configuration traps: a "skip out-of-scope deletions" setting, or an attribute mapping without isSoftDeleted, can mean that unassigned users are left untouched in the app. Review these settings for every connected app.
• Okta behaves similarly: Okta's documentation says deactivating a user ends all Okta sessions, removes app assignments and admin roles, and deprovisions the user from assigned apps where deprovisioning is enabled for that app, as a background task. Group memberships are kept.

The practical rule: SCIM removes the account in apps that support it and are configured for it. It does not revoke tokens the user created, and it does nothing for apps without a connector. See the SCIM Provisioning Guide.

Making SSO the only way in

SSO without enforcement is a convenience, not a control. If users can still sign in with a local password, an app password or a magic link sent to their mailbox, disabling them in the IdP leaves those paths open.

1. Turn on SSO enforcement in each app: most business SaaS plans have a setting that requires SAML or OIDC sign-in for all members. Where it is only available on a higher tier, record that as a risk decision rather than assuming it is on.
2. Remove local passwords: after enforcement, reset or remove existing local credentials so they cannot be used if enforcement is later relaxed.
3. Keep one controlled exception: a break-glass local administrator per critical app, held in a vault, monitored and tested, so an IdP outage does not lock you out. See the Break-Glass Account Guide.
4. Check what enforcement removes: GitHub's documentation says enforcing SAML SSO removes organisation members and administrators who have not authenticated through the IdP, including bots and service accounts without an IdP identity. Inventory machine users before you switch it on.
5. Pair enforcement with deprovisioning: GitHub also says that without SCIM, members are not automatically removed from the organisation when their IdP access ends; they stay until an owner removes them. SSO blocks new sign-ins; it does not remove the membership or the tokens.

Killing sessions and tokens

• IdP sessions: in Microsoft Entra ID, revokeSignInSessions invalidates the refresh tokens issued to applications and the browser session cookies by resetting signInSessionsValidFromDateTime, with a possible delay of a few minutes. It does not cover external users, who sign in through their home tenant. Okta deactivation ends Okta sessions.
• App sessions: apps that issued their own session after SSO may keep it until it expires. Use each app's admin sign-out or session revocation for high-risk leavers, and set reasonable session lifetimes in apps that allow it.
• Shared signals: the OpenID Continuous Access Evaluation Profile (CAEP 1.0, final, August 2025) defines events such as session-revoked and credential-change that an IdP can send to apps that support them, so revocation reaches the app without waiting for expiry. Support is still uneven; check each vendor. See the Shared Signals Framework Guide.
• Personal tokens and keys: GitHub warns that authorised tokens keep granting access to the organisation after sessions expire. The same applies to API keys in CRM, ticketing and analytics platforms, app passwords in mail and calendar systems, and SSH keys. List them before the leave date and revoke them on it.
• OAuth grants: revoke consents the leaver gave to third-party apps, and reassign any integration installed under their account to a service identity before removing them, or the integration breaks. See the SaaS and OAuth App Governance Guide.

Two incidents show why the credential layer matters. In the Ledger Connect Kit npm Compromise, a phished former employee's npm access that had not been properly revoked was used to publish malicious package versions. In the Mastra npm Supply Chain Attack, a former contributor's account kept publish rights across the package scope long after they stopped contributing. Registries and developer platforms are SaaS too.

Orphan account sweeps

An orphan account is a SaaS account with no matching active person or owner. Sweeps find the accounts that SCIM, enforcement and manual tasks missed.

1. Build the app list: combine the IdP's application list, finance and expense records, SaaS discovery or posture tooling, browser extension and OAuth grant inventories, and the list of apps with local logins.
2. Export accounts per app: by API where possible, otherwise by admin export, including role, last sign-in date, account type (member, guest, service) and whether the account signs in with SSO.
3. Match to the authoritative source: join on immutable employee ID where the app stores it, otherwise on email address, and flag every account whose person is terminated, unknown or a personal address.
4. Classify: leaver, unknown, shared or generic mailbox, service or integration account, external guest, and active-but-dormant.
5. Act with owners: remove leaver accounts immediately; give unknown and shared accounts an owner or remove them; move integrations to named service identities; disable dormant accounts after an agreed period.
6. Record and repeat: keep the evidence for audit and run the sweep monthly for critical apps and quarterly for the rest.

Implementation: a phased approach

1. Phase 1, inventory and tiering (weeks 1 to 4): build the app list, record for each app whether it supports SSO, SSO enforcement and SCIM deprovisioning, and tier apps by data sensitivity and privilege.
2. Phase 2, connect and enforce the top tier (months 1 to 3): SCIM and SSO enforcement for tier 1 apps. Test in a pilot: deprovision a test user and confirm sign-in, API tokens and mobile sessions all fail. Keep the previous manual runbook until the test passes.
3. Phase 3, runbooks for the rest: for apps without SCIM, a documented removal task with an owner and a deadline, triggered from the same leaver event, and tracked to closure.
4. Phase 4, tokens and grants: add token, key and OAuth grant revocation to the leaver workflow for the platforms where users create them (code hosting, package registries, CRM, analytics, AI tools).
5. Phase 5, sweeps and metrics: run the first orphan sweep, fix what it finds, then schedule it.

Rollback: prefer disable over delete at first, so an accidental deprovisioning can be reversed. Microsoft recommends that applications support both soft and hard deletes for this reason. Set a defined period after which disabled accounts are deleted and licences reclaimed.

Decision guidance

Small organisations: a spreadsheet of apps with owners, SSO enforcement on the handful of critical ones, and a leaver checklist that names every app and token type is enough to close most gaps. Large organisations: drive deprovisioning from the identity governance platform, with SaaS discovery feeding the app inventory, ticketed tasks for disconnected apps and sweep results reported to app owners and audit.

Where identity fits: non-human access left behind

Leavers often own non-human identities: integrations they installed, bots and service accounts they created, API keys embedded in automations, and AI agents connected with their own credentials. Removing the person without reassigning these either breaks the business process or, worse, leaves a credential with no owner that nobody will rotate. Before the leave date, transfer ownership of each NHI to a named person, rotate any secret the leaver could have seen, and record the new owner. See the NHI Offboarding and Decommissioning Guide.

Detection and measurement

• Sign-ins after termination: any successful sign-in or API call by an identity after its termination date, in IdP logs and SaaS audit logs, is a priority alert.
• Provisioning health: alerts on provisioning jobs in quarantine or with rising error counts, because a broken connector stops deprovisioning silently.
• Local sign-ins: sign-ins that bypass SSO in apps where it should be enforced.
• Token use: API activity from tokens whose creator is no longer active.

KPIs:

• Time to full deprovisioning: median and 95th percentile hours from termination to removal in every app, against an SLA such as 24 hours (immediate for high-risk leavers).
• Automation coverage: percentage of tier 1 apps with SSO enforcement and SCIM deprovisioning tested in the last 12 months.
• Orphan rate: orphan accounts found per sweep per 1,000 SaaS accounts, trending to zero.
• Token residue: active tokens, keys and OAuth grants belonging to terminated users (target zero).
• Licence reclaim: licences recovered per sweep, which also builds the business case.

Framework mapping

Common failure patterns

• IdP disable treated as done: the user cannot sign in through SSO, but their local password, mobile session and API token still work.
• Silent connector failure: a provisioning job goes into quarantine after an admin credential expires and nobody notices for weeks.
• Disabled but still licensed and readable: SCIM sets active to false, but the app's meaning of inactive still allows API access or keeps shared content public.
• Developer platforms forgotten: code hosting and package registry rights sit outside the IdP, as the Ledger and Mastra incidents show.
• Integrations break on removal: the leaver's account ran a business-critical integration, so the team re-enables it "temporarily" and it stays.
• Contractors outside HR: no termination event ever reaches the IdP, so their SaaS access has no end date.

Practitioner checklist

• Maintain an inventory of every SaaS app with owner, tier, SSO enforcement status and SCIM deprovisioning status.
• Enforce SSO and remove local passwords in every app that supports it, with one vaulted break-glass admin where needed.
• Connect SCIM deprovisioning for tier 1 apps and test that a disabled user's sign-in, sessions and API tokens all fail.
• Alert on provisioning jobs in quarantine or with persistent errors.
• Revoke IdP sessions and refresh tokens on the leave date, and use app-level session revocation for high-risk leavers.
• Revoke personal tokens, keys, app passwords and OAuth grants, and reassign integrations to service identities first.
• Run orphan account sweeps against the HR record monthly for critical apps and quarterly for the rest.
• Set expiry dates and sponsors for contractor and guest access.
• Report time to full deprovisioning and token residue to app owners and audit.

Standards and references

• IETF: RFC 7644 System for Cross-domain Identity Management: Protocol
• IETF: RFC 7643 System for Cross-domain Identity Management: Core Schema
• OpenID Foundation: Continuous Access Evaluation Profile 1.0
• Microsoft Learn: How application provisioning works in Microsoft Entra ID
• Microsoft Learn: user revokeSignInSessions
• Okta: Deactivate and delete user accounts
• GitHub Docs: Enforcing SAML single sign-on for your organization
• GitHub Docs: About SCIM for organizations

Related NHI Mgmt Group resources: Employee Offboarding Security Guide · SCIM Provisioning Guide · Joiner-Mover-Leaver Guide · SaaS Security Guide