What Is SCIM? Automated User Provisioning Explained

SCIM (System for Cross-domain Identity Management) is a standard protocol for automatically creating, updating, and deactivating user accounts across applications as a company’s central identity directory changes. Where SSO answers “how does this user log in,” SCIM answers a different question: “does this user’s account even exist in this app, with the right attributes, and does it get removed the moment they leave the company?”

The problem SCIM solves

Without SCIM, provisioning a new employee into every tool they need — email, chat, the CRM, a dozen SaaS apps — is manual work: someone in IT creates an account in each system by hand, sets a role, and hopes they remembered every app the person needs. Offboarding is the more dangerous half of the same problem: when someone leaves, every one of those manually created accounts has to be manually disabled too, and it’s common for a few to be missed — leaving a former employee’s credentials active in some forgotten tool for months.

SCIM automates both directions. A company’s identity provider (Okta, Entra ID, and similar directory services) becomes the single source of truth for who should have access to what. When someone joins, changes teams, or leaves, the identity provider pushes that change out to every connected application via the SCIM protocol, and each application’s user list stays in sync automatically.

How the protocol works

SCIM is a REST API convention with a defined JSON schema for representing users and groups. The identity provider acts as the client, and each connected application exposes a SCIM endpoint that acts as the server. The identity provider makes standard HTTP requests against that endpoint:

• POST /Users — create a new user, with attributes like name, email, and role.
• PATCH /Users/{id} — update specific attributes, such as a changed department or a demoted role.
• DELETE /Users/{id} (or a PATCH that sets active: false) — deactivate the account.
• GET /Users and GET /Groups — query existing records, often used to reconcile state periodically rather than relying solely on push events.

Because the schema is standardized, an application that implements SCIM correctly can be provisioned by any SCIM-compliant identity provider without custom integration work on either side — the same benefit that a standard like OAuth provides for authentication, just applied to account lifecycle instead of login.

SCIM vs SSO: different jobs

It’s easy to conflate the two because they’re usually configured together and both live under “identity management,” but they solve different problems:

	SSO	SCIM
Question it answers	How does the user authenticate?	Does the user’s account exist, with the right attributes?
Triggered by	The user, at login time	The identity provider, when directory data changes
Without it	Separate password per app	Manual account creation and deletion per app
Protocol examples	SAML, OpenID Connect	SCIM (its own dedicated standard)

A company can have SSO without SCIM: users authenticate through a single identity provider, but someone still has to manually create their account in each downstream app first, and manually remove it later. SCIM without SSO is less common in practice, but conceptually separate: an app’s accounts could stay in sync automatically while users still log in with per-app credentials. Most enterprise deployments run both together, because the combination is what actually closes the offboarding gap: SSO makes login instant, SCIM makes sure there’s no dangling account left behind to secure once access should be gone.

Why offboarding is the real driver

Security and compliance teams tend to push for SCIM harder than for SSO alone, because the offboarding case is where manual provisioning fails most dangerously. A missed SSO configuration is an inconvenience — a locked-out user files a ticket. A missed deprovisioning step is a live, unattended credential sitting in a system nobody’s watching, which is exactly the kind of gap a zero-trust posture is designed to close by treating every access grant as something that needs continuous verification and is not simply trusted forever. SCIM turns “deactivate every account when someone leaves” from a manual checklist into something that happens automatically the moment HR marks them as terminated in the directory.

Where SCIM fits for a growing SaaS product

For a company building a B2B application, supporting SCIM is often a prerequisite for selling into larger enterprise customers — procurement and security teams frequently require it explicitly, separate from any request for MFA or SSO support, precisely because it’s the piece that lets their own IT team stop manually managing your app’s user list. Implementing it means exposing a SCIM-compliant endpoint against the schema the standard defines, and handling the create, update, and deactivate operations correctly — including making sure a deactivated SCIM user is actually locked out of the application, not just flagged in a database column that the rest of the app ignores.

The takeaway

SCIM is the automation layer behind enterprise identity: it keeps user accounts across every connected application in sync with a company’s central directory, so a new hire gets access automatically and a departing employee’s access disappears everywhere at once. It’s a separate concern from SSO — SSO handles how someone logs in, SCIM handles whether their account should exist at all — and together they’re what let large organizations manage access at a scale that manual provisioning and offboarding simply can’t keep up with.