IDSync — identity software buyer platform
Run Stack Finder

Provisioning

Joiner / Mover / Leaver (JML)

Joiner / Mover / Leaver (JML) is the operational model for managing identity through the employee lifecycle — granting access on hire, changing it on role change, and removing it on exit — typically driven from an HR system through the IdP and into downstream apps via SCIM.

Last reviewed 5/30/2026

Key points

  • JML is the lifecycle model behind every modern provisioning workflow.
  • Joiner: birthright access provisioned on day one based on role/department.
  • Mover: access updated (added and removed) when the employee changes role.
  • Leaver: access fully revoked on exit — the part most organizations get wrong.
  • Drives from HR (Workday, BambooHR, Rippling, Hibob) → IdP (Okta, Entra) → apps (via SCIM).

What is Joiner / Mover / Leaver?

Joiner / Mover / Leaver (JML) is the operational model for managing identity across the full employee lifecycle. Every modern identity program is structured around the same three events:

  1. Joiner — a new employee starts. They need an IdP account, an email, a laptop, and access to the apps their role requires, ideally on day one.
  2. Mover — an employee changes role, team, or location. They need new access and the old access they no longer need has to be removed (the most-skipped part).
  3. Leaver — an employee leaves (voluntary, involuntary, or contract end). Every account, every session, every API token tied to them needs to be killed within hours, ideally minutes.

The typical JML chain

The cleanest pattern flows from a single source of truth:

``text HR system → Identity provider → Downstream apps (Workday) (Okta / Entra ID) (via SCIM / native) ``

  • HR is the authoritative record (hire date, term date, manager, department).
  • The IdP imports those records and assigns the user to groups based on role.
  • Groups drive both SSO access and SCIM provisioning into downstream apps.
  • A termination in HR cascades within minutes to IdP suspension, SCIM-driven account disable, session revocation, and device wipe.

Why JML matters

  • Day-one productivity — new hires staring at a blank screen for a week is a brutal first impression and an expensive one.
  • Security — orphaned accounts after layoffs or terminations are the single most common audit finding.
  • Compliance — SOC 2, ISO 27001, SOX, HIPAA, and most regulators expect documented, automated JML.
  • Cost — paying for SaaS seats nobody is using because nobody deprovisioned them.

Common pitfalls

  • HR doesn't sync to IdP in real time. Leavers stay active until the next nightly sync.
  • Movers are ignored. Joiners are easy, leavers are increasingly automated, movers are where stale access accumulates.
  • Birthright over-grant. Day-one access is too broad, then never trimmed.
  • Apps without SCIM. Manual deprovisioning never gets done consistently.
  • No emergency offboarding path. Hostile termination requires a same-minute kill, not a same-day kill.

How to fix JML at scale

  • Make HR the unambiguous source of truth.
  • Define birthright access by role/department, not by manual ticket.
  • Drive SCIM everywhere you can; manually deprovision the rest with checklists.
  • Implement emergency offboarding as a single button that kills IdP session, SCIM-deactivates, revokes OAuth grants, and rotates shared secrets.
  • Measure mean-time-to-deprovision and report on it.

FAQ

Is JML the same as IGA?

JML is the lifecycle pattern. IGA is the platform category that automates it (along with access reviews, SoD, and governance).

What if I don't have an HRIS?

Smaller orgs use the IdP itself (Okta, Google Workspace, Microsoft 365) as the source of truth. That works up to a point, then HR-driven becomes necessary.