SCIM is the standard that lets an identity provider or IGA platform create, update and remove user accounts in other applications automatically. Without it, provisioning depends on manual tickets, CSV uploads or custom scripts, and deprovisioning is where it most often fails: leavers keep access to SaaS applications for weeks or never lose it. SCIM 2.0 is widely supported by SaaS vendors and identity platforms, but "supports SCIM" can mean very different things in practice. This guide explains how SCIM works, where integrations commonly fail, how to secure the SCIM connection itself, and what SCIM does not solve.
Key takeaways
- SCIM 2.0 defines a standard schema and REST API for users and groups (RFC 7643 and RFC 7644).
- The main value is reliable deprovisioning, not just faster onboarding.
- Check what a vendor's SCIM support actually does: deactivation vs deletion, group sync, custom attributes and error handling.
- The SCIM bearer token can create and modify accounts. Treat it as a privileged NHI credential.
- SCIM manages accounts and groups; it does not remove tokens, API keys and sessions a user created. Plan for those separately.
How SCIM works
- The SCIM client (usually the identity provider or IGA platform) calls the SCIM service provider (the application) over HTTPS.
- Resources such as
/Usersand/Groupsare created with POST, updated with PUT or PATCH, read with GET and removed with DELETE. - The core schema covers common attributes such as userName, name, emails, active and group membership, and enterprise extensions add attributes such as employee number, department and manager.
- Setting
activeto false deactivates an account without deleting it, which many organisations prefer so audit history survives. - Applications publish what they support through discovery endpoints (
/ServiceProviderConfig,/Schemas,/ResourceTypes).
Where SCIM integrations fail
| Failure | Effect | What to check |
|---|---|---|
| Only create is implemented | Accounts appear but are never removed | Test deactivation and deletion explicitly |
| Deactivation leaves sessions and tokens alive | Leaver keeps working until sessions expire | Whether the app revokes sessions and API tokens on deactivation |
| Groups not synchronised | Access in the app drifts from policy | Group push and membership updates |
| Local accounts outside SCIM | Admins or break-glass accounts never deprovisioned | Whether local sign-in can be disabled; report accounts not managed by SCIM |
| Silent errors | Failed updates go unnoticed | Error logging, retries and alerting in the IdP or IGA |
| Attribute mapping mistakes | Wrong roles or departments assigned | Mapping reviews and test users |
| SCIM behind a premium licence tier | Teams fall back to manual provisioning | Licensing during procurement |
Securing SCIM
- Protect the SCIM token: it can create privileged accounts. Store it in a vault, scope it to provisioning only, rotate it and restrict source IP addresses where the application allows. See the API Key Management Guide.
- Prefer OAuth-based authentication for SCIM connections where both sides support it, over a static bearer token.
- Limit who can change SCIM configuration in the identity provider; a changed mapping or endpoint is a quiet way to grant access. See the Identity Provider and SSO Security Guide.
- Monitor for accounts created in applications outside SCIM, and for SCIM calls from unexpected sources.
- Be careful with inbound SCIM (an application or partner pushing identities into your IdP), which can create identities in your core directory.
What SCIM does not solve
- Personal access tokens, API keys and OAuth grants that a user created in the application. Revoke them separately at offboarding. See the Joiner-Mover-Leaver Guide.
- Non-human identities such as service accounts and integrations, which SCIM does not usually manage. See the NHI Lifecycle Management Guide.
- Fine-grained entitlements inside applications that SCIM groups do not express. IGA connectors or application APIs may be needed. See the IGA Buyer's Guide.
- Applications without SCIM: use IGA connectors, application APIs or, as a last resort, managed tickets with evidence of completion.
- Real-time events: SCIM is request-based; the Shared Signals Framework and emerging SCIM event work address notifying applications of changes such as account disablement.
Rolling out SCIM
- Rank applications by risk and number of users, and check SCIM support and licensing for each.
- Define the authoritative source and attribute mappings. See the Identity Data Quality Guide.
- Test the full lifecycle with test users: create, update, move, deactivate, reactivate and delete.
- Disable local account creation in the application where possible.
- Reconcile accounts in the application against the IdP after go-live, and remove strays.
- Monitor errors and alert on failed deprovisioning.
Practitioner checklist
- Require working SCIM deprovisioning (not just provisioning) for new SaaS purchases.
- Test deactivation and confirm it revokes sessions and tokens in the application.
- Vault, scope and rotate SCIM tokens, or use OAuth where supported.
- Restrict and monitor changes to SCIM configuration in the IdP.
- Reconcile application accounts against the IdP and remove unmanaged accounts.
- Handle tokens, API keys and NHIs outside SCIM in offboarding.
- Alert on provisioning errors.
Standards and references
- RFC 7643: SCIM Core Schema
- RFC 7644: SCIM Protocol
- RFC 7642: SCIM Definitions, Overview, Concepts and Requirements
- OpenID Shared Signals Working Group
Related NHI Mgmt Group resources: Joiner-Mover-Leaver Guide · IAM and IGA Basics · IGA Buyer's Guide · Identity Data Quality and Identity Fabric Guide