Joiner Mover Leaver is the identity lifecycle process for creating, changing, and removing access as people enter, change roles, or leave an organization. It governs provisioning, modification, and deprovisioning across systems, ensuring access matches current job needs and reducing orphaned accounts, privilege creep, and residual access risk.
What Joiner Mover Leaver Covers Across the Identity Lifecycle
Joiner Mover Leaver is the operational identity lifecycle pattern for getting access right at the moments that matter: when someone starts, changes role, or exits. It is the practical bridge between employment status and real system permissions.
The term is broader than account creation and deletion. It includes identity proofing, provisioning, role changes, entitlement updates, group membership, and timely deprovisioning so access reflects current business need rather than historical accumulation.
Why JML Matters for Access Governance
JML exists because access becomes risky when it lags behind people and organisational change. Without a disciplined lifecycle, organisations accumulate orphaned accounts, stale entitlements, and permissions that no longer match job function, which weakens least privilege and complicates auditability.
It is also one of the clearest places where governance becomes operational. A JML process forces ownership decisions about who approves access, who revokes it, which systems must be updated, and how quickly changes must propagate after a move or departure.
For lifecycle-driven identity programs, NHIMG’s NHI Lifecycle Management Guide is a useful companion because it covers provisioning, governance, offboarding, and visibility patterns that mirror the same control problem in another identity population.
Common Failure Modes in Joiner Mover Leaver
JML breaks when the process is fragmented across HR, IT, application owners, and manual approvals. Delays between a personnel change and access update can leave excessive privileges in place, while incomplete offboarding can preserve dormant access long after the business relationship ends.
The most damaging failures are usually not dramatic. They are incremental: role changes that do not trigger entitlement review, contractor access that is never removed, and account ownership that is unclear enough for nobody to take responsibility for cleanup.
That is why the lifecycle is as much about visibility as it is about provisioning. If organisations cannot inventory active access reliably, they cannot prove that joiner, mover, and leaver actions actually happened end to end.
How JML Relates to Identity Security Outcomes
When JML works well, it reduces privilege creep, shortens exposure windows, and makes access review meaningful rather than symbolic. It also supports stronger evidence for audit, incident response, and segregation of duties by tying permissions to a current business context.
When it fails, the result is often residual access that outlives the need for it. That can enable unauthorized use, lateral movement, or simple operational confusion when old permissions continue to work after a role change or exit. In mature environments, JML is therefore a control for both lifecycle hygiene and security containment.
NHIMG’s Top 10 NHI Issues is also relevant here because it frames the broader identity control failures that arise when access is not governed across the full lifecycle.
Risk and Threat Considerations
JML failures create a direct security exposure because stale accounts and excess entitlements can remain usable after a person changes role or leaves. The risk is not only accidental overexposure, but also abuse of residual access by insiders or attackers who obtain valid credentials tied to an identity that was never fully cleaned up.
Failure mechanism: The lifecycle change is not propagated quickly or completely, so permissions, group membership, tokens, keys, or account states continue to authorize actions that no longer match current business need.
Impact: Orphaned or overprivileged access can enable unauthorized access, data exposure, policy violations, and harder incident containment because defenders must sort out which access is still legitimate.
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, CIS Controls v8 and NIST CSF 2.0 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 governs account creation, change, and removal across the identity lifecycle. |
| IA-5 — Authenticator Management | JML must handle credential lifecycle at join, move, and leave events. | |
| AC-6 — Least Privilege | JML is the control process that keeps access aligned to current job need. | |
| Recommendation — Enforce AC-2 to provision, modify, review, and disable accounts as roles change. Apply IA-5 to rotate, revoke, and retire authenticators during lifecycle changes. Use AC-6 to keep permissions constrained to current duties after each lifecycle event. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | JML is a core identity-management lifecycle process under Annex A. |
| A.5.18 — Access rights | JML directly governs granting, reviewing, and removing access rights over time. | |
| Recommendation — Define identity lifecycle ownership and procedures for joiner, mover, and leaver events. Review and revoke access rights whenever roles or employment status change. | ||
| CIS Controls v8 | CIS-5 — Account Management | JML is the operational account-management discipline CIS expects organizations to maintain. |
| Recommendation — Centralize account lifecycle management so access is disabled or updated at each personnel change. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | JML is the lifecycle control that enforces current-state access decisions. |
| Recommendation — Maintain joiner, mover, and leaver workflows that keep access decisions current. | ||
Practitioner Guidance
Governance implication: Treat JML as a cross-functional control, not an IT ticket queue. The process needs clear ownership for each lifecycle event, because gaps usually appear at the handoff between HR, managers, application owners, and security operations.
What to watch for: The strongest warning signs are delayed deprovisioning, repeated manual exceptions, and access changes that rely on people remembering to ask for them. Those are usually indicators that the lifecycle is not embedded into the business process itself.
Practitioner takeaway: A good JML program is measured by how little residual access survives a change, not by how many requests are processed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
