SCIM, the System for Cross-domain Identity Management, is the standard protocol for automated user provisioning. It gives an identity provider a defined way to create, update, and deactivate accounts inside an app, so the app stays in sync with a source of truth without anyone building a custom integration for it.
It is plumbing. Useful, widely supported, and genuinely the clean path where it exists. It is also narrower than most people assume, in two directions: what it reaches, and what it does.
How SCIM works
SCIM 2.0, defined in RFC 7643 and RFC 7644, specifies two things: a schema for representing users and groups, and a REST API for acting on them. An app that implements SCIM exposes an endpoint. The identity provider authenticates to it with a token and issues standard operations: create this user, update these attributes, add them to this group, deactivate them.
Because the schema and operations are standardized, the identity provider does not need bespoke code per app. Turn on SCIM in the app, connect it in the identity provider, and provisioning flows. Create a user in the directory and they appear in the app. Disable them and the app account deactivates.
What SCIM does not do
Two limits define the real shape of SCIM.
Coverage. Only apps that have built a SCIM endpoint can be provisioned this way. Across a typical mid-market stack, that is a minority. Standard-plan SaaS, internal admin tools, and legacy systems either lack SCIM or gate it behind a tier. For those, SCIM is not an option at any configuration.
Depth. Even where SCIM works, it handles create, update, deactivate, and group sync. That is account lifecycle, not governance. SCIM does not run access reviews, does not model fine-grained entitlements below the group level, and does not produce the audit trail a framework asks for. It keeps accounts in sync. Deciding whether the access is appropriate, and proving it, is a separate layer on top.
The SCIM tax
Because SCIM is what a real identity program depends on, vendors know they can charge for it. The common pattern is to lock SCIM behind the enterprise or top plan, so a company that needs automated provisioning has to upgrade the entire plan to unlock one protocol. The extra cost has nothing to do with features the company uses. It is the price of the plumbing.
This is the SCIM tax, and it is a pricing strategy, not a technical necessity. The open SCIM Tax Index documents which vendors gate SCIM and behind which tier. The point worth holding onto: provisioning does not actually require SCIM. Where an app has no SCIM or gates it, provisioning can run over the app's own API or a custom automation framework instead, on any plan.
Related terms
- SCIM provisioning. The provisioning done over the SCIM protocol.
- SCIM vs SAML. How SCIM (provisioning) differs from SAML (authentication).
- SCIM tax. The pricing pattern of gating SCIM behind expensive tiers.
- Identity Governance and Administration (IGA). The governance layer SCIM does not provide.