The JML cycle: Joiner, Mover, Leaver in depth

Ten years, five teams, one audit finding

Daniel has worked at the same distribution company for ten years. He started in purchasing, moved to warehouse planning, spent two years in accounts payable, did a stint covering for a manager in logistics and now runs a small analytics team. Every move came with new access, requested by his new manager and approved within a day. None of the moves took anything away. During a SOX audit, a routine query turns up something nobody intended: Daniel can create a supplier in the ERP, a permission left over from purchasing, and approve payments to suppliers, left over from accounts payable. Nobody ever decided he should be able to do both. It just accumulated.

The operational IAM cycle introduced the six processes that keep an IAM program running, and JML was one of them, seen from a distance. This article opens that one box completely, because JML is where most of the value of an IAM program lives, and most of its failures too. Every other process exists to serve it. Aggregation and the master record exist so JML knows who changed. Correlation and reconciliation exist so JML knows which accounts to touch. Certification exists to catch what JML missed. Get JML right and the rest of the program has a chance; get it wrong and no dashboard or audit will save you, because you’ll spend your life cleaning up access that no longer matches reality.

In one sentence, JML is the discipline of keeping a person’s access equal to what their current relationship with the organization justifies, no more and no less, at every moment from before their first day to after their last.

The 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 change of state is an event JML has to react to. Thinking in states is what separates a solid program from one that only handles the easy 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 --> [*]

A person becomes prospective as soon as a hire is approved, often days or weeks before they start. On the start date the joiner flow makes them active. While active they may go through the mover loop many times. A leave of absence parks them in suspended, where access is frozen but not destroyed. Leaving triggers the leaver flow into terminated, but that isn’t the end: a rehire can bring them back to active, and only after a retention period set by policy 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 now” loses forensic evidence and breaks the ownership of data. A program with no suspended state either strips everything during a parental leave or, worse, leaves full access in place for someone who isn’t there.

The kinds of access JML moves

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

The difference matters a great deal. Birthright and role-based access are what the joiner and mover flows automate; they’re calculated from attributes, so the system can grant and remove them without a person. Requestable access is what those flows can’t assume, because it needs someone’s intent and an approval. And just-in-time access is the way out that keeps requestable access from turning into permanent debt: instead of granting standing access a future mover will forget to remove, you grant it for as long as it’s needed and let it expire. In a healthy program, roughly 60% of a typical user’s access is birthright or role-based, about 30% is requestable and governed by approval and certification, and the small remainder is just-in-time for truly sensitive operations. When almost everything is requestable, the automation is too thin; when almost everything is birthright, you’ve over-provisioned and lost least privilege.

Joiners: getting day one right

The joiner flow has one deceptively hard goal: the new person is productive from their first click, and has only the access their job justifies. Both halves matter. Give too little and the manager starts raising urgent tickets and the new hire’s first impression is friction; give too much and you’ve planted privilege creep before they’ve even signed in.

A mature joiner flow isn’t one event but three. Before the start date, as soon as the offer is accepted, the HR system creates a prospective identity, and IGA can build the accounts in a disabled state, order the hardware and queue the training, so nothing has to be created in a rush on the morning itself. On day one the identity becomes active, the prepared accounts are switched on, birthright and role-based access apply, and credentials are issued; because the heavy lifting already happened, this step is quick and low-risk. And during probation, some access is deliberately held back, production access, signing authority, sensitive systems, until the person passes probation or completes required training. Encoding that as a scheduled change rather than a manual reminder is what stops it from being forgotten.

The pre-start window is convenient and also risky, because the accounts exist before the person does. They have to be created disabled, with activation tied to the real start date. A prepared account that’s switched on early, or that an attacker finds and uses in the gap, is a quiet way into the environment under a legitimate-looking identity.

The worst joiner habit is copying access: “give Sara the same as Daniel, they’re on the same team.” It feels efficient and it’s a disaster. Daniel, as we saw, has ten years of one-off grants, and Sara would inherit all of them on her first day. Birthright has to be calculated from attributes, title, department, location, type of employment, not copied from a person who is a pile of historical exceptions. Pushing that access out to applications increasingly relies on SCIM, the System for Cross-domain Identity Management, which gives IGA one standard API to create, update and disable accounts across modern SaaS, replacing the fragile per-application connectors of a decade ago.

Movers: 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, and every time it’s skipped, access piles up.

The result is privilege creep, Daniel’s story: someone who has passed through five teams ends up holding the sum of all five teams’ access. Nobody decided they should have it; it’s sediment. And it isn’t just untidy. Overlapping access from different functions is exactly how separation-of-duties violations are born. Daniel wasn’t given the power to create a supplier and pay it on purpose; he picked up one half years ago and the other half in a later move.

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 branch that matters is the middle one, remove old roles, because it’s the one human-driven processes skip. A correct mover recalculates the entire expected set of roles 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 cleanest way to think about it is that a mover is a small leaver from the old role and a small joiner into the new one, run together. Framed that way, removing the old access isn’t optional; it’s half the operation.

Simple sideways moves are easy. The cases that show a program’s real quality are harder. A promotion within the same team keeps some access, raises some and drops some, and a partial overlap is harder than a clean swap. A move to another department brings two role sets that may conflict, so separation of duties has to be checked from scratch. A temporary assignment or secondment should have its access expire automatically on return, which is exactly what just-in-time access is for. A change from employee to contractor, or the other way round, changes the whole basis of the access and even its authoritative source. And an acting or interim role brings elevated access that has to be clearly time-limited and reversible.

Leavers: removing access before it becomes a liability

The leaver flow is where IAM most visibly protects the organization, and where speed is a security property. Every minute a person who has left keeps their access is a minute of exposure: to an angry exit, to a compromised personal device or simply to an account nobody is watching any more.

Not all leavers are the same, and the flow has to tell them apart. A planned departure, a resignation or retirement with notice, can run on the scheduled last day, with the mailbox handover and data transfer arranged in advance. An immediate departure, a dismissal for cause or any situation where access has to go now, can’t 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 planned path is dangerous, because the case where speed matters most is exactly the one it can’t handle.

The most common leaver mistake is treating “remove access” and “delete the account” as the same thing. They aren’t, and mixing them up destroys evidence. Straight away, the account is disabled, active sessions and tokens are revoked and the person is removed from groups, so access is gone within minutes. During the retention period, the disabled account stays intact, the mailbox goes into retention or legal hold, the manager gets delegated access for the handover and the person’s data is reassigned. Only after the retention period is the account deleted, on the clock set by policy and regulation. Deleting on day one feels tidy but is wrong: you’ve erased the trail an investigator might need, orphaned the documents the person owned and made every email sent to them bounce.

Leavers aren’t the only source of dead access. Dormant accounts, active accounts nobody has used for months, are leaver-shaped risk hiding in plain sight: a contractor whose engagement quietly ended, a service account for an application that was switched off, 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 effectively an unprocessed leaver. Contractors are the biggest blind spot. Their departure is often not a clean “terminated” event in HR; the contract simply lapses and the supplier may not tell you in time. Without an authoritative contract end date feeding the leaver flow, contractor access routinely outlives the engagement, so every contractor identity needs a hard end date, and a missing or extended date should be treated as an exception to review.

Who owns what

JML fails as often from unclear ownership as from bad tools. Each movement touches several functions, and when everyone is responsible, nobody is.

HR owns the authoritative facts: the hire and start date for a joiner, the recorded change of role that triggers a mover, the termination date for a leaver. The manager asks for job-specific access when someone joins, confirms what the person still needs when they move and flags urgent departures. The IAM or IGA platform calculates birthright and role-based access and provisions it, recalculates and reconciles access on every move, and disables accounts, revokes sessions and schedules deletion on departure. Application owners approve sensitive entitlements, approve them again after a change and confirm removal in their application. And security reviews separation-of-duties exceptions when someone moves and investigates urgent departures.

The failure that keeps recurring is the manager’s part in the mover. Managers are happy to ask for new access for their people and reliably silent about what should be removed. That’s why the IGA platform, not the manager, has to own the “remove old roles” step, driven by recalculation rather than by someone remembering to ask. In Daniel’s company, every manager he ever had did their job as they understood it, and the gap was precisely that nobody owned the removal.

How mature is it, and how do you know?

JML maturity is a ladder, and most organizations can place themselves on it honestly. At level 1, everything is manual: IT tickets, spreadsheets and knowledge in people’s heads, and leavers linger for weeks with orphans everywhere. At level 2 it’s ticket-driven: standard forms and approvals, still carried out by people, consistent but slow, with movers half done. At level 3 it’s event-driven: HR events trigger automatic provisioning and removal, joiners and leavers are fast and movers are reconciled. And at level 4 it’s continuous: standing access is kept to a minimum, granted just in time and expired automatically, so privilege creep is prevented by design.

Most organizations sit at level 2 and believe they’re at level 3. The honest test is the mover. If removing roles on a transfer is automatic and reliable, you’re at level 3; if it depends on someone remembering, you’re at level 2, however slick the joiner flow looks.

A handful of numbers tell the truth quickly. Time to provision, from start date to working access, should be hours, not days. Time to deprovision, from the termination event to access fully removed, should be minutes for urgent cases. The automation rate, the share of access changes carried out without a person touching them, is the best single proxy for maturity. The orphan rate, accounts with no matching identity found by reconciliation, measures leaver failures directly. A privilege-creep indicator, the average number of entitlements per user rising over time or the number of people holding more roles than their current job implies, is the mover’s report card. And the count of separation-of-duties violations is mostly accumulated mover debt. If you can only measure one, make it time to deprovision for terminations, with evidence. It’s what regulators care about most, what a breach post-mortem will look at hardest, and the clearest sign that your leaver flow is real rather than wishful.

How JML breaks

The same failures turn up in organization after organization, and knowing them by name lets you look for them on purpose. Privilege creep comes from movers that add and never remove, and leads to separation-of-duties conflicts and a much bigger blast radius. Orphan accounts come from leavers that don’t reach every application, and become dormant access and raw material for breaches. A slow urgent leaver comes from having no real-time removal path, and leaves a window of exposure after a risky exit. Day-one friction comes from a joiner flow that’s too slow or gives too little, and leads to shadow IT and emergency over-granting. Copied access comes from cloning a colleague’s birthright, and passes on years of historical excess. Contractors who overstay come from having no authoritative contract end date. And standing privileged access comes from having no just-in-time option for sensitive entitlements, which leaves permanent high-value targets.

Notice how many of those come 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 lies almost entirely in taking access away.

Why JML isn’t optional

JML isn’t just good hygiene; every serious control framework requires it, explicitly or implicitly. NIST SP 800-53, in its account management control AC-2, requires accounts to be created, enabled, changed, disabled and removed on defined triggers, which is JML in the language of controls. SOX requires access to financial systems to match current responsibilities, which is impossible without working movers and leavers, and is exactly what Daniel’s audit tested. The HIPAA Security Rule requires access to protected health information to be granted and ended according to role, the leaver flow as a legal duty. PCI DSS requires access for terminated users to be revoked immediately and access to be reviewed periodically. And ISO/IEC 27001, through its Annex A access-control objectives, expects provisioning and deprovisioning to be formal, documented processes.

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

Recap

JML is the engine of operational IAM, and its difficulty is lopsided. The lifecycle is a state machine, not an on/off switch: prospective, active, suspended, terminated and deleted, with rehires and retention complicating the edges. Under it sit four kinds of access, birthright and role-based, which are automated, requestable, which is governed, and just-in-time, the antidote to standing access. Joiners are about a fast, correct first day: prepare in advance, calculate birthright from attributes and hold back sensitive access. Movers are the hardest step because removal is invisible, so you recalculate the whole set and take away what’s no longer justified, or you accumulate privilege creep and separation-of-duties debt like Daniel did. Leavers are about speed and order: disable and revoke at once, delete only after retention and never assume contractors will leave cleanly. And ownership, metrics and maturity decide whether any of it is real, with the honest test always on the removal side.

Three questions to test yourself

1. A long-serving employee turns out to hold access from three previous roles. Which JML step failed, why is it the one that usually fails, and which control would have stopped the build-up?
2. Design the leaver flow for an employee dismissed for cause at three in the afternoon. What has to happen in the first five minutes, what during the retention period, and what, if anything, should never be deleted?
3. An organization insists it’s “fully automated” because joiners get access instantly. What single question would tell you whether it’s really at maturity level 3 or only at level 2, and what answer would prove it?