What is SCIM provisioning?

SCIM provisioning is the automated creation, update and removal of user accounts in an application, driven by an identity provider rather than by hand. SCIM, the System for Cross-domain Identity Management, defines a standard JSON representation of users and groups (RFC 7643) and a REST API for managing them (RFC 7644). The identity provider acts as the client and pushes changes to any application exposing a SCIM endpoint, so when someone joins, changes role or leaves, their accounts follow automatically.

What is the difference between SAML and SCIM?

They solve adjacent problems and are almost always deployed together. SAML (and OIDC) handles authentication: proving who someone is at the moment they log in. SCIM handles provisioning: making sure the account exists, has the right attributes and group memberships, and is deactivated when they leave. SAML alone gives you single sign-on to accounts that must still be created and removed manually. SCIM alone gives you accurate accounts nobody can log into. Enterprise buyers typically require both, which is why they appear together in procurement checklists.

Which endpoints does SCIM 2.0 define?

The core resource endpoints are /Users and /Groups, supporting POST to create, GET to read or search, PUT to replace, PATCH to modify and DELETE to remove. Three discovery endpoints are also defined and frequently skipped by implementers: /ServiceProviderConfig declares which features the server supports, /ResourceTypes lists available resource types, and /Schemas describes the attributes for each. A client that reads ServiceProviderConfig before assuming PATCH support will fail less often.

Why do SCIM integrations break in practice?

Almost always because implementations are partial rather than because the standard is unclear. The recurring causes: PATCH is not implemented, or implemented with different semantics for multi-valued attributes such as group membership, so removals silently fail. Filtering support is inconsistent, so clients cannot reliably look up a user by userName before creating a duplicate. Soft delete versus hard delete is not specified by the RFC, so deprovisioning may deactivate rather than remove, which matters for licence reclamation and audit. And custom attribute extensions differ per vendor, so a working integration with one application tells you little about the next.

Does SCIM handle deprovisioning?

Yes, and this is usually the reason to adopt it. Deprovisioning is the part of the lifecycle most often done badly by hand, and orphaned accounts after someone leaves are a standing audit finding and a real attack path. SCIM automates removal alongside creation. One caveat worth checking per application: RFC 7644 does not mandate whether DELETE hard-deletes or deactivates, so confirm what your target application actually does before relying on it for licence reclamation or compliance evidence.

Is SCIM still current, and is there a SCIM 3.0?

SCIM 2.0 is the current version and has been stable since the RFCs were finalised in 2015. There is no SCIM 3.0. Work continues in the IETF SCIM working group on extensions and profiles rather than a new major version, so the protocol you implement today is the one that will still be in use for the foreseeable future. Stability is a genuine advantage here: unlike faster-moving identity specifications, a SCIM integration written years ago still works.

Do I need SCIM to sell to enterprises?

Increasingly yes, alongside SAML. Enterprise security reviews commonly require both single sign-on and automated provisioning before a purchase proceeds, because the buyer needs users removed on departure without raising a ticket with you. Building both yourself is a meaningful engineering commitment, which is why a market exists specifically for adding them quickly. See our SCIM provisioning tools comparison for the options.

Standard · stable

SCIM 2.0

RFC 7643 & RFC 7644IETFRFCs finalized 2015; widely implementedOfficial spec ↗

What it is

SCIM, the System for Cross-domain Identity Management, is the open standard for automating the user lifecycle across applications. When HR hires someone or an admin grants an app, SCIM pushes that change so accounts are created, updated, and, most importantly, removed without manual work. It is defined by RFC 7643 (the schema) and RFC 7644 (the protocol).

It answers a different question from SAML and OIDC. Those authenticate a person at login. SCIM makes sure the account exists, carries the right attributes, and disappears when they leave. Most enterprise deployments need both, which is why procurement checklists ask for them together.

How it works

SCIM defines a standard JSON representation of users and groups and a REST API to manage them. An identity provider acts as the client and pushes changes to any application that exposes a SCIM endpoint.

Standard schema: common attributes for users and groups, extensible per app.
REST operations: create, read, update, delete, and search over /Users and /Groups.
Discovery endpoints: /ServiceProviderConfig, /ResourceTypes and /Schemas declare what the server actually supports.
Filtering: query by attribute, for example userName eq "ada@example.com", so clients can look before they create.

The discovery endpoints are the most commonly skipped part of the specification, and skipping them is the most common cause of avoidable failures. A client that reads /ServiceProviderConfig before assuming PATCH is available fails less often than one that does not.

Where implementations actually break

The specification is clearer than its reputation. Deployments break because implementations are partial, and in a consistent set of places.

PATCH semantics for multi-valued attributes. Group membership is the usual casualty. Some implementations do not support PATCH at all; others differ on whether a patch to a multi-valued attribute replaces or appends. The visible symptom is that additions work and removals silently do not, which is the worst possible failure mode for deprovisioning.

Inconsistent filtering. If filtering is unreliable, a client cannot confirm whether a user already exists before creating one, and duplicates follow.

Soft delete versus hard delete. RFC 7644 does not mandate which happens on DELETE. Applications vary. That distinction decides whether a licence is reclaimed and whether an auditor sees the account as removed, so confirm it per application rather than assuming.

Custom schema extensions. Vendors extend the schema differently. A working integration against one application predicts very little about the next.

Status

The RFCs were finalised in 2015 and SCIM 2.0 remains current. There is no SCIM 3.0; IETF work continues on extensions and profiles rather than a new major version. That stability is an advantage: an integration written years ago still works.

Why it matters

Deprovisioning is the part of the identity lifecycle most often handled badly by hand, and orphaned accounts are both a standing audit finding and a real attack path. Automating removal is usually the business case, ahead of the convenience of automated creation.

For anyone selling B2B software, SCIM has become a gate. Enterprise security reviews routinely require both SSO and automated provisioning before purchase, which is why a market exists specifically for adding them quickly. See our SCIM provisioning tools comparison for the options.

SAML 2.0, OpenID Connect, and the SCIM glossary entry. For identity governance built on top of provisioning, see what is IGA.

Who wrote it

The SCIM protocol, RFC 7644, was edited by Phil Hunt with co-authors from SailPoint, Cisco, Nexus, and Salesforce. More in the experts directory.

Learn by listeningIdentity governance (IGA): 14 podcast episodes, basics to advanced

SCIM 2.0: frequently asked questions

What is SCIM provisioning?: SCIM provisioning is the automated creation, update and removal of user accounts in an application, driven by an identity provider rather than by hand. SCIM, the System for Cross-domain Identity Management, defines a standard JSON representation of users and groups (RFC 7643) and a REST API for managing them (RFC 7644). The identity provider acts as the client and pushes changes to any application exposing a SCIM endpoint, so when someone joins, changes role or leaves, their accounts follow automatically.
What is the difference between SAML and SCIM?: They solve adjacent problems and are almost always deployed together. SAML (and OIDC) handles authentication: proving who someone is at the moment they log in. SCIM handles provisioning: making sure the account exists, has the right attributes and group memberships, and is deactivated when they leave. SAML alone gives you single sign-on to accounts that must still be created and removed manually. SCIM alone gives you accurate accounts nobody can log into. Enterprise buyers typically require both, which is why they appear together in procurement checklists.
Which endpoints does SCIM 2.0 define?: The core resource endpoints are /Users and /Groups, supporting POST to create, GET to read or search, PUT to replace, PATCH to modify and DELETE to remove. Three discovery endpoints are also defined and frequently skipped by implementers: /ServiceProviderConfig declares which features the server supports, /ResourceTypes lists available resource types, and /Schemas describes the attributes for each. A client that reads ServiceProviderConfig before assuming PATCH support will fail less often.
Why do SCIM integrations break in practice?: Almost always because implementations are partial rather than because the standard is unclear. The recurring causes: PATCH is not implemented, or implemented with different semantics for multi-valued attributes such as group membership, so removals silently fail. Filtering support is inconsistent, so clients cannot reliably look up a user by userName before creating a duplicate. Soft delete versus hard delete is not specified by the RFC, so deprovisioning may deactivate rather than remove, which matters for licence reclamation and audit. And custom attribute extensions differ per vendor, so a working integration with one application tells you little about the next.
Does SCIM handle deprovisioning?: Yes, and this is usually the reason to adopt it. Deprovisioning is the part of the lifecycle most often done badly by hand, and orphaned accounts after someone leaves are a standing audit finding and a real attack path. SCIM automates removal alongside creation. One caveat worth checking per application: RFC 7644 does not mandate whether DELETE hard-deletes or deactivates, so confirm what your target application actually does before relying on it for licence reclamation or compliance evidence.
Is SCIM still current, and is there a SCIM 3.0?: SCIM 2.0 is the current version and has been stable since the RFCs were finalised in 2015. There is no SCIM 3.0. Work continues in the IETF SCIM working group on extensions and profiles rather than a new major version, so the protocol you implement today is the one that will still be in use for the foreseeable future. Stability is a genuine advantage here: unlike faster-moving identity specifications, a SCIM integration written years ago still works.
Do I need SCIM to sell to enterprises?: Increasingly yes, alongside SAML. Enterprise security reviews commonly require both single sign-on and automated provisioning before a purchase proceeds, because the buyer needs users removed on departure without raising a ticket with you. Building both yourself is a meaningful engineering commitment, which is why a market exists specifically for adding them quickly. See our SCIM provisioning tools comparison for the options.

Last reviewed September 20, 2026By SWI Community TeamSuggest a correction How we research

Independent, community-driven reference. Always confirm details against the official specification linked above.