Enterprise-ready playbook
Ship SCIM and directory sync
Updated 2026-07-19
Why enterprises demand it
- Automated deprovisioning on offboarding is a security and audit requirement
- Manual user management across many customers does not scale
- SCIM is the second SSO-adjacent gate on enterprise deals
How to implement
- 1Implement SCIM 2.0 provisioning per Organization
- 2Support create, update, and deactivate (deprovision) for users and groups
- 3Map IdP groups to your roles
- 4Handle just-in-time provisioning for users who log in before sync
- 5Test against the major IdPs; each interprets SCIM slightly differently
Standards
- SCIM 2.0
- SAML / OIDC (paired with SSO)
Pitfalls
Provisioning without deprovisioning
The whole point for security teams is automated offboarding; deactivate must work.
Assuming SCIM is uniform
Okta, Entra, and others diverge; test against each.
No group-to-role mapping
Enterprises manage access by IdP group; map it to your roles.
Build checklist
- SCIM 2.0 provisioning per organization
- Create, update, and deactivate all supported
- Group-to-role mapping
- JIT provisioning fallback
- Tested against major IdPs
What to require of a platform
- SCIM 2.0 inbound provisioning
- Deprovisioning / deactivation
- Group-to-role mapping
Go deeper
Build it: blueprints
FAQ
- Is SCIM required if I already have SSO?
- Often yes. SSO authenticates users who show up; SCIM provisions and, crucially, deprovisions them automatically. Enterprise security teams treat automated offboarding as a control, so SCIM usually follows SSO as the next hard requirement.
- Why is deprovisioning the most important part of SCIM?
- Leaving access active after someone departs is a security and audit failure. The main reason enterprises want SCIM is automated deactivation on offboarding, so your implementation must handle deactivate, not just create and update.