How do I handle SSO deprovisioning when a user leaves a company?

When a user leaves a company, SSO deprovisioning is about removing their access everywhere in a controlled, auditable way—not just disabling the login. The exact approach depends on your IdP and apps, but a good pattern is:

1) Disable the user at the source of truth

Usually this is your IdP / directory (e.g., Okta, Azure AD / Entra ID, Google Workspace).

• Suspend/disable the account immediately
• Revoke active sessions and refresh tokens
• Remove from groups that grant access

2) Automate downstream deprovisioning

Use standards and integrations so apps react automatically:

• SCIM: preferred for automated provisioning/deprovisioning
• SAML/OIDC + app-specific admin APIs: if SCIM isn’t available
• HRIS-driven workflows: best when HR is the source of truth

3) Revoke access artifacts

Make sure you invalidate:

• SSO sessions
• OAuth access/refresh tokens
• API keys / service credentials tied to the user
• Device trust / mobile management access if applicable

4) Handle app-specific ownership

Some accounts may own important data:

• Transfer ownership of files, projects, dashboards, repos, etc.
• Convert to shared/team ownership where possible
• Preserve records needed for compliance or legal hold

5) Keep audit and compliance records

Log:

• Who initiated deprovisioning
• When access was removed
• Which apps were affected
• Whether data ownership was transferred

6) Have a fallback for apps without automation

For apps that don’t support SCIM or APIs:

• Use a manual deprovisioning checklist
• Track those apps in an access inventory
• Periodically review for stale accounts

7) Separate access removal from data retention

Deprovisioning should stop access, but you may still need:

• Email retention / forwarding policies
• Legal hold
• Data export for the company
• Record retention requirements

Practical offboarding flow

1. HR marks employee as terminated
2. IdP account is disabled and sessions are revoked
3. SCIM/API removes user from connected apps
4. App owners are notified to transfer ownership
5. Audit log is stored
6. Manual follow-up for any non-integrated systems

Good guardrails

• Use least privilege and group-based access
• Prefer SCIM over manual app-by-app cleanup
• Ensure instant revocation for privileged users
• Test offboarding regularly with a checklist/tabletop exercise

If you want, I can also give you:

• a sample offboarding checklist
• a SCIM-based deprovisioning architecture
• or a vendor-by-vendor approach for Okta / Entra / Google Workspace.