The joiner, leaver, and move process covers the access changes that happen when people enter, leave, or change roles in an organisation. It is a core identity governance workflow because timely updates reduce inappropriate access, improve compliance, and help ensure access follows the business lifecycle.
Expanded Definition
The joiner leaver move process, often shortened to JLM, is the identity governance workflow that updates access when a person is hired, changes role, transfers teams, or exits the organisation. In mature IAM programs, it is the operational bridge between HR events and entitlement changes across applications, infrastructure, and privileged access systems. Guidance varies across vendors on whether JLM is treated as a pure HR synchronization workflow or as part of broader identity lifecycle management, but the core security expectation is consistent: access should match current job function and stop when the business relationship ends.
JLM matters because it touches provisioning, deprovisioning, role changes, approvals, and evidence generation for audit. It is closely aligned with least privilege, Zero Trust, and identity governance controls described in the NIST Cybersecurity Framework 2.0. For NHI programs, the same lifecycle logic must extend to service accounts, API keys, tokens, and certificates, not just human users. The most common misapplication is treating moves as a low-risk admin task, which occurs when role changes are processed informally and old entitlements are left active.
Examples and Use Cases
Implementing JLM rigorously often introduces workflow friction, requiring organisations to weigh faster employee access against tighter approval and revocation controls.
- A new engineer joins and is automatically provisioned into a standard role bundle, with additional access requiring manager and application owner approval.
- An employee transfers from finance to marketing and loses finance-system access on the same day the new role is granted, preventing entitlement overlap. The lifecycle discipline described in the Ultimate Guide to NHIs shows why the same timing matters for machine identities as well.
- A contractor’s badge and SaaS access are disabled at offboarding, and remaining tokens are revoked so stale sessions cannot persist after departure.
- A platform team rotates ownership of a production service account after a team reorganisation, ensuring the account’s privileges match the new operational boundary.
- A cloud migration project reassigns application ownership, triggering access review, token re-issuance, and removal of obsolete admin grants.
For implementation detail, identity teams often map JLM triggers to HRIS events, ITSM tickets, and privileged access workflows. The practical lesson is that the process is not only about onboarding; it is also about timely removal and reclassification of access as business context changes.
Why It Matters in NHI Security
JLM failures create the conditions for orphaned accounts, lingering privilege, and untracked access paths that attackers routinely exploit. In NHI environments, those failures are more dangerous because service accounts and API keys do not leave on their own. The Ultimate Guide to NHIs reports that only 20% of organisations have formal offboarding and API key revocation processes, and 91.6% of secrets remain valid five days after notification, showing how often lifecycle controls lag behind operational reality. That gap is directly relevant to JLM because the same delay that leaves a former employee active can leave a machine credential usable long after a role or system change.
Practitioners should view JLM as a control for reducing over-privilege, shrinking the blast radius of compromised accounts, and improving auditability across human and non-human identities. It also supports zero trust expectations by forcing access to be continuously revalidated as context changes. Organisations typically encounter the consequences only after a termination, reorg, or breach review, at which point JLM becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed as roles and conditions change. |
| NIST Zero Trust (SP 800-207) | PA-1 | Zero Trust depends on continuously re-evaluated identity and access context. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Lifecycle weaknesses create stale secrets and unmanaged non-human identities. |
| NIST SP 800-63 | IAL2 | Identity proofing and lifecycle events shape who may receive access. |
| OWASP Agentic AI Top 10 | A-03 | Agent and tool access must be revoked when ownership or purpose changes. |
Tie joiner, leaver, and move events to timely access updates and periodic entitlement reviews.
Related resources from NHI Mgmt Group
- What breaks when deprovisioning is not tied to the joiner-mover-leaver process?
- 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
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
