System for Cross-domain Identity Management (SCIM) is an open standard for automating user provisioning. It defines a common REST API and data format that an identity provider uses to create, update, disable and delete user accounts and group memberships in applications. When someone joins, changes department or leaves, SCIM lets those changes flow from the central identity system to connected applications without anyone editing each app by hand. SCIM 2.0, published by the IETF, is the version in common use.
At a glance
- A standard API and schema for managing users and groups across systems.
- The identity provider (the SCIM client) pushes changes; the application (the SCIM service provider) applies them.
- Handles account creation, attribute updates, group membership and deprovisioning.
- Complements sign-in standards such as SAML and OpenID Connect, which do not manage accounts on their own.
- Widely supported by business SaaS, though often only on higher plans and to varying depth.
What problem it solves
Single sign-on (SSO) stops users needing a password for every app, but each app still keeps its own list of accounts. Without automation, IT creates those accounts by hand, forgets to update them when people move and often fails to remove them when people leave. Disabling the user in the identity provider blocks new SSO sign-ins, but the app account can remain, holding a paid license and sometimes still reachable through API tokens, local passwords or sessions that were already open.
SCIM closes that gap. It turns the joiner-mover-leaver (JML) events recorded in the identity system into account changes in each connected app, so access and licenses track employment more closely and auditors can see consistent deprovisioning.
How it works
Connection. An administrator configures the application in the identity provider (IdP) with the app’s SCIM endpoint URL and a credential, usually a token issued by the app.
Assignment. Users and groups are assigned to the application in the identity provider, often based on department or role.
Create. When a user is assigned, the identity provider sends a SCIM request to create the account, with attributes such as name, email, department and manager mapped to the app’s fields.
Update. When attributes or group memberships change, the identity provider sends updates. Groups pushed through SCIM can drive roles inside the app.
Deprovision. When a user is unassigned or disabled, the identity provider tells the app to deactivate or delete the account, depending on configuration and what the app supports.
Timing and errors. Some identity providers push changes as they happen; others sync on a schedule. Failed requests, for example from a mismatched attribute or an expired token, need monitoring, or accounts drift out of sync quietly.
The standard also allows reading and searching users and groups, which some tools use to reconcile accounts that already exist.
When it matters for buyers
- When buying SaaS. Ask whether SCIM provisioning is included, on which plan, and whether it covers groups and deprovisioning, not just account creation. “SSO tax” pricing often applies to SCIM too.
- When offboarding is a recurring audit finding. SCIM is one of the most direct fixes for accounts left behind in SaaS apps.
- When license costs are creeping up. Automatic deactivation helps reclaim seats. SaaS management platforms can show which apps are not provisioned this way.
- When moving identity providers. Each SCIM connection needs to be rebuilt and tested, so count them in the migration plan.
Our SaaS management platforms overview covers tools that track provisioning and license use across your SaaS estate.
Questions to ask vendors
- Do you support SCIM 2.0, and on which plans?
- Which operations do you support: create, update, deactivate, delete and group management?
- Which attributes can be mapped, and can groups drive roles in your application?
- What happens to a user’s data and content when SCIM deactivates or deletes them?
- Do you revoke active sessions and API tokens when an account is deactivated?
- Is your integration published in our identity provider’s app catalog, and who supports it?
How it differs from SAML and OpenID Connect
Security Assertion Markup Language (SAML) and OpenID Connect (OIDC) handle sign-in: they let the identity provider tell an app who the user is at the moment they log in. SCIM handles the account itself, before and after sign-in: creating it in advance, keeping its details and groups current, and removing it when the person leaves. A typical well-run SaaS integration uses both, SAML or OIDC for SSO and SCIM for provisioning. Some apps offer just-in-time provisioning through SAML or OIDC instead, which creates accounts at first sign-in but generally doesn’t handle updates or removal. In larger environments, identity governance and administration (IGA) tools may also use SCIM, alongside other connectors, to provision accounts.