SCIM Provisioning: Why Deprovisioning Is the Part Everyone Gets Wrong

What SCIM actually is

SCIM stands for System for Cross-domain Identity Management. It is an open standard — schema in RFC 7643, protocol in RFC 7644 — that defines a REST API for moving identity data between systems. Version 2.0 is what every major IdP implements.

The mental model is simpler than the acronym. Your IdP is the client, the downstream application is the server. The IdP holds a list of people and groups, and when that list changes it makes an HTTP call to say so.

SCIM defines two resource collections, and the whole protocol hangs off them:

The second-to-last row is the important one. SCIM has a first-class, standard way to say this person should no longer have access — and that signal originates where somebody’s departure is already recorded, which is HR-fed identity, not a spreadsheet owned by IT.

SCIM is not SSO, and the difference matters

SSO answers a question at login time: is this person who they claim to be, right now? A SAML assertion or an OIDC token arrives, the application validates it, the session starts.

SCIM answers a question continuously: should this person exist here at all? It runs on its own schedule, independent of whether anyone is logging in.

The gap between those two is the whole problem. Run SSO with just-in-time account creation and nothing else, and your IdP guards the front door while the accounts behind it accumulate forever. Deactivating someone in the IdP does block new logins. The account object is still there, still attached to whatever roles, memberships, and — this is what stings on an AI platform — whatever API keys and service tokens it collected.

Why deprovisioning is the part everyone gets wrong

Onboarding is a loud failure. Offboarding is a silent one. That asymmetry explains almost every access-review finding we’ve ever seen.

Nobody complains about access they shouldn’t have. When provisioning breaks, a new engineer pings a channel within twenty minutes. When deprovisioning breaks, the beneficiary has already left the building. There is no feedback loop, so the defect persists until an auditor goes looking.

Manual offboarding checklists decay. The checklist is written when the company has eight SaaS tools. Two years later it has sixty, and the checklist still has eight.

The dwell time is long. Because nothing surfaces the problem, orphaned accounts are usually measured in months, and they turn up during an audit or an incident — the two worst moments to find them.

On AI platforms, an orphaned account is more than a login. A stale user record can be attached to model provider credentials, MCP server access, deployed workloads, and long-lived API keys. Browser sessions expire on their own. Programmatic credentials do not. This is why API authentication and RBAC in an AI gateway has to be identity-aware rather than key-aware — a key with no owner is a key nobody will ever revoke.

SCIM removes the human step. The departure is recorded once, in the IdP, and propagates outward.

SCIM vs JIT vs invite-only: which provisioning mode to use

TrueFoundry supports three provisioning modes, and a tenant uses exactly one at a time. This is the decision most teams are actually trying to make when they search for SCIM.

Three things fall out of this table.

JIT is not a lightweight SCIM. It is half of SCIM — the visible half. It handles a new person needing an account, well and with zero configuration. It does nothing about a person leaving. If your reason for choosing JIT is “we’ll deal with offboarding manually,” write down honestly who owns that step and how it gets audited.

Invite-only is not a worse option, it’s a different one. For a contractor at a partner firm with no record in your IdP, an invite is the correct mechanism. The problem is using it for employees who are in your IdP, because then your admins become a manual replica of a system you already pay for.

Group sync is the row people underweight. Creating users automatically saves a few minutes per hire. Syncing groups is what keeps authorization correct over time — a permanent cost rather than a one-time one.

Where teams get this wrong

Treating SSO as deprovisioning. The most common mistake, and an understandable one, because disabling a user in the IdP does block new logins. What it does not do is remove the account, its group memberships, or any credentials it holds. Blocking the front door is not the same as closing the account.

Group names that silently fail to sync. Every provisioning system has naming constraints, and IdP groups are usually named by people who have never read them. A group called ML Platform — Prod (EMEA) contains a space, an em dash, and parentheses, and will not become a valid team downstream. The failure is quiet: users sync, the group doesn’t, and nobody notices until someone asks why the team is empty.

Assuming SCIM reaches every grant a person holds. SCIM syncs users and group membership. It knows nothing about permissions granted directly, outside any group, on a specific resource. Remove someone from a team and the direct grant survives. This is the most common answer to “why can this person still see that.”

Storing the SCIM token badly, or not at all. The Bearer token is displayed once. Teams paste it into the IdP, close the tab, and keep no copy. That is survivable — you generate a new one — but doing so invalidates the old one, so provisioning stops until the IdP is updated too. Put it in your secret manager before you close the tab.

Want to see the lifecycle end to end?

Spin up a TrueFoundry tenant, wire up your IdP, and watch a group become a team.

Get started free

How SCIM provisioning works in TrueFoundry

TrueFoundry supports SCIM against both OIDC and SAML v2 SSO configurations. Before you configure provisioning, you need SSO working — the SCIM URL and token live alongside the SSO configuration, not in a separate integration.

Step 1 — Configure SSO

Go to Platform → Settings → SSO, toggle Enabled, pick your provider, and choose OIDC or SAML v2.

For OIDC you supply a Client ID, Client Secret, and Issuer URL; the callback URL on the IdP side is always https://login.truefoundry.com/oauth2/callback. For SAML you supply the IdP SSO URL and an X.509 signing certificate, then return after saving to collect the Callback URL and Issuer TrueFoundry generates and paste those into your IdP.

One detail that saves time later: configure your IdP to emit claims named email, sub, and groups. Those are TrueFoundry’s defaults, and aliasing the attributes on the IdP side means you never touch the advanced fields.

Step 2 — Turn on SCIM

Go to Settings → Security & Access → Provisioning and select SCIM. This is where all three provisioning modes live, and picking one is how you choose the tenant’s lifecycle model.

Step 3 — Copy the SCIM Base URL

Expand your saved SSO configuration to reveal the SCIM URL along with the rest of the metadata. This is the value your IdP calls.

Step 4 — Generate the SCIM token

Click the key icon next to the SSO configuration to generate the SCIM authentication token.

Treat it like a password. It is shown only at creation; if you lose it, you generate a replacement and the previous token stops working.

Step 5 — Point your IdP at it

In your IdP’s provisioning settings, set the Base URL (some IdPs call it Tenant URL) to the SCIM URL, set Authentication to Bearer Token, and paste the SCIM token as the token value. Then assign users and groups in the IdP and start provisioning. Within a few minutes, users and teams appear in TrueFoundry.

IdP groups become teams — this is the part that matters

Most SCIM write-ups stop at user sync. User sync is the easy half. The reason to run SCIM on a platform like this is group sync, because groups are where authorization lives.

When the tenant is configured for SCIM, every group your IdP pushes through becomes a TrueFoundry team automatically. Add someone to the IdP group and they join the team; remove them and they leave it.

Synced teams are ordinary teams in every other respect. You can grant them resource access, assign tenant-level roles, and add identity provider claim mappings.

Be precise about the division of labour, because it is easy to over-claim. SCIM does not decide what a team may do — an admin grants the team its roles once, deliberately. SCIM automates membership, and since permissions attach to the team, current membership means a current effective permission set. Design the authorization once; let the IdP handle the churn.

There is a naming constraint to respect. The IdP group name becomes the team name, so it may contain only alphanumeric characters, hyphens, and underscores, and can be at most 36 characters. Rename groups in the IdP before you turn provisioning on, not after.

A worked example: a contractor on the ML platform team

Here’s the lifecycle running end to end, with the manual steps marked.

One-time setup (manual). An admin creates an IdP group called ml-platform-contractors — lowercase, hyphens, 23 characters, safe. SCIM pushes it and a team of the same name appears in TrueFoundry. The admin grants that team what it needs: the relevant model provider account, User access on two MCP servers, nothing else. That is the authorization design, done once.

Onboarding (automatic). A contractor starts. HR provisioning adds them to ml-platform-contractors. SCIM creates their TrueFoundry user and adds them to the team. They log in through SSO with exactly the access the team holds. Nobody filed a ticket.

Scope change (automatic). Three months in, the contractor moves to a different project. Someone removes them from ml-platform-contractors and adds them to another group. SCIM adjusts both teams. Their model provider access disappears with the team membership, and no admin touched TrueFoundry.

Offboarding (automatic). The contract ends. The IdP record is deactivated. SCIM marks the TrueFoundry user inactive, and a deactivated user is rejected during the authentication flow. The account no longer functions, without anyone remembering that TrueFoundry was on the list.

The one thing still manual. If that contractor had also been granted something directly — a single secret group, say, outside any team — that grant survives, because it never came from the IdP. Deactivation blocks the login regardless, but the grant record remains until someone removes it. Build that into your access review. It is the same pattern that shows up across enterprise MCP access control: inherited and direct permissions combine, and removing one does not remove the other.

Ready to make your IdP the source of truth?

Configure SSO, switch on SCIM, and let group membership drive access.

Start free on TrueFoundry

Gotchas worth knowing

For Entra ID and Okta, SCIM requires SAML. The capability matrix lists SSO as merely recommended for SCIM in general, but for the two most widely deployed IdPs the provisioning guides depend on the SAML configuration. If you set up OIDC with Entra or Okta and then go looking for SCIM, you will be reconfiguring.

One provisioning mode per tenant. You cannot run SCIM for employees and invite-only for contractors in the same tenant by flipping both switches. If you need to bring in someone who isn’t in your IdP, the Invite User flow on Access > Users still exists — and when you use it for an SSO user, leave the Send email to set password checkbox unchecked, since there is no password to set.

Deactivation and deletion are different operations. Deactivating blocks login and is what SCIM drives. Deleting a user outright is a separate admin action, and TrueFoundry refuses it until the user has been explicitly removed from all resources and teams. That guard stops you deleting an identity while dangling grants still reference it.

The dedicated Provisioning page arrived in v0.143. On earlier versions SCIM is configured inline in the SSO form. The values are the same; the screens differ.

‍