SCIM (System for Cross-domain Identity Management)

The System for Cross-domain Identity Management (SCIM) is an open standard protocol for automating the exchange of identity information between identity providers and the applications that hold user accounts. SCIM 2.0, an IETF Proposed Standard defined in RFC 7643 (core schema) and RFC 7644 (protocol), gives provisioning a common REST API and a common user and group schema, so that accounts can be created, changed and deactivated in each application without a separate integration per application. It is the protocol that turns a leaver in the HR system into a disabled account everywhere, which single sign-on on its own does not do.

The protocol is small. An application exposes /Users and /Groups endpoints, and the identity provider or identity governance system, acting as the SCIM client, creates, reads, changes and deletes resources there over HTTP with a JSON schema both sides understand. Three discovery endpoints tell the client which resources, attributes and operations the application supports. Little of that is hard to implement, and the protocol has been stable for a decade. What decides whether SCIM delivers anything is organizational: who is accountable for deprovisioning, what the organization demands when it buys software, how the provisioning credentials are protected, and who owns the mapping between the attributes on each side.

Deprovisioning Is the Control Auditors Test

Creating accounts is the part of provisioning everyone notices, because a new employee who cannot work complains on the first day. Removing them is the part that fails silently. A departed employee whose account survives in a sales, finance or source-code application complains to nobody, and the account stays usable for as long as a password, an API token or a local login bypasses the identity provider. Single Sign-On does not close this gap: disabling a user at the provider stops new federated logins and leaves every account and every open session in place. Just-in-time provisioning, in which an application creates an account at the first federated login, makes the gap grow, since it creates accounts automatically and never removes one.

Auditors know this, which is why leaver controls are tested at the applications and not at the provider. The usual test samples employees who left during the audit period and checks whether their accounts in the in-scope applications were disabled, and how quickly. SCIM is what makes the answer the same for every application that supports it: the leaver record arrives from HR, the provider sends a deactivation to each application, and the provisioning log records when each one was sent and answered.

Deactivation needs a decision of its own. RFC 7643 gives every user an active attribute, and a client can set it to false or delete the resource outright. Deactivating keeps the account and its history for investigations and for data the employee owned, while deleting removes it. The choice belongs in the joiner-mover-leaver policy, per application class, and not in the default of whichever connector was configured first. Movers are the hardest case. A change of department has to remove the groups and roles of the old job as well as add the new ones, and a connector that only ever adds memberships produces the slow accumulation of access that CIEM and access reviews then have to find.

Pushing changes is half of the control. The other half is reading accounts back: a SCIM client can list and filter the accounts an application holds and compare them with the source of truth, which is how orphaned and locally created accounts are found. RFC 9865 adds cursor-based pagination, the scheme most application data stores page by internally, so that reading back a large directory no longer requires the application to hold the whole result set in memory to serve numbered pages.

"Supports SCIM" Belongs in the Contract

Most of the provisioning an organization can automate is decided before any connector is built, when the application is bought. An application without a provisioning interface leaves a manual ticket or a custom script for every joiner and leaver, for the life of the contract. Provisioning is also often reserved for higher pricing tiers, so the requirement has to be in the tender, not discovered during rollout.

"Supports SCIM" on a feature list is not enough to evaluate, because implementations differ in what they cover. Does the application support groups, or users only? Does it accept PATCH, or only full replacement, which risks overwriting attributes the client does not manage? Does it filter on userName and externalId, so the client can match existing accounts instead of creating duplicates? And what does deactivation do: does it end the user's active sessions and revoke the API tokens and personal access tokens the user created, or only block the next login? An application that answers these questions badly supports SCIM on paper and still needs a manual leaver step, and the procurement team is the one with the leverage to find out before signing.

The SCIM Endpoint Is a Privileged API

A SCIM endpoint can create users, change their attributes and put them in groups, including the group that makes someone an administrator. Whoever holds its credential can therefore create an account for themselves with any privilege the application has, and that account will look like one the provisioning system created. RFC 7644 leaves authentication to the HTTP layer, and in practice many applications issue a single long-lived bearer token from their admin console for the provisioning connector to use. That token is an administrative credential for the application and has to be handled like one.

The hygiene is the same as for any privileged secret. The token is kept in a vault or in the provisioning system's protected configuration and never in a script or a ticket, it is rotated on a schedule and whenever someone who could read it leaves, and it is scoped to provisioning if the application allows any scoping at all. Where the application accepts OAuth, a client-credentials grant with short-lived access tokens, sender-constrained with DPoP or mutual TLS where supported, is better than a static secret. Network restrictions to the provisioning system's addresses reduce the exposure further. The other side matters as much: the identity provider or governance system holds a provisioning credential for every connected application, which puts its connector configuration among the most valuable targets in the estate, and administrative access to it should be held without standing privileges. Account creations and group changes that arrive at an application's SCIM endpoint without a matching request in the governance system are an anomaly Identity Threat Detection and Response should watch for.

Someone Has to Own the Schema

SCIM standardizes the envelope and a core user schema, with an enterprise extension for attributes such as employee number, department and manager. Every real deployment maps more than that. The application has its own idea of a unique username, its own required attributes and its own roles, and the source of truth has its own formats and gaps. RFC 7643 defines roles and entitlements as multi-valued attributes without saying what their values mean, so what a role is in one application has nothing in common with a role in the next.

Most provisioning errors start in the attribute mapping. A wrong source for userName creates duplicate accounts when someone changes their name, a missing manager breaks the approval workflows that depend on it, and a group mapped to the wrong application role grants access nobody requested. Each mapping therefore needs a named owner, usually split between the IAM team, which owns the identity attributes and their sources, and the application owner, who knows what each role grants. Changes to it deserve the same review as a change to an access policy, since in effect that is what they are. The discovery endpoints help here: a client can read an application's /Schemas and flag attributes that appear or disappear after an upgrade.

Events, Devices and Agents

The protocol above is a request-response API driven by the client. RFC 9967, a Proposed Standard since May 2026, adds a profile for Security Event Tokens (SETs), so that a SCIM service provider can publish provisioning events such as create, patch, activate and deactivate, and report the completion of long-running bulk requests. That changes what the governance system can see. An account created or changed inside the application itself can reach it as an event, instead of at the next reconciliation run. The events use the same token format and the same push and poll delivery as the Shared Signals Framework, and the two complement each other: SCIM events describe what happened to an account, while shared signals describe what happened to a session or a credential, such as a revoked session after a compromise.

RFC 9944, also a Proposed Standard since May 2026, extends SCIM to devices. It defines a Device resource with extensions for network onboarding methods, among them Wi-Fi Easy Connect, FIDO Device Onboard, Bluetooth Low Energy and MAC Authentication Bypass, and reverses the usual roles: the deployment's network infrastructure runs the SCIM server, and a supplier or an administrator's onboarding tool is the client. For organizations with large fleets of connected devices, this brings them into the same lifecycle model as other non-human identities, with the same questions about who owns the device record and who removes it.

AI agents are the next candidate. Several individual Internet-Drafts propose agent resource types, among them an AI Agent Resource Extension that defines an Agent with named owners. None has been adopted by the SCIM working group. The direction would let SCIM-capable governance tooling provision and deactivate agents through the protocol it already uses for users, which is why the AI Agent Registry and Lifecycle article treats SCIM as the provisioning path for an agent inventory, once one schema is settled.