Why do provisioning differences create access risk across IdPs?

Provisioning differences create risk because the same lifecycle event can create, update, or remove accounts inconsistently across systems. When joiner-mover-leaver flows are not normalised, some users are provisioned too broadly, while others are not deprovisioned quickly enough, which leaves access states misaligned with policy.

Why provisioning differences turn lifecycle events into access drift

Provisioning differences matter because an identical joiner, mover, or leaver event can produce different outcomes in each identity provider. One system may create an account, another may only update attributes, and a third may leave the old state in place. That divergence turns a routine lifecycle change into access drift, where policy and reality no longer match.

In practice, the risk is not the existence of multiple IdPs by itself, but inconsistent handling of the same authoritative event. If one system treats a role change as a full re-provision while another treats it as a partial update, entitlement state becomes fragmented. Over time, that fragmentation makes it harder to know who should have access, who still does, and which system is authoritative for removal.

This is why normalisation matters across IAM and IGA Basics and the Joiner-Mover-Leaver (JML) Guide: the lifecycle decision should be consistent even when the target platforms are not. When provisioning rules differ, access becomes an implementation detail instead of a governed outcome.

Where IdP differences usually show up

The most common breakpoints are account creation, attribute updates, entitlements, and removal. Some IdPs expect a source-of-truth feed to create the account immediately, while others wait for a first sign-in or require a separate app assignment. In a heterogeneous environment, those different defaults can produce overprovisioning in one place and underprovisioning in another.

Differences also appear in how group membership, role mapping, and deprovisioning are interpreted. A mover event may remove a user from one role hierarchy but leave inherited access behind in another system. A leaver event may disable the primary directory account but fail to revoke linked application access, tokens, or delegated permissions.

For a broader operational view, Identity Provider and SSO Security Guide is useful because it shows how federation, tokens, and recovery paths can preserve access even after the main identity change. If provisioning logic is not aligned, those preserved paths become unintended standing access.

Why inconsistent provisioning creates security exposure

Provisioning differences create two opposite failure modes. Overprovisioning gives a user access that the policy did not intend, often because one system applies birthright access, legacy role logic, or delayed reconciliation. Slow deprovisioning creates stale access, which is especially dangerous when the former user, contractor, or service account can still reach sensitive systems after the business thinks access has ended.

The exposure is amplified when the same person has multiple identities across directories, SaaS tools, and internal apps. One account may be removed cleanly while another remains active, creating a hidden path for reuse, impersonation, or simple policy bypass. That is why lifecycle control, not just authentication, is central to the risk.

Access Reviews and Certification Guide and Role Mining and Role Design Guide both matter here because they address the downstream symptoms, review fatigue, role sprawl, and inconsistent entitlement models that make provisioning drift hard to see until after an access incident.

Risk and Threat Considerations

Provisioning drift becomes a real security problem when inconsistent lifecycle handling leaves privileged, stale, or orphaned access in place. The longer the mismatch persists, the more likely it is that a former role, a stale entitlement, or an abandoned account can be used in an unauthorized way, whether by mistake, abuse, or compromise.

Failure mechanism: Different IdPs and connected apps interpret the same lifecycle trigger differently, so create, update, disable, and delete actions do not complete as one coherent control. That leaves access paths that policy assumes were removed, but that still function in at least one system.

Impact: Attackers and insiders can exploit the gap for unauthorized access, privilege retention, lateral movement, or re-entry through an unrevoked account path. Even without active abuse, the organisation carries an ongoing audit and governance problem because the actual access state can no longer be trusted.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Lifecycle drift often persists through stale credentials and tokens.
	AC-2 — Account Management	Provisioning differences are fundamentally account lifecycle failures across systems.
	AC-6 — Least Privilege	Overprovisioning across IdPs directly violates minimum-access expectations.
Recommendation — Revoke and rotate authenticators when lifecycle events change or end access. Centralise account lifecycle rules so creation, change, and removal are consistent. Limit entitlements to the minimum needed and remove excess during lifecycle events.
CIS Controls v8	CIS-5 — Account Management	The issue is inconsistent account provisioning and deprovisioning across systems.
Recommendation — Standardise account provisioning and removal across directories and SaaS apps.
ISO/IEC 27001:2022	A.5.16 — Identity management	Identity lifecycle governance is central when IdPs diverge on account state.
Recommendation — Maintain a single governed identity lifecycle with defined ownership and approvals.

Practitioner Guidance

What to prioritise: Define the lifecycle event as the control point, not the target application. The cleanest fix is usually a single authoritative joiner, mover, leaver policy with explicit rules for account creation, attribute sync, entitlement changes, and hard deprovisioning across each IdP.

What to verify: Test the same move and leaver cases in every connected system, including secondary directories and apps that cache access or maintain their own groups. Verify that the account state, group state, token state, and application assignment all converge to the intended outcome.

Practitioner takeaway: Provisioning risk is usually a consistency problem before it is an authentication problem, so measure whether every IdP reaches the same end state from the same lifecycle event and treat any exception as a control gap.