A joiner-mover-leaver event is a lifecycle change in a person’s or non-human identity’s access status. In IAM, it covers onboarding, role changes, and offboarding, triggering account creation, entitlement updates, privilege revocation, and audit controls so access stays aligned with business need and security policy.
How Joiner-Mover-Leaver Events Work
Joiner-mover-leaver events are the operational moments that keep access aligned to real-world status changes. They connect HR, identity governance, application administration, and security policy so access is created, adjusted, or removed when a person or non-human identity changes role, team, sponsor, or employment state.
In practice, the value of the JML model is that it treats access as lifecycle-managed rather than permanent. A joiner needs the right baseline access, a mover should not keep old entitlements by default, and a leaver should lose access promptly so stale permissions do not accumulate.
Why JML Matters for Access Control
JML is the point where access governance becomes measurable. It is where organisations reconcile who should have access, who actually has access, and whether inherited or exceptional privileges still make sense. Without a disciplined JML process, entitlement drift becomes normal and least privilege becomes difficult to prove.
It also matters because lifecycle events are where many identity problems first surface, including orphaned accounts, birthright access that is too broad, and delayed revocation after role changes or departures. A JML process therefore sits at the centre of both governance and security hygiene.
What Changes at Join, Move, and Leave
A joiner event usually triggers account creation, group membership, application entitlements, mailbox or collaboration access, and any role-based baseline permissions that the business has approved. The goal is to give the new identity enough access to work without opening unnecessary pathways from day one.
A mover event is often the most overlooked stage because the user still needs access, but not necessarily the same access. Role changes should remove obsolete access, grant new access, and preserve evidence of what changed so reviewers can spot privilege creep over time.
A leaver event is the most sensitive because it closes the trust relationship. Access should be revoked, accounts disabled or removed, and any connected credentials, sessions, tokens, or delegated permissions that remain usable after departure should be handled according to policy.
JML in Identity Governance and Audit
JML is not just provisioning. It is also a control story about ownership, approvals, segregation of duties, and evidence. A strong JML process leaves a clear record of why access was granted, when it changed, who approved it, and when it was removed.
That audit trail matters because lifecycle changes are one of the easiest places to test whether governance is real or merely documented. If the organisation cannot show timely revocation, accurate entitlement updates, and periodic review of lingering access, then the process is not fully under control.
For a practical lifecycle reference, the Joiner-Mover-Leaver (JML) Guide covers how to automate onboarding, role changes, and offboarding while removing old-role access and revoking what leavers leave behind.
For broader governance context, IAM and IGA Basics explains how provisioning, entitlement management, and access reviews fit together across people and machines.
For non-human populations, NHI Lifecycle Management Guide extends the same lifecycle logic to provisioning, rotation, visibility, and offboarding of non-human identities.
Risk and Threat Considerations
JML failures create a direct exposure window: access that should have been reduced or removed can linger after a role change or departure. That stale access is attractive because it often includes legitimate credentials, trusted sessions, or permissions that defenders assume are already gone.
Failure mechanism: The process breaks when HR, IAM, application owners, or security teams do not share a reliable trigger, so accounts, entitlements, and active access paths remain valid after the business event has changed.
Impact: The result can be privilege creep, orphaned access, unauthorized use after departure, and a larger attack surface for credential abuse or insider misuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | JML is the lifecycle control that creates, modifies, reviews, and removes user access. |
| IA-5 — Authenticator Management | Leaver handling often includes revoking or rotating authenticators, tokens, and other credential material. | |
| AU-6 — Audit Review, Analysis, and Reporting | JML needs auditable evidence of who changed access, when, and why across lifecycle events. | |
| Recommendation — Use AC-2 to govern account creation, modification, disabling, and review around joiner, mover, and leaver events. Use IA-5 to manage credential issuance, change, and revocation when identities change status. Use AU-6 to review lifecycle access changes and investigate abnormal provisioning or revocation patterns. | ||
| CIS Controls v8 | CIS-5 — Account Management | CIS account management directly covers provisioning, deprovisioning, and access governance for lifecycle events. |
| Recommendation — Apply CIS-5 to automate account changes and remove stale access when people or non-human identities move or leave. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | JML is the operational mechanism for granting, changing, and removing access rights over time. |
| Recommendation — Use A.5.18 to ensure access rights are provisioned, adjusted, and revoked in line with role and status changes. | ||
Practitioner Guidance
Why practitioners should care: JML is one of the few IAM processes that directly ties business change to access change, so it is a control point, not an administrative formality. If lifecycle changes are delayed or inconsistently applied, every downstream access review becomes harder to trust.
Governance implication: Treat the joiner, mover, and leaver workflow as an owned control with clear triggers, accountable approvers, and measurable closure times. The practical test is whether the organisation can prove that access always follows status, not the other way around.
Practitioner takeaway: The strongest JML programmes are the ones that remove obsolete access as deliberately as they add new access, because the mover and leaver stages usually expose more risk than the joiner stage.
Related resources from NHI Mgmt Group
- Why do third-party application credentials create residual risk after a Joiner-Mover-Leaver event?
- Why do service accounts and API keys complicate joiner-mover-leaver processes?
- How can organisations use access profiles in joiner-mover-leaver workflows?
- How should security teams automate joiner-mover-leaver workflows?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org