SCIM explained: automatic user provisioning (RFC 7644)

SCIM is a standard way for one system to tell another which user accounts should exist. When a new employee is added to your company directory, SCIM can create their account in the email system, chat tool and project software at the same time; when they leave, it can switch those accounts off. The standard is defined by the IETF in RFC 7642, RFC 7643 and RFC 7644, published in September 2015.

What does SCIM do?

SCIM automates the user lifecycle, often summarised as joiner, mover, leaver:

• Joiner. A person is created in the identity provider and appears in every connected app with the right groups.
• Mover. The person changes team; attributes and group memberships are updated everywhere.
• Leaver. The account is deactivated or deleted across all apps, ideally at once.

Without such automation, each app needs a manual step. Forgotten accounts of former employees are a well-known security gap.

How does it work?

SCIM has two parts.

The schema (RFC 7643). It defines common resource types in JSON, mainly User and Group, with standard attributes such as userName, name, emails, active and groups, plus a way to add custom extensions. A user looks roughly like this:

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "a.example@company.example",
  "name": { "givenName": "Alex", "familyName": "Example" },
  "emails": [{ "value": "a.example@company.example", "primary": true }],
  "active": true
}

The protocol (RFC 7644). It is a REST API over HTTPS. The service provider, the application that holds accounts, exposes endpoints such as /Users and /Groups. The client, typically the identity provider, uses standard HTTP methods:

• POST /Users creates an account,
• GET /Users?filter=... searches,
• PUT replaces and PATCH modifies an account,
• DELETE removes it.

Further endpoints describe capabilities (/ServiceProviderConfig, /Schemas, /ResourceTypes), and an optional /Bulk endpoint allows many operations in one request. Payloads use the media type application/scim+json.

Where is SCIM used?

Large identity providers and business applications support SCIM, which is why it appears as a ‘provisioning’ tab in many admin consoles. Typical examples are workforce identity platforms from Microsoft and Okta connecting to hundreds of SaaS products. Always check the vendor’s documentation, because support varies: some apps offer SCIM only in higher-priced plans, and some implement only parts of the specification.

SCIM, SSO and federation

SCIM is often confused with single sign-on, but they solve different problems.

Question	Answered by
Who may have an account?	SCIM
Who is logging in right now?	SAML or OpenID Connect
How do organisations trust each other’s logins?	Identity federation

A typical setup uses SSO for authentication and SCIM for provisioning. Our page on single sign-on covers the login side.

Does SCIM matter for the EUDI Wallet?

Not directly. The wallet is a tool for individuals to hold and share credentials, and its protocols are OpenID for Verifiable Credential Issuance and Presentations plus the ISO mdoc and SD-JWT formats. SCIM is a back-office standard for organisations that manage many accounts. The connection is indirect: as employers adopt wallet-based or federated login, their need to keep accounts clean and current does not go away. Read the EUDI Wallet overview for the citizen-facing side.

Common limitations

SCIM describes how to exchange user and group records, but not every business rule. License assignment, app-specific roles and custom fields often need vendor extensions, and two products that both ‘support SCIM’ may not interoperate fully. Passwords are deliberately outside the intended flow, because the identity provider handles authentication. Expect to read each vendor’s SCIM notes and to test the combinations you rely on.

Examples

• Onboarding. HR adds a new hire to the directory; within minutes the person has accounts and group memberships in ten apps.
• Offboarding. On the last working day the account is deactivated everywhere, ending access that would otherwise linger.
• School year change. A school updates class groups in the directory and the learning platform follows.

Planning a SCIM rollout

Before switching provisioning on, decide which system is the source of truth, usually the HR system or the directory. Define which attributes flow where and which groups map to which app roles. Test with a small pilot group, because a wrong mapping can deactivate real accounts or hand out the wrong permissions at scale. Many products offer a dry-run or a manual sync first; use it. Also decide what ‘leaver’ means for each app: immediate deletion can destroy data that the organisation must keep, so deactivation followed by a retention period is often the safer default.

Security considerations

• Protect the SCIM credential. A bearer token that can create users can create administrators. Store it as a secret, scope it narrowly and rotate it.
• Deactivate, then review. Deactivating an account does not remove access tokens or app passwords that already exist. Check how each app handles sessions after deprovisioning.
• Minimise attributes. Provision only the attributes an app needs; each extra field is data that can leak.
• Log and monitor. Provisioning events show who created or changed which account; log them and alert on unusual bulk changes.
• Expect partial implementations. Test filters, group handling and PATCH behaviour, which vary between products.

Small teams can start with the advice in our guide to login security for small businesses.

Status in October 2026

SCIM 2.0 has been stable since 2015, and the core RFCs remain the reference. Any later extensions are separate documents, so rely on RFC 7643 and 7644 unless a vendor documents otherwise.