What Is Account Provisioning? SCIM and Implementation

Account provisioning prepares and maintains the accounts people need to use systems. A useful deployment covers more than account creation: it also handles job changes and retirement of access when someone leaves.

The same principles apply to internal applications, on-premises systems, cloud services, and SaaS. This guide focuses on SCIM 2.0 and adding automation to an application that already uses SSO. Sources and product information were checked on November 1, 2026.

Provisioning, deprovisioning, and lifecycle management

Identity lifecycle management follows an identity from creation through changes to retirement. An authoritative source, such as approved HR records or a directory, drives changes in downstream systems. Deprovisioning disables or removes access that is no longer required.

Event	Typical work	Key question
Joiner	Create account and initial memberships	Is access approved, timely, and limited to what is needed?
Mover	Update department, role, and memberships	Were old privileges removed as well as new ones added?
Leaver	Disable access, transfer ownership, eventually delete where appropriate	What are the deadlines, retention rules, and rehire requirements?

Manual administration means repeating these changes in each target. Automation reduces repetitive work but also spreads incorrect source data or mappings. Monitor actual target state as well as job completion.

What SCIM standardizes

System for Cross-domain Identity Management (SCIM) provides a standard way to manage identity resources across systems. RFC 7643 defines the core schema; RFC 7644 defines the HTTP protocol. SCIM manages accounts rather than performing SAML or OIDC sign-in.

Typically, the identity platform’s provisioning service acts as the SCIM client and the target application exposes the SCIM service. These are management roles, separate from SAML’s authentication roles of IdP and SP.

HR or directory → provisioning service → HTTPS management API → application users and groups

An internal target may need an agent or private connectivity. Proprietary APIs and directory integrations are alternatives where SCIM is unavailable.

Users, Groups, and operations

Users represents user resources; Groups represents groups and their memberships. Actual support varies. Using a group to select who gets an application is different from creating that group in the application.

Method	Purpose	Example
POST	Create a resource	Add a user under `/Users`
GET	Retrieve or search	Read `/Users/{id}` or use a filter
PATCH	Change selected values	Update activity state or membership
PUT	Replace writable resource attributes	Account for the effect of omitted values
DELETE	Remove a resource	Delete `/Users/{id}`

Check supported operations, including PATCH. Internal retention after deletion and the operational effect of active=false depend on the application.

Identifier example

An application might return this fictional user:

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id": "app-u-8421",
  "externalId": "source-user-0198",
  "userName": "alex@example.com",
  "active": true
}

Attribute	Meaning in this example	Design implication
`id`	Target-issued resource identifier	Stable for the resource’s lifetime
`externalId`	Optional identifier supplied by the client	Could link to a stable source identity if supported and mapped
`userName`	Required target username	Need not be an email address and may change
`active`	Administrative status	Test what disabling actually blocks

If Alex’s username changes, an update to the same account preserves its target id. Do not assume externalId exists or automatically provides matching without connector configuration.

Adding provisioning to an existing SSO deployment

Suppose an internal portal already trusts a cloud IdP and contains employee files, posts, and permissions. Administrators currently create and maintain its accounts manually.

Keep the established SSO configuration where possible and add a separate management connection. The goal is to manage the existing accounts, preserving their identity and associated data while automating lifecycle changes. Deleting and recreating users is not an inherent requirement of enabling SCIM.

Area	Before	Intended after state
Authentication	Existing SAML or OIDC SSO	Retained
Account administration	Manual or separately managed	Automated through SCIM or another connector
Existing users	Own application data and permissions	Matched to the same target accounts
Data and permissions	Managed inside the application	Retention and intended changes verified

See SSO vs. provisioning for responsibilities and SSO protocols for authentication identifiers.

Matching existing users

Matching links a source identity to an existing target account. Inspect the attributes the connector actually searches and the number of results it receives.

Inventory source and target users, including target internal IDs.
Identify searchable matching attributes: perhaps username, email, or a stable identifier.
Check uniqueness, missing values, aliases, case handling, renames, and rehires.
Pilot against existing accounts and inspect whether the connector updates the original target ID.
Sign in through SSO and verify that the user reaches that same account and its original data.

For example, a SAML NameID and SCIM userName might both contain alex@example.com. They can help resolve the same account if the application’s rules support it. The standards do not automatically equate NameID with SCIM id, externalId, or userName; OIDC sub is not automatically a SCIM identifier either.

Zero matches may cause a new account to be created. Multiple matches may cause errors or unsafe association. Reused email addresses can also link the wrong person to old data. Inspect create-versus-update events, and stop expanding scope if duplicates appear. Coordinate with JIT account creation to avoid competing creation paths.

Matching rules, precedence, and stored links are connector-specific. Microsoft Entra ID, for example, supports matching attributes and precedence, but the target API must support filtering on the chosen attribute.

Preserving existing data

Continuing to use the same account often allows its associated data to remain, but this is application-dependent. SCIM is not a file or chat migration protocol, and changes to attributes or memberships may alter access.

Item	What to compare before and after
User ID	Same internal application identity
Files	Ownership, sharing, and read/write access
Chats and posts	History and author association
User settings	Preferences and notification settings
Groups	Manual and synchronized memberships
Permissions	Roles, individual grants, and obsolete access
Audit logs	Historical actor linkage and retention

Deletion and recreation can break these relationships. Check exports, backups, recovery capabilities, and ownership-transfer procedures before enabling destructive operations. Never promise that all permissions or historical data will survive automatically.

Implementation risks

Area	Check or mitigation
Existing-account matching	Validate unique searchable values against original target IDs
Duplicate accounts	Inspect create/update events and JIT interactions
Attribute overwrites	Define the authoritative owner, mappings, and null-value behavior
Existing permissions	Test role or license changes and removal of old privileges
Group synchronization	Test membership removal and conflicts with manual administration
Out-of-scope users	Test what happens when assignments or scoping filters change
Administrator protection	Protect emergency access from unintended bulk disablement
SSO identifier alignment	Ensure authentication and provisioning resolve the same account
Licensing	Verify feature and API access requirements on both sides
Synchronization timing	Measure initial and incremental runs, retries, and offboarding delays
Session revocation	Test browser, mobile, and long-lived sessions after disablement
API tokens	Secure and rotate connector credentials; separately handle users’ personal tokens
Product differences	Confirm PATCH, groups, deletion, recovery, and audit capabilities

Recommended rollout

Confirm support. Check resources, operations, network connectivity, licensing, and connector credentials.
Inventory accounts. Include administrators, dormant users, guests, and service accounts.
Design attributes and matching. Establish authority, uniqueness, and rename/rehire rules.
Review mappings. Check create-only versus ongoing updates, transformations, and empty values.
Test disablement and deletion. Include unassignment, scope changes, departures, and restoration.
Prepare emergency access. Protect and test a recovery route independent of the failing sign-in or sync path.
Pilot a small population. Cover existing accounts, new users, renames, disablement, and any JIT interaction.
Verify data and permissions. Compare internal IDs, files, history, memberships, grants, and audit records.
Expand gradually. Review changes and failures before adding more users or departments.
Operate and monitor. Watch credential expiry, failed jobs, unexpected bulk changes, and account drift.

Stopping synchronization does not undo completed writes. Establish restoration procedures and understand recovery limits before expanding scope.

Example: Microsoft Entra on-demand provisioning

On-demand provisioning is a Microsoft product capability rather than a feature of the SCIM standard. For a supported application, configure provisioning on the enterprise application in the Entra admin center, then select a test user through on-demand provisioning and run the operation.

For an existing portal user, inspect import, scope evaluation, matching, and export results. Confirm an update to the existing target ID rather than a new account. This performs real writes: limit the selected users and mapped attributes accordingly.

A successful on-demand operation does not replace testing scheduled runs, group behavior, or offboarding. Review current feature requirements and limitations in the official documentation and the target connector’s guide.

Troubleshooting

Symptom	Start by checking
Duplicate user	Matching values, missing attributes, supported filters, JIT races
No updates	Assignment, scope, mappings, last successful run, provisioning logs
HTTP 401 or 403	Expired credentials, permissions, tenant, endpoint
HTTP 409 or validation failure	Uniqueness conflicts, required attributes, target constraints
Wrong groups or permissions	Group support, manual changes, application role mapping
Former employee still has access	Target disablement, sessions, alternate logins, personal tokens
Unexpected bulk changes	Source data, scoping, transformations; pause expansion and assess impact

Logs may contain personal information or credentials. Share only what is needed for diagnosis and redact secrets.

Summary

SCIM helps automate account management. In an established SSO environment, begin with matching, attribute ownership, and disablement behavior. Prove that existing users retain the intended account, data, and access before widening the deployment.

For related infrastructure planning, see retiring on-premises Active Directory.