SCIM vs JIT Provisioning: Gaps and Which to Use

Just-in-time provisioning makes it easy to give people an account in a SaaS app, but it does almost nothing when they leave, so the account, its API tokens and its SSH keys can outlive the person's access in the identity provider. SCIM and JIT both create accounts in a downstream application from an identity provider (IdP), yet they work on opposite triggers: SCIM pushes changes from the IdP whenever they happen, while JIT creates or updates an account only when the user signs in. That difference decides whether a leaver is removed in minutes or remains active until someone notices. This guide compares the two for workforce SaaS and internal applications, shows where the deprovisioning gaps sit, gives a decision table and a migration path from JIT to SCIM, and lists what to monitor. It is for IAM engineers, application owners and identity governance teams. Example platforms are listed alphabetically. For SCIM mechanics in depth see the SCIM Provisioning Guide.

Key takeaways

JIT is a sign-in event, not a lifecycle. An account is created or updated when a SAML or OpenID Connect sign-in arrives; nothing reaches the application when the user is disabled, moved or deleted in the IdP.
SCIM closes the leaver gap. The IdP sends a PATCH setting active to false, or a DELETE, so the account is suspended in the application without anyone signing in.
SSO removal is not account removal. GitHub Enterprise Server documents that a user removed from the IdP under JIT can continue to authenticate with access tokens or SSH keys until an admin suspends the account.
Use both where you can. Many teams keep JIT as a safety net for attribute refresh at sign-in and use SCIM as the authoritative create, update and disable channel.
Where only JIT exists, compensate. Short app session lifetimes, scheduled reconciliation against the IdP, and a leaver runbook step per JIT app are the minimum.

What each one actually is

SCIM (System for Cross-domain Identity Management) is an IETF standard: RFC 7643 defines the core schema (User, Group, the enterprise user extension) and RFC 7644 defines the REST protocol, both Standards Track and published in September 2015. The IdP acts as the SCIM client and calls the application's SCIM endpoint over TLS, normally with an OAuth 2.0 bearer token, to create users (POST), change them (PUT or PATCH), suspend them (PATCH active=false) and delete them (DELETE). RFC 7644 section 3.6 says that after a successful DELETE the server must return 404 for that resource and leave it out of future query results.

JIT (just-in-time) provisioning is a pattern, not a standard. When a user signs in through SAML 2.0 or OpenID Connect and the application does not recognise them, it creates a local account from the attributes in the assertion or ID token (email, name, groups, roles). Some applications also update attributes and group-based roles at each later sign-in. The application learns about the user only at the moment of sign-in, so it learns nothing while the user stays away.

Both rely on single sign-on for authentication. The difference is the lifecycle channel: SCIM is a push channel from the source of truth, JIT is a side effect of authentication.

Side-by-side comparison

Dimension	SCIM provisioning	JIT provisioning
Trigger	Change in the IdP (assignment, attribute change, disable, delete)	User signs in to the application
Standard	RFC 7643 schema and RFC 7644 protocol	No standard; behaviour defined per application on top of SAML or OIDC
Account creation	Before first use, so access can be prepared and reviewed	At first sign-in
Attribute and role updates	Pushed on change, in the next provisioning cycle	Only at next sign-in, if the application supports update on login
Deprovisioning	Suspend (`active=false`) or DELETE sent automatically	None; requires manual action or a separate process
Local credentials (API tokens, SSH keys, app passwords)	Typically blocked once the account is suspended (confirm per application)	Keep working after IdP removal until the account is suspended
Group push	Groups and memberships can be provisioned as resources	Groups only as claims in the assertion at sign-in
Integration identity	A SCIM bearer token or OAuth client, a powerful non-human identity	None beyond the SSO trust (signing certificate)
Setup effort	Higher: endpoint, token, attribute mapping, scoping, testing	Low: enable on the SSO connection
Licence and seat use	Seats used from provisioning, reclaimed on disable	Seats used only by people who actually sign in, rarely reclaimed
Audit evidence	Provisioning logs on both sides	Sign-in logs only; no record of intended state

Where the deprovisioning gaps sit

The leaver case is where the two models diverge most. In Microsoft Entra ID, when a user who was in scope is unassigned, disabled or soft-deleted in the source, the provisioning service disables the user in the target with an update (for SCIM applications, a request setting active to false), and sends a DELETE when the user is permanently deleted from the tenant 30 days later. Okta's SCIM documentation describes the same pattern: deprovisioning a user in Okta updates the SCIM resource with active=false. Under JIT none of this happens.

Gap 1, long-lived local credentials: applications that issue their own tokens do not check the IdP on every request. GitHub Enterprise Server states that if you remove a user from your IdP you must also manually suspend the account, otherwise the owner can continue to authenticate using access tokens or SSH keys. The same applies to API tokens and app passwords in many SaaS products. See the Employee Offboarding Security Guide.
Gap 2, live sessions: blocking SSO stops new sign-ins, but the application session already issued stays valid until it expires. With JIT there is no event to end it; some SCIM implementations also end sessions on suspension, so test this per application. See the Global Token Revocation Guide.
Gap 3, local login paths: if the application still allows username and password or a break-glass local login, an account created by JIT can be used without the IdP at all.
Gap 4, stale roles for movers: JIT updates roles only at sign-in, and some applications only add roles from claims and never remove them. A mover keeps old privileges until they sign in again, or forever.
Gap 5, invisible accounts: with JIT there is no record in the IdP of which applications hold an account for a person, so access reviews and leaver checks cannot be complete.

The lesson extends beyond accounts. The Coupang breach involved signing keys held by a departed engineer that were never revoked or rotated: removing the person from the directory did not remove what they held. A leaver process has to cover every credential tied to the person, which is easier when the application account is suspended by SCIM rather than left for someone to remember. The Leaver Retained Access Incident Playbook covers response when this goes wrong.

Which to use: decision table

Situation	Recommended approach	Why
Application holds sensitive data, source code, finance or customer records	SCIM, with SSO enforced and local login off	Leaver suspension must not depend on a person remembering
Application issues long-lived API tokens, SSH keys or app passwords	SCIM, and confirm that suspension invalidates those credentials	These credentials bypass SSO after removal
Application supports SCIM and JIT	SCIM as the lifecycle channel; JIT on or off by policy	JIT can refresh attributes at sign-in but must not be the only path
Low-risk, read-only tool with short sessions and no local credentials	JIT is acceptable with quarterly reconciliation	Exposure after leaving is limited to session lifetime
Large, occasional user base (for example a learning portal)	JIT for creation, scheduled clean-up of inactive accounts	Pre-provisioning everyone wastes seats and creates dormant accounts
Application supports neither	SSO only, plus a manual or API-driven leaver step owned by the application owner	Record it as a risk exception with a review date
Privileged admin roles in the application	SCIM group push for role assignment, or a JIT access tool for elevation	Role removal must happen on mover and leaver, not at next sign-in

Small organisations: start with the five to ten applications that hold the most sensitive data or issue local credentials, and turn on SCIM there first; rely on JIT plus a monthly reconciliation for the rest. Large organisations: make SCIM support a procurement requirement for any application above a set data classification, and track JIT-only applications as exceptions. The Joiner-Mover-Leaver Guide and the Identity Lifecycle Event Design Guide cover the upstream events that feed both models.

Security trade-offs of SCIM

SCIM is not free of risk. It adds a privileged integration identity: the token the IdP uses to call the SCIM endpoint can create users, assign groups and in some applications grant admin roles. Treat it as a high-value non-human identity.

Token scope: where the application allows it, issue a token that can manage users and groups only, not change SSO settings or read data.
Token lifetime and rotation: record the expiry, an owner and a rotation date. Many SCIM tokens are long-lived by design, so rotation must be scheduled. See the NHI lifecycle automation guide.
Admin role assignment by group push: if a group maps to an admin role, whoever can change that group in the IdP becomes an admin in the application. Protect those groups like privileged roles (ATT&CK T1098.003 Additional Cloud Roles describes the attacker side).
Matching errors: the matching attribute (for example userPrincipalName mapped to userName) decides which existing account is updated or disabled. A wrong mapping can link a new joiner to a leaver's old account.
Error states: Microsoft Entra places a provisioning job in quarantine after a high error rate and disables it automatically if it stays quarantined for more than four weeks. A silently stopped job means leavers stop being disabled.

JIT has its own trust risk: the application trusts whatever attributes the IdP signs. If roles come from assertion claims, a forged or mis-issued assertion grants those roles at sign-in. Protecting the federation trust is covered in the Golden SAML and Federation Trust Abuse Defence Guide.

Moving from JIT to SCIM

Inventory JIT applications. List every SSO connection with JIT on, whether SCIM is offered, which local credentials the application issues and who owns it.
Reconcile first. Export the application's accounts and match them to IdP users. Disable or delete accounts with no active IdP match before SCIM goes live, so the first sync does not inherit orphans.
Choose the matching attribute. Use an immutable identifier (an employee ID or the IdP object ID stored as externalId, which RFC 7643 section 3.1 defines as set by the provisioning client) rather than email where the application allows it.
Create a scoped SCIM token. Record owner and expiry, store it only in the IdP connector, and log its use.
Pilot. Microsoft recommends starting automatic provisioning in a test environment with a small subset of users, then widening scope in waves. Test joiner, mover (role change) and leaver (unassign, disable) for pilot users and confirm in the application that tokens and sessions stop working on suspension.
Turn off local login and decide on JIT. Enforce SSO for all non-break-glass users. Keep JIT only if it adds value at sign-in, and never as the creation path for privileged roles.
Roll back safely. If the first full sync misbehaves, pause the provisioning job rather than deleting it, and set the application to disable rather than delete out-of-scope users so mistakes are reversible.

Expect the first cycle to take time: Microsoft documents the initial cycle as anywhere from 20 minutes to several hours depending on directory size, followed by incremental cycles at an interval set per application. For connector errors during rollout see the SCIM Provisioning Errors Troubleshooting Guide.

Detection and measurement

Provisioning logs: monitor failed disable operations and jobs in an error or quarantine state. Microsoft Entra retains most audit data for 30 days, so export provisioning logs to your SIEM if you need longer history.
Leaver activity: alert on any sign-in, API call or SSH use in an application by an identity that is disabled in the IdP (ATT&CK T1078.004 Cloud Accounts covers valid account misuse).
SCIM token use: alert when the SCIM token is used from an address other than the IdP's provisioning service, or creates admin-level users outside a change.
Reconciliation: compare each application's active accounts against IdP assignments on a schedule, monthly for JIT-only applications.

Metric	Target
Share of sensitive applications using SCIM for deprovisioning	100% of applications above your data classification threshold
Median time from IdP disable to application suspension	Within one provisioning cycle for SCIM apps; documented SLA for manual apps
Application accounts with no matching active IdP user (orphans)	Zero after each reconciliation
JIT-only applications with a recorded risk exception and owner	100%
SCIM tokens with owner, expiry and rotation date recorded	100%
Provisioning jobs in error or quarantine for more than 24 hours	Zero

Common failure patterns

Treating SSO removal as offboarding. The IdP account is disabled, but the application account and its tokens remain active because only JIT was configured.
Local login left on. Users created by JIT also set a local password, which keeps working after SSO is blocked.
SCIM job silently stopped. An expired SCIM token or a quarantined job means leavers stop being processed and nobody is alerted.
Delete instead of disable on day one. A wrong scoping filter in the first sync removes hundreds of accounts and their data in the application.
Roles only ever added. JIT or SCIM mappings grant roles from groups but never remove them on mover events, so privilege accumulates.
Personal credentials forgotten. Keys and tokens the person created outside the application account, as in the Coupang case above, are not part of the leaver checklist.

Framework mapping

Framework	Reference	How SCIM and JIT relate
NIST SP 800-53 Rev 5	AC-2 Account Management; AC-2(1) Automated System Account Management; AC-2(3) Disable Accounts	SCIM provides automated account management and disabling; JIT alone does not meet AC-2(3) for leavers
NIST CSF 2.0	PR.AA-01; PR.AA-05	Identities managed by the organisation; access reviewed and least privilege kept for movers
CIS Controls v8.1	Safeguards 5.3 Disable Dormant Accounts; 6.1 Establish an Access Granting Process; 6.2 Establish an Access Revoking Process	SCIM automates granting and revoking; JIT applications need reconciliation for 5.3
ISO/IEC 27001:2022 Annex A	A.5.16 Identity management; A.5.18 Access rights	Provisioning and removal of access rights across the identity lifecycle
MITRE ATT&CK v20	T1078.004 Cloud Accounts; T1098.003 Additional Cloud Roles	Leaver accounts reused; roles granted through group or claim manipulation

Practitioner checklist

List every SSO application with JIT enabled and record whether it supports SCIM.
Turn on SCIM deprovisioning for every application that holds sensitive data or issues local credentials.
Confirm per application that suspension blocks API tokens, SSH keys, app passwords and live sessions.
Disable local username and password login for all users except documented break-glass accounts.
Use an immutable matching attribute and set out-of-scope users to disable, not delete.
Give every SCIM token an owner, a scope, an expiry and a rotation date.
Alert on provisioning jobs in error or quarantine and on activity by IdP-disabled users.
Reconcile JIT-only applications against the IdP at least monthly and record them as risk exceptions.
Add a leaver step for every application that cannot be deprovisioned automatically.

Worked scenarios

The scenarios below are illustrative examples, not real incidents.

SCIM scenario: a leaver in a code hosting platform. A developer resigns on a Friday and is disabled in the IdP that afternoon. The code hosting platform is connected through SCIM, so the IdP sends a PATCH setting active to false within the next provisioning cycle. The account is suspended before Monday, and the personal access tokens and SSH keys tied to it stop working with it. The weekly reconciliation report shows no active accounts without a matching enabled IdP user.

JIT scenario: a wiki tool with no SCIM support. A team uses a hosted wiki that supports SAML sign-in with JIT account creation but has no SCIM endpoint. A contractor leaves and is removed from the IdP, so SSO sign-in fails, but the wiki account and an API token the contractor created stay active. The quarterly reconciliation against the IdP export finds the orphaned account. The team adds the wiki to its leaver runbook as a manual step, shortens the session lifetime, and schedules a monthly export comparison until the vendor ships SCIM.

SCIM vs JIT Provisioning: Deprovisioning Gaps and Which to Use