Join, Move, Leave is the identity lifecycle model for onboarding, role change, and offboarding. It captures the three moments when access should be created, adjusted, or removed. Mature programs use these events to keep privileges aligned with job function, reduce lingering access, and prevent persistence after a user leaves.
What the Join, Move, Leave lifecycle actually governs
Join, Move, Leave is the operational identity lifecycle for when a person enters an organisation, changes role, or departs. The model matters because each event should trigger a corresponding access decision, not just an HR record update.
At join, access begins from a defined baseline. At move, existing access is reassessed against the new function, which is where stale entitlements most often persist. At leave, access should be removed promptly and completely so the account cannot linger as an unused but still-privileged entry point.
This lifecycle is broader than provisioning alone. It is a governance pattern for keeping permissions tied to current business need, which is why it sits at the centre of NHI Mgmt Group’s Ultimate Guide to NHIs as a lifecycle control concept, not a one-time admin task.
Why Join, Move, Leave is a control pattern, not an administrative convenience
The model exists because access drift is predictable. People change teams, projects end, contractors roll off, and legacy permissions accumulate unless the organisation has a repeatable way to join, move, and leave accounts and entitlements.
That makes Join, Move, Leave one of the clearest bridges between business change and security change. It turns ordinary workforce events into security events, which is what keeps privileges aligned with job function and prevents residual access from becoming a hidden dependency.
It also helps separate the concepts of account status and entitlement status. A user may still exist in a directory while some access should already have been removed, or a role change may require partial retention and partial replacement. The model forces those distinctions to be handled deliberately rather than assumed.
Where Join, Move, Leave fails in practice
Most failures come from timing, ownership, and incomplete deprovisioning. Join can overshoot and grant more than the baseline needed on day one. Move can leave old access behind. Leave can close the visible account while leaving tokens, app access, shared credentials, or downstream permissions active.
The biggest weakness is usually not the lifecycle idea itself, but the handoff between HR, IT, application owners, and security. If no one owns the move event, permissions tend to accumulate. If no one verifies the leave event, revocation becomes partial. If no one reviews the join event, excess access is often accepted as temporary and never cleaned up.
The risk is not theoretical. NHIMG’s guide notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a useful indicator of how often lifecycle discipline breaks down once access extends beyond a single human account.
How to think about Join, Move, Leave across access governance
Join, Move, Leave is best understood as an access governance control plane that spans provisioning, modification, and deprovisioning. It supports least privilege by making access changes event-driven, rather than relying on periodic cleanup or informal requests.
For practitioners, the important question is whether every lifecycle event produces a corresponding access outcome that is timely, complete, and reviewable. When that is true, the model reduces lingering privilege, shortens the window for misuse after role changes, and lowers the chance that departed users retain operational reach.
NHIMG’s broader NHI research also shows why lifecycle discipline matters at scale, since NHIs outnumber human identities by 25x to 50x in modern enterprises. The same join, move, leave logic becomes even more important when the “user” is a service, workload, or automation that changes ownership, purpose, or environment over time.
Risk and Threat Considerations
Join, Move, Leave creates risk when changes in employment or responsibility are not matched by changes in access. The result is residual privilege, which can be abused after a move, retained after a departure, or leveraged by an attacker who compromises an account that was never fully cleaned up.
Failure mechanism: lifecycle gaps leave old permissions, sessions, tokens, or delegated access in place after the business need has changed. That can create a persistence path for misuse, lateral movement, or unauthorized access long after the original event.
Impact: organisations can end up with access that no longer has a legitimate owner or purpose, increasing the chance of insider misuse, account abuse, audit failure, and delayed incident containment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Join, Move, Leave is an access governance lifecycle that depends on managing who can access what. |
| 5 — Account Management | The term directly concerns account creation, modification, and removal across the user lifecycle. | |
| 8 — Audit Log Management | Lifecycle changes need logging so access changes can be reviewed and validated after join, move, or leave events. | |
| Recommendation — Apply CIS Control 6 to provision, adjust, and revoke access as roles and employment status change. Use CIS Control 5 to track accounts through join, move, and leave events and remove stale access promptly. Use CIS Control 8 to log lifecycle-driven access changes and verify revocation and entitlement updates. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication and Access Control | Join, Move, Leave is a practical identity and access lifecycle model for controlling access over time. |
| PR.AA-04 — Access Permissions and Authorizations | The model exists to create, change, and remove permissions as people join, move, or leave. | |
| GV.OV-01 — Oversight of Cybersecurity Risk Management | Lifecycle drift is a governance issue because stale access creates measurable security exposure. | |
| Recommendation — Implement PR.AA-01 to keep access aligned with current role and employment status. Use PR.AA-04 to review and adjust permissions whenever a join, move, or leave event occurs. Use GV.OV-01 to assign lifecycle ownership and measure whether access changes are completed on time. | ||
Practitioner Guidance
Governance implication: Join, Move, Leave works only when someone is accountable for each lifecycle event end to end, including the access outcomes that should follow it. Treat the lifecycle as an entitlement control, not just an HR or service desk workflow.
What to watch for: role changes that do not trigger entitlement review, departures that do not trigger revocation verification, and exceptions that are accepted as temporary but never revisited. Those are the conditions that turn a clean lifecycle model into lingering access.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
