Joiners, Movers, and Leavers

What Joiners, Movers, and Leavers Means in Practice

Joiners, movers, and leavers is the identity operations lifecycle that turns access governance into a repeatable business process. It covers the point where a person enters the organisation, changes role, or exits, and it exists to keep entitlements aligned with current need rather than historical access.

In practice, JML is less about a single event than about continuity of control. A joiner workflow establishes the right starting access, a mover workflow adjusts access when responsibilities change, and a leaver workflow removes access and related access paths when the relationship ends.

Why JML Matters for Access Governance

JML is one of the main ways organisations prevent privilege creep, orphaned accounts, and role mismatch from accumulating over time. Without a defined lifecycle, access decisions become inconsistent, approvals are hard to audit, and ownership of accounts or entitlements becomes unclear.

The term matters because access is rarely static. People move between teams, gain temporary duties, take on higher privilege, or leave with active sessions, tokens, keys, or delegated access still in place. A strong JML model keeps those transitions tied to an authoritative source of change, usually HR or another trusted business record.

Good JML also helps distinguish provisioning from governance. Provisioning grants access, but governance decides whether that access still fits the person’s current role, risk, and business need. That is why JML is often the operational backbone of identity governance rather than just an onboarding checklist.

Common Failure Modes in JML Programs

The most common failure is lag, where access changes happen after the business event rather than alongside it. That creates a window where former access remains usable, or where a mover keeps both old and new access, which is a classic source of excess privilege.

Another failure mode is partial deprovisioning. Organisations may disable a primary account but overlook SaaS apps, cloud consoles, API credentials, shared mailboxes, or connected tools that still retain access. In mature environments, JML has to account for the full set of access-bearing relationships, not only the login account.

JML can also fail when ownership is weak. If no one is accountable for reviewing joiner, mover, and leaver state, exceptions become permanent. That is how temporary access becomes standing access, and why orphaned accounts often persist after the original business need has disappeared.

How JML Connects to Identity Lifecycle Controls

JML sits at the centre of identity lifecycle management because it links business events to access decisions. It relies on authoritative data, entitlement models, access review, and timely revocation so that lifecycle changes are reflected consistently across systems.

It also stretches beyond simple user administration. A mover can trigger role recalculation, a joiner can require birthright access with constraints, and a leaver may require revocation of sessions, secrets, or delegated access before account closure is complete. That is why JML is often treated as a governance control as much as an operational one.

For related guidance on the broader lifecycle model, see Joiner-Mover-Leaver (JML) Guide and IAM and IGA Basics, which place JML inside the wider governance and entitlement framework.

Where JML Is Most Important

JML becomes especially important where access changes are frequent, regulated, or high impact. Environments with contractors, privileged users, shared admin tools, or machine and service access need stronger lifecycle discipline because role changes can leave behind access that is not visible in a simple directory record.

The control also matters when organisations depend on multiple systems for identity, such as HR, IAM, SaaS platforms, and cloud services. If lifecycle triggers are not synchronised across those layers, the organisation can end up with mismatched identity state, delayed offboarding, or inconsistent access review results.

For practical policy design, the Access Control Policy Template shows how joiners and leavers fit into least privilege, review cadence, and access control policy structure. For operational offboarding detail, Employee Offboarding Security Guide covers the leaver side of the lifecycle in more concrete terms.

Risk and Threat Considerations

JML failures create a direct path to excess privilege, unauthorized access, and persistent account exposure. The risk is not limited to people leaving the organisation, because movers can also inherit old entitlements that no longer fit their role, creating a quiet but durable access mismatch.

Failure mechanism: Delayed or incomplete lifecycle updates leave active accounts, sessions, or credentials in place after the business event has already changed the access decision.

Impact: Attackers, insiders, or former users can exploit stale access to reach systems, move laterally, or retain access that should have been removed, increasing the chance of data exposure and privilege abuse.

Practitioner Guidance

Governance implication: Treat JML as a cross-functional control owned jointly by identity, security, and the business process that creates the change. The most common mistake is to view it as a help desk task, when it is actually a lifecycle control that depends on timely triggers, clear accountability, and exception handling.

What to watch for: Pay attention to delayed terminations, role-change exceptions, orphaned accounts, and recurring manual overrides, because those are the signs that the lifecycle process is drifting away from the real business state.

Related resources from NHI Mgmt Group

• How should security teams govern NHI access across joiners, movers, and leavers?
• How should security teams automate access changes for joiners, movers, and leavers?
• Who should own lifecycle workflows across joiners, movers, and leavers?
• Why do movers create more identity governance risk than joiners and leavers?