Skip to content

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

  1. 1Implement SCIM 2.0 provisioning per Organization
  2. 2Support create, update, and deactivate (deprovision) for users and groups
  3. 3Map IdP groups to your roles
  4. 4Handle just-in-time provisioning for users who log in before sync
  5. 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.