SCIM Provisioning: How It Works and the Places It Silently Breaks
SCIM is how accounts get created and removed across your apps automatically. Here is the mechanism, and the failure modes that leave access lingering.
When someone joins your company and their accounts in a dozen apps appear "automatically," and when they leave and those accounts are supposed to vanish, the thing doing the work is usually SCIM. It's one of the most load-bearing and least-examined pieces of identity plumbing, and its failures are quiet by nature.
What SCIM is
SCIM — System for Cross-domain Identity Management — is a standard protocol for provisioning and deprovisioning user accounts across systems. Your identity provider (the source of truth for who works here) speaks SCIM to each connected application. It's a simple REST API with a defined schema for users and groups: create this user, update that user's attributes, add them to this group, deactivate this user.
The idea is to make joiner/mover/leaver automatic. Onboard someone in the IdP, and SCIM pushes account creation out to Slack, the CRM, the wiki, and so on. Change their department, and SCIM updates their group memberships. Offboard them, and SCIM tells every app to deactivate the account.
How it works, mechanically
The IdP acts as the SCIM client; each application exposes a SCIM endpoint. When something changes, the IdP sends a request: POST /Users to create, PATCH /Users/{id} to update, often PATCH with active: false (or DELETE) to deprovision. The application's job is to honor these and reflect the change in its own user store. Done well, the IdP is the single place you grant and revoke, and every downstream app stays in sync.
Where it silently breaks
The word that matters is silently. Provisioning failures are loud — a new hire can't get into an app, so they complain and it gets fixed. Deprovisioning failures are silent — no one complains that a departed employee's account still works, because the departed employee isn't around to notice, and no one is checking. So the dangerous failures are the ones that leave access lingering.
The common failure modes:
- Apps that aren't connected. SCIM only covers the apps you wired up. The shadow SaaS tool a team adopted on a credit card isn't in the IdP, so the leaver keeps that account forever. Your deprovisioning is only as complete as your app inventory.
- Deactivate vs. delete. Some apps interpret SCIM "deactivate" as "suspend," leaving data and sometimes tokens intact; some leave existing sessions or API tokens valid even after the account is deactivated. The human is "gone" but their access artifacts aren't.
- Local accounts beside SSO. A user provisioned via SCIM may also have created a local password or a personal API token inside the app, out of band. Deprovisioning the SCIM identity doesn't touch those side-door credentials.
- Group-driven access drift. When access is granted through group membership, a mistake in group mapping silently over- or under-provisions, and nobody sees it until it's abused.
- Silent sync failures. A token between the IdP and an app expires, or a schema mismatch starts rejecting updates, and the sync just stops. Without monitoring, provisioning looks fine for new joiners while leavers quietly stop being removed.
- Service and shared accounts. SCIM handles humans. The service accounts and shared logins living in the same apps are outside its model entirely, so they're never swept.
What good looks like
- Reconcile, don't trust. Periodically compare who should have access (per the IdP) against who actually has access (per each app), and investigate the deltas. Deprovisioning that's never verified is deprovisioning you can't rely on.
- Monitor the sync itself. Alert when SCIM updates start failing, so a stalled connector doesn't silently strand leavers' accounts.
- Cover the whole app inventory. Deprovisioning is only complete if every app a person can reach is connected — which means knowing every app a person can reach.
- Kill sessions and tokens on offboard, not just the account. Deactivating a user should also invalidate their live sessions and any tokens they minted.
- Hunt for side-door credentials. Local passwords and personal API tokens created inside apps need their own sweep; SCIM won't find them.
The takeaway
SCIM makes identity lifecycle automatic, which is exactly why its failures hide: the system looks like it's working because onboarding works, while offboarding quietly leaks. The job isn't "turn on SCIM." It's continuously verifying that access which should be gone actually is — across every app, every session, and every side-door credential the protocol doesn't see.