User Provisioning: How Accounts Get Created and Removed

Last updated: August 2026

User provisioning is the process of creating, updating and deactivating user accounts across the applications an organization runs, driven by an authoritative source such as an HR system or identity provider. It covers the whole account lifecycle: an account exists before someone’s first day, changes as they move teams, and is locked the moment they leave.

Most teams do not choose a provisioning strategy. They accumulate one. Someone creates accounts by hand, then a script appears, then SSO arrives and accounts start creating themselves, and nobody notices that nothing removes them.

Key takeaways

• Provisioning is a lifecycle, not a create step. The deactivate half is where the security risk lives.
• Four common approaches: manual, scripted, just-in-time, and SCIM. They differ mainly in whether offboarding is automatic.
• Orphaned accounts, live credentials belonging to people who left, are one of the most common audit findings.
• The trigger to automate is usually enterprise sales, a compliance regime, or per-seat licensing costs, not headcount alone.

What problem is provisioning actually solving?

Three things happen to every employee: they join, they change, they leave. Each one has to be reflected in every system they touch.

Joining is the part everyone handles, because someone complains loudly on day one when they cannot log in. Changing is handled unevenly. Leaving is where it falls apart, because nobody complains. The person is gone. Their account is not.

That leftover account is an orphaned account: a working credential attached to someone who no longer works for you. It shows up in SOC 2 and ISO 27001 audits constantly, and it is exactly what an attacker looks for, because nobody is watching it and nobody will notice the login.

The scale of the problem is what makes manual handling fail. Okta’s Businesses at Work report has put the average company’s app portfolio above 90 applications for several years running (Okta, 2024). Nobody keeps 90 apps in sync by hand.

The four approaches

Manual

An admin creates the account. It works, it needs no engineering, and it is correct until roughly the fortieth employee or the tenth application, whichever comes first.

The failure mode is not the creating. It is that offboarding depends on someone remembering every app a departing person had access to, which is a memory test nobody passes reliably.

Scripted

A script or workflow calls each application’s API. This automates the work but not the integration problem: every app has a different API, a different auth scheme, and a different idea of what a user is. You now own N integrations and their breakages.

Scripts also tend to be written for onboarding and extended to offboarding later, or never.

Just-in-time (JIT)

The application creates the account automatically at the user’s first SSO login, using attributes from the SAML assertion or OIDC token. No endpoint, no token, no sync engine. It is genuinely the cheapest thing that works.

The catch is structural: JIT has no offboarding mechanism at all. A departed employee simply never logs in again while their account sits there, active. JIT can create accounts and it cannot remove them, because removal is not a login event.

SCIM

The identity provider pushes changes to a standard REST endpoint as directory data changes. It handles the full lifecycle including deactivation, and because it is a standard, one implementation works with every compliant identity provider rather than one per vendor.

This is what enterprise buyers mean when they ask for “provisioning”. For the protocol detail, see what SCIM is and why it matters.

Provisioning is not authentication

These get conflated constantly, and the distinction is worth holding.

Authentication answers “is this person who they claim to be?” at login. Provisioning answers “should this person have an account here at all, and in what state?” continuously.

SSO without provisioning means accounts either get made by hand or spring into existence at first login, and nothing cleans them up. Provisioning without SSO means accounts are perfectly synchronized but everyone still juggles passwords. Mature stacks run both, which is why enterprise checklists ask for both. We covered the split in detail in SCIM vs SAML.

How Okta, Entra ID and the rest do it

The major identity providers all implement SCIM the same basic way. You give them a base URL and a credential, and they push changes on their own schedule.

Okta calls it Lifecycle Management and pushes changes as they happen. Assign a user to the app and Okta sends POST /Users within moments; suspend them and the PATCH follows (Okta developer docs, 2026). Okta also distinguishes profile sourcing from provisioning, which matters if you have more than one authoritative system.

Microsoft Entra ID runs provisioning cycles on a fixed interval, roughly every 40 minutes, comparing assigned users against the app and pushing creates, updates and deactivations (Microsoft Learn, 2026). It is reconciliation-based rather than event-based, so changes are not instant.

That difference is worth knowing before you promise anyone real-time deprovisioning. With Entra, “immediate” means within the cycle.

One convention holds across all of them: deactivate, do not delete. Offboarding is a single request that flips one field:

PATCH /scim/v2/Users/2819c223-7f76-453a-919d-413861904646
Content-Type: application/scim+json

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    { "op": "replace", "path": "active", "value": false }
  ]
}

That is the entire offboarding story, and it preserves the audit trail in a way DELETE would not. Whatever sits on the receiving end must treat a deactivated account as fully locked out: sessions invalidated, tokens revoked, logins refused. An account marked inactive that still holds a live session has not been deprovisioned in any sense an auditor accepts. If you are implementing that side, see building and testing a SCIM API.

When does it stop being optional?

Not at a headcount. The triggers are usually these:

• You are selling to enterprises. Procurement asks for provisioning by name, and increasingly treats automated deprovisioning as a security control rather than a feature.
• You are in a compliance regime. SOC 2 and ISO 27001 auditors ask how access is revoked. “A person does it” is an answer, but a weak one that fails the first time someone forgets.
• Access costs money. Per-seat licensing turns every orphaned account into a recurring line item.
• Headcount churns. Contractors, seasonal staff and reorgs generate lifecycle events faster than tickets get processed.

If none of those apply, JIT plus a quarterly access review is a defensible position. Just be aware that SCIM is the harder retrofit of the two, because by the time you add it you have a pile of existing accounts to reconcile against the directory.

Provisioning in Keycloak

Keycloak sits on both sides of this, which is a common source of confusion.

Reading your directory. If Active Directory or OpenLDAP is your source of truth, Keycloak federates it directly through user federation rather than SCIM. Users live in LDAP and Keycloak reads them, optionally importing a local copy. That is covered in the Keycloak LDAP integration guide, and for stores that are not LDAP you can implement a custom user federation provider.

Being provisioned into. If a cloud identity provider needs to push users into Keycloak, that is SCIM. For most of Keycloak’s history there was no SCIM support at all and teams used community extensions. Recent releases add a native SCIM 2.0 server as an experimental feature behind a flag, covering core user and group operations rather than the full protocol surface. Check the Keycloak supported features list for current status before building on it.

Skycloak ships SCIM 2.0 provisioning as a supported feature on managed Keycloak, with the setup walked through in using SCIM 2.0 with Skycloak.

Frequently asked questions

What is the difference between user provisioning and identity management?

Provisioning is one part of identity management. Identity management covers authentication, authorization, directory data and governance; provisioning is specifically the account lifecycle across applications.

Is JIT provisioning good enough?

For internal tools with low churn and no compliance requirement, often yes. It fails the moment you need to prove access was revoked, because JIT has no revocation path at all.

What is deprovisioning?

Removing or disabling access when someone leaves or changes role. In practice it means setting the account inactive rather than deleting it, so the audit trail survives.

Do I need SCIM if I already have SSO?

SSO does not remove access when someone leaves; it only controls login for people who still have accounts. If nothing else deactivates accounts, SSO alone leaves orphans.

Can I provision users into Keycloak?

Yes, two ways. Federate an existing LDAP or Active Directory so Keycloak reads it, or accept SCIM pushes from a cloud identity provider. The SCIM server in Keycloak is currently an experimental feature.

How fast is deprovisioning in practice?

Depends on the identity provider. Okta pushes on change, so effectively immediate. Entra ID reconciles on a cycle of roughly 40 minutes, so “immediate” is really “within the hour”. Promise accordingly.

The short version

Provisioning is the account lifecycle, and the half that matters is the half nobody notices: the accounts that should stop existing.

If you are building the receiving end of this, our free SCIM Endpoint Tester fires live requests at your endpoint from the browser so you can see exactly what an identity provider will get back.

Want SSO and provisioning handled without maintaining the plumbing? See Skycloak pricing.