SCIM — System for Cross-domain Identity Management — is the standard that lets your identity provider create, update and deactivate accounts in other applications automatically. When someone joins and their Okta or Entra account appears in Slack, Zoom and Figma without anyone filing a ticket, that is SCIM.

It is genuinely good, and it does less than most people assume.

What it actually syncs

SCIM defines two things: a schema for users and groups, and a REST API for pushing changes to them. Your identity provider is the source of truth; the application is the target. When a user is created, updated or deactivated at the source, the provider calls the target's SCIM endpoint and the change propagates.

In practice that means:

• Account lifecycle. Create on join, deactivate on leave.
• Attribute sync. Name, email, job title, department, manager — whatever the application's schema accepts.
• Group membership. Which is usually how application-level permissions get assigned, indirectly.

That covers the majority of joiner and leaver work, which is why SCIM is worth turning on wherever it is offered.

The four gaps it leaves

It only reaches applications that support it. SCIM support is common in enterprise tiers and rare below them. The tool your design team pays for monthly, on a card, almost certainly has no SCIM endpoint — and that is exactly the tool nobody remembers at offboarding.

Deactivation is not always cancellation. SCIM deactivates the user in the application. Whether that removes them from the bill is entirely the vendor's choice, and many keep charging until a human edits the plan. Provisioning automation with no license reclamation produces a tidy directory and a growing invoice.

In-app permissions are usually out of scope. SCIM syncs group membership; what a group means inside the application is configured in the application. Someone can be in the right group and still hold an admin role nobody granted deliberately.

It says nothing about what already exists. SCIM manages accounts it created. Accounts made before you enabled it, service accounts, shared logins and externally invited guests sit outside the sync entirely, and nothing about turning SCIM on surfaces them.

SCIM, SSO and JIT are not the same thing

These get used interchangeably and they solve different problems:

• SSO authenticates: it proves who someone is at login. It does not create or remove accounts.
• JIT provisioning creates an account the first time someone logs in via SSO. It is easier to configure than SCIM and has a serious asymmetry — it creates accounts but has no mechanism to remove them.
• SCIM provisions and deprovisions in both directions, on the provider's schedule rather than the user's login.

A stack with SSO and JIT but no SCIM accumulates accounts that were created automatically and can only be removed by hand. That is the worst of the three combinations, and it is extremely common.

What to do with this

Turn SCIM on wherever it exists — it is the cheapest deprovisioning you will ever get. Then write down the applications where it doesn't, because that list is your real offboarding risk, and it is not visible from inside the identity provider.

← All resources