Developer/Auth/IdentityLifecycle/Fundamentals/identity-lifecycle-management-joiner-mover-leaver

Identity Lifecycle Management: Joiner-Mover-Leaver

Concept

Identity lifecycle management is the discipline of keeping a person's (or service's) access in sync with their actual current relationship to the organization, across the full arc of that relationship rather than just at the moment an account is created. The standard framing is the Joiner-Mover-Leaver (JML) process, covering three transitions: Joiner — onboarding, provisioning a birthright bundle of access on day one; Mover — a role, team, or project change, which should both grant newly-needed access and revoke access tied to the old role; Leaver — offboarding, revoking all access, ideally the same day employment or engagement ends.

The technical machinery underneath JML is provisioning and deprovisioning: automated or semi-automated workflows, ideally triggered by an authoritative source of truth (usually the HR system, since HR knows about a hire, a role change, or a termination before any identity system does) rather than by a ticket someone remembers to file. Provisioning at the Joiner stage creates the account and assigns role-based access; at the Mover stage it both adds and removes entitlements to reflect the new role; deprovisioning at the Leaver stage disables or deletes the account and revokes every credential tied to it — including non-human identities like API keys and service accounts, which are frequently left out of the process entirely.

Tradeoffs

Automation level	Joiner speed	Mover accuracy	Leaver completeness	Operational cost
Fully manual (tickets, spreadsheets)	Slow — new hires wait on a human to act	Poor — old access is "cleanup later" and rarely happens	Poor — offboarding depends on someone remembering every system the person touched	Low tooling cost, high ongoing labor cost
Semi-automated (HR triggers a workflow, humans approve/execute steps)	Faster — the trigger is automatic even if execution isn't	Better, but still depends on execution discipline at each step	Better for known systems; still misses shadow-IT/unlisted accounts	Moderate — some tooling, less labor than fully manual
Fully automated (HR system as source of truth, connectors handle every downstream system)	Fastest — access exists before day one	Access changes automatically with role change events	Same-day revocation across every connected system, including API keys/service accounts if scoped in	Highest upfront tooling investment, lowest ongoing labor cost

The tradeoff is upfront integration cost against ongoing risk exposure: full automation requires building and maintaining connectors to every system that grants access (which is a real, continuing engineering investment as the systems inventory changes), but partial or manual processes reliably degrade into exactly the failure mode JML exists to prevent — access that outlives its business justification.

When to use / when not to

Automate the Joiner and Leaver stages first if resources are limited — Leaver in particular, since incomplete offboarding is the highest-severity failure mode (a departed employee or contractor retaining live access).
Treat non-human identities (API keys, service accounts, machine credentials) as first-class citizens of the JML process, not an afterthought — they need the same provisioning/deprovisioning discipline as human accounts, and are disproportionately likely to be missed by process built around the human employee lifecycle.
Route Mover events through the same automated pipeline as Joiner/Leaver rather than treating a role change as a manual add-only operation — access that should be revoked on a role change is the source of permission creep, not just access that's never granted.
A fully manual process may be acceptable only at very small scale (a handful of employees, one identity provider, no meaningful segregation-of-duties requirements) — it does not scale past that without accumulating orphaned accounts and stale entitlements.

Common pitfall

Building automation around the Joiner stage (fast onboarding is visible and valued) while leaving Mover and especially Leaver as manual or semi-manual afterthoughts. Industry survey data backs this up concretely: as of 2026 only about a third of organizations revoke a departing employee's access on the actual day they leave, and for roughly half it takes three or more days — and on the non-human side, only about one in five organizations has a formal process for offboarding and rotating API keys, despite the majority of machine credentials going unrotated within any recommended timeframe. The result is a growing population of orphaned accounts and stale entitlements that security teams often can't even fully enumerate, because the technical deprovisioning workflow only partially follows the HR-driven exit process rather than being triggered by it directly.

Engineering Lens

The review question that actually surfaces JML gaps isn't "do we have offboarding" — nearly every organization answers yes — it's "what's the maximum time between someone's access no longer being justified and that access being revoked, across every system, including the ones nobody thinks to check." Framed that way, the honest answer for most organizations includes at least one system where deprovisioning is manual, delayed, or simply unmonitored — usually non-human credentials or a peripheral SaaS tool outside the primary identity provider's reach. The Principal-level move is naming that gap explicitly and prioritizing automation coverage by blast radius (which systems, if left un-deprovisioned, cause the most damage) rather than treating "we have a JML process" as a binary, finished state.