Joiner, Mover And Leaver Process

What the JML process actually governs

The joiner, mover and leaver process is the identity lifecycle control that keeps access aligned to an employee’s current status. It is not just onboarding and offboarding, it also covers role changes, transfers, contract changes and the access decisions that follow from them.

Its purpose is to keep identity records, entitlements and account state synchronised with real-world employment changes so that access is created, adjusted or removed at the right time. When it works well, it reduces access creep, prevents old-role permissions from lingering and makes later review much easier.

Why JML matters for security and governance

JML is one of the most important controls for limiting privilege drift because people often accumulate access over time. If movers keep both old and new entitlements, or if leavers remain active in systems after departure, organisations inherit unnecessary exposure and weaker auditability.

The control matters across IAM, access governance and recertification because it shapes the actual entitlement baseline, not just the initial account setup. A strong JML process also helps distinguish ordinary role change from exception handling, which is where many access-control failures begin.

How JML connects to provisioning and deprovisioning

In practice, JML sits between HR events, identity governance and downstream system provisioning. Joiners need the right birthright access, movers need access recalculated against the new role, and leavers need accounts, sessions and linked access paths removed or disabled in a controlled sequence.

Automated provisioning improves consistency, but the process still depends on accurate source data, clear ownership and complete coverage across systems. If one application is not connected to the lifecycle workflow, it can become a blind spot where stale access survives outside normal review.

For a deeper lifecycle view, the Joiner-Mover-Leaver (JML) Guide shows how organisations automate role changes, remove old-role access and revoke what leavers leave behind.

Common failure modes in JML execution

JML failures usually show up as delayed deprovisioning, incomplete transfer handling, orphaned accounts, excessive access after a role change or access recertification that never catches up. The most damaging cases are often quiet, because the identity still appears valid even when the person no longer needs it.

These failures are especially dangerous when access is tied to privileged systems, shared tooling or long-lived credentials. If the leaver process misses keys, tokens, service access or delegated permissions, the risk extends beyond a single account to the wider trust chain.

Risk and Threat Considerations

JML failures create a direct path to excessive access, orphaned accounts and privilege persistence after role change or departure. That exposure matters because attackers and insiders can exploit stale access long after the business believes it has been removed.

Failure mechanism: If account removal, entitlement updates or credential revocation lag behind the real-world lifecycle event, an identity can retain access that no longer matches its owner’s authority.

Impact: The result can be unauthorised access, audit findings, lateral movement, data exposure or abuse of lingering privileges tied to old roles, old sessions or forgotten accounts.

Practitioner Guidance

Why practitioners should care: Treat JML as an identity governance workflow, not a helpdesk task. The quality of the process is measured by how quickly and completely it removes mismatched access, especially after transfers and departures.

What to watch for: Pay attention to exceptions that bypass the normal lifecycle path, systems that are not integrated with authoritative sources, and leaver steps that stop at account disablement without confirming downstream access removal. Those are the conditions where drift tends to accumulate.

Practitioner takeaway: The strongest JML programmes are the ones that make entitlement change the default outcome of a lifecycle event, not a manual follow-up after the fact.

Related resources from NHI Mgmt Group

• What breaks when deprovisioning is not tied to the joiner-mover-leaver process?
• What happens when access certifications are not tied to a clear joiner mover leaver process?
• What breaks when a user lifecycle platform does not match the real joiner-mover-leaver process?
• Joiner-Mover-Leaver Process