What is SCIM provisioning?

SCIM — System for Cross-domain Identity Management — is an open standard for keeping user accounts in sync between an identity provider and the applications a company uses. Your directory (Entra ID, Okta, Google Workspace, OneLogin) becomes the authority on who exists, and it pushes changes to each connected application over a REST API with a defined schema.

It is usually written as "SSO and SCIM", and the pairing confuses people. They solve different halves of the same problem:

Single sign-on answers can this person log in right now? It is checked at the moment of access.
SCIM answers does this person have an account, and what are they in it? It runs in the background, whether or not anyone is logging in.

A product can have one without the other, and plenty do.

What it actually does

Create. Someone joins, is added to a group in the directory, and an account appears in the application without anybody filing a ticket.

Update. Their name, email or department changes in one place and propagates. Group membership changes move them between roles.

Deactivate. This is the reason SCIM exists. Someone leaves, HR disables them in the directory, and their access disappears everywhere — in minutes, not when somebody remembers.

Group sync. Directory groups map to groups or roles inside the application, so "everyone in Finance" is a membership the directory maintains rather than a list an administrator curates by hand.

Why deprovisioning is the whole argument

Access that outlives employment is the most common finding in any access review, and it is almost never malice — it is simply that nobody owns the leaver checklist for the twelfth application. With SSO alone, a disabled directory account does stop new logins, which is genuinely most of the risk. But the account still exists: it holds data, it may hold API keys that authenticate independently of any login, and it still appears in your seat count.

For anything holding company data this matters more than it sounds. An orphaned account with a live API key is not blocked by single sign-on, because an API key never goes near the login screen.

What SCIM does not do

It is not authentication. SCIM never checks a password or a factor. That is SAML or OIDC.
It is not authorisation. SCIM can say which group someone is in; it does not define what that group may do. That is RBAC and lives in the application.
It is not data migration. It syncs identity, not the person's content.
It does not reconcile reliably on its own. Most implementations push changes as they happen and never sweep for drift. If a change is missed, it stays missed until someone runs a full sync.

What to check before you believe a SCIM claim

Vendors advertise "SCIM support" at wildly different depths. The questions that separate them:

Does deactivation actually revoke, or just flag? Setting active: false should end sessions and invalidate tokens, not merely grey out a row.
Are groups supported, or only users? User-only SCIM leaves every role assignment manual, which is most of the work.
What happens to API keys the person created? If they survive deprovisioning, deprovisioning is incomplete.
Is it on every plan? SCIM is the classic feature held behind an enterprise tier, which is how companies that most need it end up without it.
Is there an audit trail? A provisioning change nobody can see afterwards is not a control.

Memtro supports SAML and OIDC single sign-on against your own directory and SCIM provisioning for joiners, leavers and groups, at every price rather than as an enterprise upsell, with an audit log of every administrative change.

A note on seats

There is a commercial side effect worth knowing. Because SCIM removes accounts as reliably as it creates them, it tends to reduce the number of seats a company is paying for — the leavers nobody cleaned up. For per-seat products that is an awkward incentive. It is one reason to prefer pricing that is not per seat at all.