The JML cycle: Joiner, Mover, Leaver in depth

The engine underneath the operational cycle

In the operational IAM cycle we saw the six processes that keep an IAM program running, and JML was one of them — described at a glance. This article opens that one box all the way up, because JML is where most of the value, and most of the failures, of an IAM program actually live.

Every other process exists to serve JML. Aggregation and the master record exist so JML knows who changed. Correlation and reconciliation exist so JML knows what accounts to touch. Certification exists to catch what JML missed. If you get JML right, the rest of the program has a fighting chance. If you get it wrong, no amount of dashboards or audits will save you — you’ll be permanently cleaning up after access that no longer matches reality.

So we’re going to go deep: the lifecycle as a state machine, the access model that sits underneath it, each of the three movements in detail (with special attention to the Mover, which is where programs quietly fail), who is responsible for what, how to measure whether it works, and the regulations that make it non-optional.

The identity lifecycle as a state machine

Before the three movements, you need the shape they move through. An identity isn’t simply “active” or “gone.” It passes through a series of well-defined states, and each transition is an event that JML reacts to. Thinking in states is what separates a robust program from one that handles only the happy path.

stateDiagram-v2
  accTitle: The identity lifecycle as a state machine
  accDescr: An identity starts as prospective when a hire is approved, becomes active on the start date via the joiner flow, can re-enter active repeatedly through mover events, can move to suspended during a leave of absence and back to active on return, transitions to terminated on departure via the leaver flow, and from terminated either returns to active on rehire or moves to deleted once the retention period ends.
  [*] --> Prospective: hire approved
  Prospective --> Active: start date (Joiner)
  Active --> Active: role change (Mover)
  Active --> Suspended: leave of absence
  Suspended --> Active: return
  Active --> Terminated: departure (Leaver)
  Terminated --> Active: rehire
  Terminated --> Deleted: retention period ends
  Deleted --> [*]

Reading the diagram: a person becomes Prospective the moment a hire is approved — often days or weeks before they start. On their start date the Joiner flow promotes them to Active. While active they may loop through Mover events many times. A leave of absence parks them in Suspended, a state where access is frozen but not destroyed. Departure fires the Leaver flow into Terminated — but note this is not the end: a rehire can pull them back to Active, and only after a policy-defined retention window does the identity reach Deleted.

The two states people forget are Suspended and the gap between Terminated and Deleted. A program that treats “terminated” as “delete immediately” loses forensic evidence and breaks data ownership; a program with no suspended state either over-revokes during a maternity leave or, worse, leaves full access standing for someone who isn’t there.

The access model underneath JML

JML moves access around, so you can’t reason about it without a model of what kinds of access exist. Modern programs use four, and the art is putting each entitlement in the right bucket.

The distinction matters enormously for JML. Birthright and role-based access are what the Joiner and Mover flows automate — they’re computed from attributes, so the system can grant and retire them without a human. Requestable access is what those flows can’t assume — it needs intent and approval. And JIT is the escape hatch that stops requestable access from becoming permanent debt: instead of granting standing access a future Mover will forget to remove, you grant it for the window it’s needed and let it expire on its own.

Joiner: getting day one right

The Joiner flow has one deceptively hard goal: the new person is productive on their first click, and only with the access their role justifies. Both halves matter. Grant too little and the manager starts filing emergency tickets and the new hire’s first impression is friction; grant too much and you’ve seeded privilege creep before they’ve even logged in.

The three Joiner sub-phases

A mature Joiner flow isn’t a single event — it’s three:

• Pre-hire (pre-staging): the moment the offer is accepted, HRIS creates a Prospective identity. IGA can pre-build accounts in a disabled state, order hardware, and queue training — all before day one, so nothing is created in a rush on the morning itself.
• Day one (activation): on the start date the identity flips to Active, the pre-staged accounts enable, birthright and role-based access apply, and credentials are issued. Because the heavy lifting happened during pre-staging, activation is fast and low-risk.
• Probation / ramp: some access is deliberately deferred — production access, signing authority, sensitive systems — until the person clears probation or completes required training. Encoding this as a scheduled transition, not a manual reminder, is what keeps it from being forgotten.

Birthright by rule, not by copying a colleague

The single worst Joiner anti-pattern is access cloning: “give Sara the same access as Daniel because they’re on the same team.” It feels efficient and it’s a disaster — Daniel has accumulated years of one-off grants, and now Sara inherits all of them on day one. Birthright must be computed from attributes (title, department, location, employment type), not copied from a human who is themselves a pile of historical exceptions.

Provisioning to downstream apps increasingly rides on the SCIM standard (System for Cross-domain Identity Management), which gives IGA a uniform API to create, update, and deactivate accounts across modern SaaS — replacing the brittle per-app connectors of a decade ago.

Mover: the step where programs quietly fail

If you remember one thing from this article, make it this: the Mover is the hardest and most-neglected part of JML, and it’s neglected for a structural reason. When someone moves, granting their new access is visible — they need it, they ask for it, someone celebrates the promotion. Removing the access they no longer need is invisible — nothing breaks when you skip it, nobody complains, and the person keeps working. So it gets skipped. Every time it’s skipped, access accumulates.

The result is privilege creep: a ten-year employee who has rotated through five teams ends up holding the union of all five roles’ access. Nobody ever decided they should have all of it; it’s pure sediment. And it’s not just untidy — overlapping access from different functions is exactly how segregation-of-duties (SoD) violations are born. The person who can both create a vendor and approve its payments wasn’t given that power on purpose; they collected one half in 2021 and the other half in a 2024 transfer.

What a correct Mover actually does

flowchart TB
  accTitle: The Mover decision flow
  accDescr: An HRIS change event for department, manager, or title triggers recalculation of the expected role set. The system compares the new expectation to current access and branches three ways: new roles needed are provisioned, roles no longer justified are retired, and unchanged access is left alone. Newly added access is checked for segregation-of-duties conflicts; a conflict requires an exception or approval, and either way the change is logged and a recertification is scheduled.
  EVENT[HRIS change event<br/>dept / manager / title] --> CALC[Recalculate expected role set]
  CALC --> DIFF{Compare to current access}
  DIFF -->|new roles needed| ADD[Provision new roles]
  DIFF -->|no longer justified| REMOVE[Retire old roles]
  DIFF -->|unchanged| KEEP[Leave as-is]
  ADD --> SOD{SoD conflict?}
  SOD -->|yes| EXC[Require exception + approval]
  SOD -->|no| CERT[Log + schedule recertification]
  EXC --> CERT
  REMOVE --> CERT
  KEEP --> CERT

The critical branch is the middle one — retire old roles — because that’s the one human-driven processes skip. A correct Mover recalculates the entire expected role set from the new attributes and reconciles current access against it in both directions: add what’s missing, remove what’s no longer justified. Adding without removing isn’t a Mover; it’s a second Joiner stacked on top of the first.

The hard Mover cases

Simple lateral moves are easy. The cases that expose a program’s real quality:

Leaver: removing access before it’s a liability

The Leaver flow is where IAM most visibly protects the organization, and where speed is a security property. Every minute a departed person retains access is a minute of exposure — to a disgruntled exit, a compromised personal device, or simply an account nobody is watching anymore.

Graceful vs. immediate departures

Not all leavers are equal, and the flow must distinguish them:

• Planned departure (graceful): resignation or retirement with notice. The Leaver flow can run on the scheduled last day, with mailbox handover and data transfer arranged in advance.
• Immediate departure (urgent): termination for cause, or any situation where access must be cut now. This cannot wait for a nightly batch — it needs a real-time path that disables accounts and kills active sessions within minutes.

A program that only has the graceful path is dangerous: the case where speed matters most is exactly the one it can’t handle.

Disable first, delete later

The most common Leaver mistake is treating “remove access” and “delete the account” as the same action. They aren’t, and conflating them destroys evidence:

1. Immediately: disable the account, revoke active sessions and tokens, and remove the person from groups. Access is gone within minutes.
2. During retention: keep the disabled account intact. The mailbox enters a retention/litigation-hold state; the manager gets delegated access for handover; owned data is reassigned.
3. After the retention window: only now is the account deleted, per the policy and regulatory clock.

Deleting on day one feels clean but is wrong: you’ve just erased the audit trail an investigator might need, orphaned the documents the person owned, and bounced every email anyone sends them.

The dormant-account trap

Leavers aren’t the only source of dead access. Dormant accounts — active accounts nobody has logged into for months — are leaver-shaped risk hiding in plain sight: a contractor whose engagement quietly ended, a service account for a decommissioned app, an employee on long leave. A mature program runs dormancy detection alongside JML and challenges anything inactive past a threshold, because a forgotten active account is functionally identical to an unprocessed leaver.

Who owns what: the JML RACI

JML fails as often from unclear ownership as from bad tooling. Each movement touches several functions, and when “everyone” is responsible, no one is. A workable division of labor:

The recurring failure is the Mover column for the manager: managers are happy to request new access for their report and reliably silent about what should be removed. That’s why the IGA platform — not the manager — must own the “retire old roles” step, driven by recalculation rather than by someone remembering to ask.

An automation maturity model

JML maturity is a ladder, and most organizations can place themselves on it honestly:

Most organizations live at level 2 and believe they’re at level 3. The honest test is the Mover: if role removal on a transfer is automatic and reliable, you’re at level 3; if it depends on someone remembering, you’re at level 2 no matter how slick the Joiner flow looks.

Measuring whether JML actually works

You can’t manage what you don’t measure, and JML has a handful of metrics that reveal the truth quickly:

• Time-to-provision (Joiner): from start date to working access. Target hours, not days.
• Time-to-deprovision (Leaver): from termination event to access fully revoked. For urgent cases, minutes.
• Provisioning automation rate: percentage of access changes executed without a human touching them. The single best maturity proxy.
• Orphan rate: accounts with no matching identity, found by reconciliation. A direct measure of Leaver failure.
• Privilege-creep indicator: average entitlements per user trending up over time, or the count of users holding more roles than their current job implies — the Mover’s report card.
• SoD violation count: active segregation-of-duties conflicts, most of which are accreted Mover debt.

How JML breaks: the failure catalogue

The same failures recur across organizations. Knowing them by name lets you check for them deliberately:

Notice how many trace back to the Mover and the Leaver — the removal side of the lifecycle. Granting access is the easy, popular half; the discipline of an IAM program is entirely on the taking-away side.

Why JML is non-optional: the regulatory drivers

JML isn’t just good hygiene — it’s mandated, explicitly or implicitly, by every serious control framework:

• NIST SP 800-53 (AC-2, Account Management) requires creating, enabling, modifying, disabling, and removing accounts on defined triggers — that is JML, in control language.
• SOX demands that access to financial systems match current job responsibilities, which is impossible without working Movers and Leavers.
• HIPAA Security Rule requires that access to protected health information be granted and terminated per role — the Leaver flow as a legal obligation.
• PCI-DSS requires that access for terminated users be revoked immediately and that access be reviewed periodically.
• ISO/IEC 27001 (Annex A access-control objectives) expects provisioning and de-provisioning to be formal, documented processes.

The common thread: regulators don’t just want access granted correctly — they’re obsessed with access being removed correctly and promptly. Which is precisely the half of JML that organizations neglect, which is precisely why audits keep finding it.

Recap

JML is the engine of operational IAM, and its difficulty is asymmetric:

1. The lifecycle is a state machine, not an on/off switch — prospective, active, suspended, terminated, deleted, with rehire and retention complicating the edges.
2. Four access types sit underneath it: birthright and role-based (automated), requestable (governed), and JIT (the antidote to standing access).
3. Joiner is about a fast, correct day one — pre-stage, compute birthright from attributes, defer sensitive access.
4. Mover is the hardest step because removal is invisible; recalculate the whole set and retire what’s no longer justified, or accumulate privilege creep and SoD debt.
5. Leaver is about speed and sequencing — disable and revoke immediately, delete only after retention, and never trust that contractors will leave cleanly.
6. Ownership, metrics, and maturity determine whether any of this is real — and the honest test is always the removal side.

Three questions to test yourself

1. A long-tenured employee is found to hold access from three previous roles. Which JML step failed, why is that step the one that usually fails, and what control would have prevented the accumulation?
2. Design the Leaver flow for an employee fired for cause at 3 PM. What must happen in the first five minutes, what during the retention window, and what — if anything — should never be deleted?
3. An organization insists it’s “fully automated” because Joiners are instant. What single question would you ask to find out whether it’s actually at maturity level 3 or only level 2, and what answer would prove it?