Provisioning and deprovisioning become uneven, which increases role drift, orphaned accounts, and delayed access removal. If one system reacts to lifecycle change faster than another, the identity estate stops behaving as a single governed model. Shared JML processing is what keeps access state aligned.
Where Shared JML Breaks Down Across Identity Systems
Joiner-mover-leaver processing is a lifecycle control, not just an onboarding workflow. When it is fragmented, each identity system starts making its own version of the same access decision, so provisioning, role changes, and removals stop lining up. That creates different access states for the same person or account depending on which system is consulted, which is how drift begins.
In practice, the failure is usually not a single bad record. It is a mismatch in timing, ownership, and policy enforcement between HR-driven events, directory updates, SaaS provisioning, and privileged access processes. A shared JML model keeps those changes synchronized; without it, the estate behaves like several partial systems rather than one governed identity lifecycle. For a practical lifecycle reference, see the Joiner-Mover-Leaver (JML) Guide.
A second breakage is that exceptions become invisible. One platform may provision immediately, another may wait for a manual queue, and a third may not receive the event at all. That is where role creep, stale entitlements, and orphaned accounts accumulate, because the control is no longer operating as a single end-to-end process. Shared lifecycle handling is the difference between consistent access state and policy drift.
Why Orphaned Access and Role Drift Follow Uneven Deprovisioning
The biggest downstream problem is not merely slower cleanup, but incomplete cleanup. If one system removes access quickly while another preserves it, leavers can retain usable paths in applications, VPNs, SaaS platforms, or privileged tools long after employment or role change should have cut them off. The same pattern also affects movers, where old access remains attached to a new role and becomes excess privilege.
That is why joiner-mover-leaver design has to cover more than user accounts. It must include entitlements, group membership, role assignment, token or credential revocation where relevant, and any downstream system that copies access state instead of querying a source of truth. The operational symptom is not just delay, it is inconsistency, with some systems enforcing current status and others still trusting the old one. The IAM and IGA Basics guide is useful here because it frames provisioning and access governance as one model rather than separate tasks.
Shared JML also matters because identity systems often have different sync intervals, approval rules, and deprovisioning triggers. If those rules are not harmonized, a mover can be removed from one role path but remain eligible through another, or a leaver can lose access in the directory while retaining a direct grant in a SaaS app. That is how orphaned accounts persist even when a team believes offboarding is complete. The issue is not only missing revocation, but inconsistent revocation semantics across systems.
What Practitioners Should Verify in a Shared Lifecycle Model
A shared JML model should be treated as a control boundary, not a convenience feature. If it is working, one lifecycle event should produce a predictable result across every connected identity system, with clear ownership for what is automated, what is manual, and what is reconciled later. A useful check is whether the authoritative event source, usually HR or a workforce system, can be traced to a completed access change in each downstream system without ambiguity.
Practitioners should verify three things first: that every system consuming identity events is on the same lifecycle path, that deprovisioning is actually revoking access rather than only disabling a record, and that reconciliation catches accounts that were missed or delayed. Where the environment includes service accounts, workloads, or other non-human identities, the same lifecycle logic must also cover credentials and ownership, because otherwise the human offboarding process can be clean while machine access remains live. A broader lifecycle reference is the NHI Lifecycle Management Guide, which shows how lifecycle consistency extends to non-human access as well.
The other verification point is whether the process fails safe. If a feed is interrupted, a connector breaks, or a downstream app rejects an update, the control should surface the exception quickly instead of silently leaving stale access in place. That is the practical test of shared JML maturity: not whether provisioning succeeds in the happy path, but whether the estate converges back to one current access state after failures. The SCIM and Automated Provisioning Guide is a useful implementation reference for that synchronization problem.
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 sets 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 | JML breaks credential and authenticator lifecycle consistency across systems. |
| AC-2 — Account Management | Shared JML directly governs account provisioning and deprovisioning across platforms. | |
| AC-6 — Least Privilege | Uneven mover handling causes stale access and privilege creep. | |
| Recommendation — Revoke and replace credentials promptly when lifecycle events change access. Synchronize account lifecycle actions across authoritative and downstream systems. Remove obsolete entitlements as soon as role changes take effect. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Shared JML is an identity governance requirement for consistent lifecycle state. |
| A.5.18 — Access rights | Deprovisioning failures leave outdated access rights active after lifecycle change. | |
| Recommendation — Centralize identity lifecycle ownership and enforce consistent updates. Review and revoke access rights when joiner, mover, or leaver status changes. | ||
Practitioner Guidance
What to prioritise: Start with the systems that create the widest blast radius, typically HR-to-directory-to-core SaaS and any privileged access path. If those are not synchronized, every downstream system becomes a separate cleanup problem.
Decision rule: If an identity change can affect production access, treat any disconnected JML flow as a control gap, not an integration inconvenience. The question is whether access state converges everywhere it matters, not whether one platform shows the right status.
What good looks like: A mover should lose obsolete access and gain new access on the same lifecycle event, while a leaver should have all reachable access paths removed or invalidated within the expected operational window. If that is not observable, the process is not truly shared.
Practitioner takeaway: Shared JML is what prevents identity systems from drifting into contradictory access truths; without it, cleanup becomes partial, delayed, and hard to prove.
Related resources from NHI Mgmt Group
- What breaks when identity detection does not see joiner, mover, and leaver state?
- What breaks when identity platforms handle joiner and leaver events well but mover events poorly?
- What breaks when identity systems cannot interoperate across clouds?
- What breaks when privileged credentials are shared across multiple systems?