The more cloud applications an organization relies on, the more user accounts it has to create, update and remove. New employees need access to programs, existing staff change roles and responsibilities, contractors come and go, and departing team members need to be removed from every connected system.
Managing these changes by hand consumes IT time and delays onboarding. It also creates security risks from dormant accounts that remain active after someone has left the company. And many problems only come to light during an access review or audit.
SCIM (System for Cross-domain Identity Management) is an open standard for automated user provisioning across connected applications. This guide explains how SCIM works, how it differs from Security Assertion Markup Language (SAML) and single sign-on (SSO), and what to look for when evaluating SCIM support.
Table of contents
- What is SCIM provisioning?
- The cost of managing user accounts by hand
- Key benefits of automated user provisioning with SCIM
- SCIM vs SAML: understanding the difference
- What to look for in a SCIM-ready platform
- How DocuWare supports SCIM provisioning
- Frequently asked questions about SCIM user provisioning
What is SCIM provisioning?
SCIM stands for System for Cross-domain Identity Management. It's a standard protocol for exchanging user account information between an identity provider and business applications.
Because SCIM is an open standard, organizations don't need a custom integration for every application. Any product that supports SCIM uses the same protocol to exchange user information. SCIM 2.0, published by the IETF in 2015, defines both the data model and the protocol.
Without SCIM, administrators have to create, update and remove user accounts separately in every application. With SCIM, the identity provider holds the master user record, and account changes flow automatically to connected applications. The result is less manual administration and fewer opportunities for errors.
SCIM and SAML are terms often used together, but they do different jobs. SAML authenticates the user; SCIM manages the user account.
How does SCIM work?
With SCIM provisioning, the identity provider becomes the single source of truth for user information. When someone joins, changes roles or leaves, changes are sent to connected applications over a standard REST API using JSON.
Connected applications expose a defined set of SCIM endpoints, usually users and groups, and the identity provider makes authenticated requests to them. User records follow a standard schema, which specifies attributes such as username, emails and name. Using the same schema and endpoints across integrations makes it much easier to connect new applications.
Four operations make up most SCIM provisioning activity:
- Create. A new employee joins the business. Once they're assigned to an application, the matching account is created automatically.
- Read. Existing accounts are checked before a new one is added, helping to avoid duplicate users.
- Update. Changes to a user's name, department, job title or group membership are synchronized across connected applications.
- Deactivate or delete. Most identity providers disable accounts by setting the active attribute to false rather than deleting them. Users can no longer sign in, but the account and its audit history remain available.
SCIM can also provision and manage groups. If a user is added to or removed from a department or security group in the identity provider, the change is synchronized with connected applications.
Changes aren't normally applied immediately. Most identity providers run provisioning on a schedule, typically every 20 to 40 minutes. Compared with manual provisioning, where account changes often wait until someone has time to make them, a scheduled synchronization is still a substantial improvement.
The cost of managing user accounts by hand
Manual provisioning is manageable with a small number of users and applications. But every new hire, role change and departure means more accounts to update, more permissions to maintain and more opportunities for something to be missed. The effects are felt across the business:
- Administrative workload. Every change means updating multiple applications. Each new system adds another set of accounts to manage.
- Dormant accounts. Contractor, temporary staff and former employee accounts are easy to lose track of, particularly in organizations with multiple applications.
- Access creep. New permissions are added as people move roles and existing permissions are not always removed at the same time. After a few years, tenured employees often hold wider access than their current role requires.
- Inconsistent audit trails. One application records access changes in a ticket, another in an email, another in its own audit log. Bringing those records together takes time. If you're working to SOX 404 controls or a similar framework, inconsistent records create extra work during testing and remediation.
- Manual errors. A mistyped username, old email address or the wrong role assignment can leave one application out of step with the others.
Key benefits of automated user provisioning with SCIM
Quicker onboarding, cleaner offboarding
New hires can receive access to the applications they need on day one. When someone leaves, disabling their account in the identity provider removes access across connected applications during the next synchronization cycle, without each application having to be updated separately.
Less repetition of work
User accounts are created once but updated throughout a person's time with the organization. Job changes and name changes require updates across multiple applications; SCIM removes much of that repeated administration by applying those changes automatically. Because every connected application receives the same information from a single source, inconsistencies between systems become less common, reducing the time spent correcting account and access issues.
Stronger security and compliance posture
With SCIM provisioning, access is granted, changed and removed through the identity provider rather than separately in each application. Instead of piecing together emails, tickets and application logs, IT teams have a single place to check account changes. It also becomes easier to answer audit questions, such as who had access to a particular system at a particular point in time.
Keeping tighter control over who can access systems containing sensitive information is increasingly important as privacy requirements evolve. In California, for example, CCPA administrative fines rose in January 2025 to as much as $2,663 per violation, or $7,988 for intentional violations and certain violations involving the personal information of consumers under 16. Statutory damages for certain data breaches also increased to between $107 and $799 per consumer, per incident.
While SCIM alone does not ensure CCPA compliance, automated provisioning can support stronger access controls by helping organizations remove unnecessary access promptly and maintain more consistent records of account changes.
Read more on best practices for automating compliance.
More choice over identity providers
SCIM uses a common protocol that different identity providers can support. Microsoft Entra ID, Okta, Ping and other compatible providers all use the same approach. If your identity provider changes, your applications don't need a different provisioning method. That flexibility is useful in hybrid environments and makes future identity provider migrations less disruptive.
SCIM vs SAML: understanding the difference
SCIM and SAML solve different problems. SAML confirms a user's identity when they sign in, whereas SCIM creates, updates and removes user accounts.
|
SAML (SSO) |
SCIM (provisioning) |
|
|
Purpose |
Authentication — verifying who is signing in |
Account lifecycle — creating, updating, and deactivating users |
|
When it runs |
At each login attempt |
Whenever directory data changes |
|
What it transfers |
A signed assertion about one login |
User and group records |
|
Without it |
Separate passwords for every application |
Accounts created and removed by hand |
SCIM SSO integration
SCIM and SSO perform different jobs. SSO (using SAML or OIDC) authenticates users when they sign in, while SCIM manages the user accounts behind those logins. Most organizations use both.
For SCIM SSO integration to work correctly, the values used to identify each user need to match. If the username in the SSO claim doesn't match the account provisioned through SCIM, users may be unable to sign in, or a duplicate account may be created.
What to look for in a SCIM-ready platform
Two platforms may both support SCIM 2.0, but the quality of that support can differ. If SCIM is part of your requirements, here are some key points to check:
- Support for SCIM 2.0. Look for full support for the standard rather than a proprietary synchronization tool described as “SCIM-compatible”.
- Identity provider compatibility. Check support for your identity provider, including generic or custom identity providers where required.
- User and group provisioning. Automating user accounts is only part of the solution. Group membership should also be created, updated and removed automatically.
- Flexible attribute mapping. Usernames, email addresses, roles and account status should be mapped and synchronized consistently across connected applications. Some implementations shorten or reformat values on the way in, which causes mismatches with single sign-on later.
- Support for your environment. If you operate cloud, on-premises or hybrid environments, provisioning should work across your technology infrastructure.
- Lifecycle management. Check how users are created, updated and deprovisioned, and what happens to documents, workflows and pending tasks when an account is disabled.
- Straightforward configuration. SCIM provisioning should be something your IT team can configure without extensive custom development or professional services.
Our guide on what to look for in a document management system covers the wider evaluation criteria.
How DocuWare supports SCIM provisioning
DocuWare Cloud supports SCIM 2.0 provisioning with Microsoft Entra ID, Okta, Ping Identity and generic identity providers. Organizations using other compatible identity platforms aren't limited to vendor-specific integrations.
Once configured, our software can:
- Create users automatically from your identity provider.
- Synchronize user attributes, including usernames, email addresses and account status.
- Deactivate users automatically when accounts are disabled in your identity provider.
- Provision groups and assign users to them.
- Keep group memberships synchronized as users join, leave or change roles.
For organizations that continue to use on-premises Active Directory as their authoritative directory, DocuWare's User Provisioning application synchronizes identities with DocuWare Cloud over SCIM, allowing cloud accounts to follow existing directory changes without duplicate administration.
For DocuWare Cloud, provisioning is configured in DocuWare Configuration under General > User Provisioning. Select your identity provider and generate the credentials it will use to connect.
For on-premises deployments, our User Provisioning Configurator desktop application has been recently redesigned, with an updated interface that makes the setup sequence easier to follow. Both are included in DocuWare version 7.14.
DocuWare supports single sign-on alongside SCIM provisioning, so users authenticate identity through your existing identity provider rather than a separate DocuWare login.
Step-by-step guidance is available in the DocuWare Knowledge Center, including generic identity provider integration, connecting an on-premises Active Directory to DocuWare Cloud, and configuring the User Provisioning desktop application.
If you're evaluating SCIM provisioning for your organization, you can also request a demonstration of DocuWare Cloud.
Frequently asked questions about SCIM user provisioning
What is SCIM provisioning?
SCIM provisioning automatically creates, updates and deactivates user accounts across connected applications using the System for Cross-domain Identity Management (SCIM) standard. It allows an identity provider to keep user accounts synchronized without managing each application separately.
How does SCIM work?
SCIM lets an identity provider exchange user account information with business applications over REST APIs using JSON. Applications expose SCIM endpoints for users and groups, and the identity provider sends authenticated requests to them whenever a directory record changes. Records follow the SCIM 2.0 schema, so the same format works across every application supporting the protocol.
What is SCIM used for?
SCIM automates routine account administration across multiple applications. It creates accounts for new hires, applies changes when people change roles and removes access when they leave. It also manages group membership, so security and department groups in the identity provider are reflected in each application.
SCIM vs SSO: what’s the difference?
SCIM and single sign-on (SSO) solve different problems. SCIM creates, updates and removes user accounts. SSO verifies a user's identity when they sign in. Most organizations run both, with SCIM managing the account lifecycle and SAML or OIDC handling authentication at login.
Does SCIM replace SAML?
No. SAML and SCIM do different jobs. SAML authenticates users when they sign in, while SCIM creates, updates and removes their accounts. Most organizations use both together.
How does SCIM security work?
Manual account changes are easy to miss, especially across dozens of applications. SCIM removes much of that risk by applying the same change wherever the user has an account. IT also has a more complete record of how access has changed over time.
What identity providers support SCIM?
Microsoft Entra ID, Okta and Ping all support SCIM, along with many other identity providers. Because SCIM is an open standard, applications that support generic identity providers can also integrate with custom or in-house directory services.