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 application, so the application stays in sync with a source of truth without anyone building a custom integration for it. It is plumbing, and useful plumbing: widely supported, and the clean path wherever it exists. It is also narrower than most people assume, in two directions, what it reaches and what it does.
identity provider (source of truth) application with a SCIM endpoint ---------------------------------------------- -------------------------------- new user in the directory -- POST /Users ----> account created attribute or group change -- PATCH /Users ----> account updated, groups synced user deactivated -- PATCH active=false -> account deactivated reaches: apps that built SCIM AND include it on the plan the company pays for does not reach: apps without SCIM, apps gating it to enterprise, entitlements below the group
How does SCIM work?
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.
The schema
RFC 7643 defines a User resource and a Group resource, each with a core set of attributes. A User has a userName, a name, emails, an active flag and an externalId that ties it back to the directory. A Group has a displayName and a list of members. An enterprise extension adds employeeNumber, department, manager and similar fields. Applications can extend the schema with their own attributes, and the identity provider maps directory fields onto whatever the application declares.
The operations
RFC 7644 defines the HTTP operations an identity provider performs against the application's endpoint.
| Operation | HTTP method | What it does |
|---|---|---|
| Create a user | POST /Users | A new hire appears in the application with the attributes the directory holds |
| Read users | GET /Users, with filters | The identity provider reconciles what the application has against what it expects |
| Replace a user | PUT /Users/id | The whole record is rewritten |
| Update attributes | PATCH /Users/id | One or more attributes change, including active: false to deactivate |
| Delete a user | DELETE /Users/id | The account is removed, where the application supports deletion |
| Manage groups | POST, PATCH, DELETE on /Groups | Directory groups become application groups and memberships follow |
| Discover capabilities | GET /ServiceProviderConfig, /Schemas, /ResourceTypes | The identity provider learns what the application supports |
The direction
The application exposes the endpoint, and the identity provider authenticates to it, usually with a bearer token generated in the application's admin console, and calls it. This inverts the older directory model, and a commenter on a thread about a lightweight LDAP server put the consequence well:
SCIM + Oath/SAML is pretty solid (SCIM doesn't handle authentication just provisioning, de-provisioning, and updates). It flips the script on LDAP as well, instead of the application calling in to the directory, the directory/sync service calls into the application which has some positive security implications.
Because the schema and the operations are standardized, the identity provider does not need bespoke code for each application. Turn on SCIM in the application, connect it in the identity provider, and provisioning flows. Create a user in the directory and they appear in the application. Disable them and the application account deactivates.
What does SCIM not do?
Two limits define the real shape of SCIM.
Coverage
Only applications that have built a SCIM endpoint can be provisioned this way, and 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 plan tier. For those applications SCIM is not an option at any configuration. The SCIM Tax Index tracks 286 SaaS vendors: at the June 2026 verification, 178 gate SCIM behind a higher plan, 68 have no SCIM at any price, and twelve include it on a base plan. The founder of a company that builds SSO integrations for a living described the state of support:
But unfortunately even SCIM isn't well enough supported yet to be considered a base standard. (It's worse than SAML.)
Depth
Even where SCIM works, it handles create, update, deactivate and group sync, which is account lifecycle rather than 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 compliance framework asks for. It keeps accounts in sync. Deciding whether the access is appropriate, and proving it, is a separate layer on top.
| SCIM does | SCIM does not |
|---|---|
| Create an account from a directory record | Decide whether the person should have the account |
| Set attributes and group memberships | Model roles, permission sets or entitlements below the group |
| Deactivate an account when the directory says so | Revoke API tokens or sessions the application issued, unless the application does so on deactivation |
| Keep the application's user list in sync | Tell anyone who approved a grant, or whether it is still appropriate |
| Report what it created | Produce review evidence or an audit trail beyond its own log |
What happens at deprovisioning?
Deprovisioning is the operation SCIM exists for, in most buyers' minds, and the one that separates it from SSO.
What the protocol sends
A PATCH setting active to false, or a DELETE where the application supports removal. That is the whole of it. With SSO alone, disabling the person stops new logins and leaves the account, any local password and every live session intact. With SCIM the application is told to deactivate, and the account stops being a way in.
The main benefit IMHO is deprovisioning. With straight up fed you can autocreate users etc but as the relying party you don't know when their access has been revoked. Sometimes this doesn't matter, but... often it does. People come and go all the time in enterprise.
What the application does with it is not specified
Whether deactivation ends live sessions, invalidates refresh tokens or revokes API keys the person issued is left to the application. RFC 7644 defines the flag, not the behaviour behind it, so two applications can both be compliant and behave differently. The only way to know which of yours is which is to test one: deactivate a test account mid-session and watch the tab that was already open.
Where the gap shows up in an audit
An auditor sampling a leaver asks when access ended, and the identity provider's log answers when the directory changed. If the application kept a session alive for another eight hours, the evidence and the reality disagree by eight hours. That is a formality on a routine resignation and the whole question on a contentious exit, which is why the emergency procedure for a hostile departure is never SCIM alone.
What is the SCIM tax?
Because SCIM is what a real identity program depends on, vendors know they can charge for it.
The pattern
The common shape is to lock SCIM behind the enterprise or top plan, so a company that needs automated provisioning upgrades its entire account to unlock one protocol. The extra cost has nothing to do with the features that tier otherwise carries. That is the SCIM tax, and it is a pricing strategy rather than a technical necessity, because the endpoint costs the same to run on every plan.
What it means for coverage
The consequence is that a stack's SCIM coverage is a budget decision rather than a technical one. A company with 60 applications does not have 60 candidates for SCIM. It has the few where SCIM is included, the few where the upgrade was worth buying, and the rest, which need another path or a person. Any provisioning plan that assumes provisioning means SCIM therefore covers the minority of the stack and reports itself finished.
The open SCIM Tax Index documents which vendors gate SCIM and behind which tier. The point worth holding onto is that provisioning does not require SCIM. Where an application has no SCIM or gates it, provisioning can run over the application's own API instead, or through a custom automation framework that drives the admin console, on any plan the company already holds.
Iden connects over SCIM where an application offers it on the plan a company already holds, over the application's own API where it does not, and through a custom connector where neither exists. The connector catalogue shows which path each application uses, so the coverage question this page keeps returning to has a visible answer per application. The feature behind it is Day one access, without a ticket.
200+ connectors. SCIM where the app has it, an API where it does not, and a custom connector where neither exists.