Joiner-mover-leaver, usually shortened to JML, is the model for managing someone's access across the whole time they are at a company. Three stages: they join, their role changes, they leave. Each stage should change their access to match, automatically, across every system.
The model is old and the stages are obvious. What is not obvious is that most companies do the first and last stages by hand and skip the middle one entirely.
The three stages
Joiner. A new hire needs access to the apps their role requires, ideally on day one, not after a week of tickets. When this is driven by policy rather than a manual request queue, it is called birthright access: the role maps to a bundle, and the bundle is granted automatically.
Mover. Someone changes team, gets promoted, or shifts function. Their access should change to match. They gain what the new role needs and lose what the old role required. This is the stage that quietly fails. The new access gets added because someone asks for it. The old access almost never gets removed because nobody is watching for it.
Leaver. Someone departs. All access is removed across every system, sessions ended, owned data handled, and the whole thing recorded. This is deprovisioning, and it is the stage where a miss becomes an orphaned account.
Where JML breaks
The joiner and leaver stages are events. Someone starts, someone quits. Events get noticed and get processes built around them.
The mover stage is not an event in the same way. A team change is a quiet administrative update, and the access implications trail behind it. The result is privilege creep: people accumulate access as they move around, and the access from prior roles stacks up. By the time an access review runs, a five-year employee who has changed teams three times is carrying permissions from all three, and nobody can say why they still have most of them.
The trigger problem compounds it. JML runs cleanly when there is one authoritative source firing the stages. The HRIS handles employees. Contractors, service accounts, and other identities that never touch the HRIS have no automatic trigger, so their lifecycle is managed by memory, if at all.
What working JML looks like
The HRIS is the source of truth. A joiner record grants the birthright bundle across every connected app. A department change updates entitlements in both directions, adding the new and stripping the old. A termination date fires deprovisioning everywhere in one sequence. Identities outside the HRIS, contractors and non-human accounts, get an explicit owner and an expiry so they are covered by the same machinery.
The point of JML is that access always reflects the current state of the person, not the sum of everything they have ever been granted. When it works, there is nothing to clean up later, because nothing accumulated.
Related terms
- Birthright access. The joiner stage, done automatically by role.
- Deprovisioning. The leaver stage: removing all access on departure.
- Privilege creep. What the broken mover stage produces over time.
- Identity Governance and Administration (IGA). The wider discipline JML sits inside.