The joiner-mover-leaver lifecycle describes the access changes that should happen when a person or account is created, changes role, or exits the organisation. It is the basic operating model for keeping entitlements aligned to current need, and it becomes critical when automation replaces manual ticket handling.
Expanded Definition
The joiner-mover-leaver lifecycle is the operational pattern for creating, changing, and removing access as people or service accounts enter, move within, or leave an organisation. In NHI programs, it extends beyond human onboarding to API keys, service accounts, bots, and other non-human identities that must stay aligned to current purpose.
For mature identity teams, the lifecycle is less about a ticketing sequence and more about control points: approve, provision, review, rotate, suspend, and revoke. Definitions vary across vendors on whether the lifecycle includes attestation, credential rotation, and downstream entitlement cleanup, but no single standard governs this yet. In practice, the model is strongest when it is tied to OWASP Non-Human Identity Top 10 risk categories and enforced through automation rather than manual exception handling.
The most common misapplication is treating joiner-mover-leaver as a human HR workflow only, which occurs when teams fail to extend the same controls to machine identities, cloud roles, and embedded secrets.
Examples and Use Cases
Implementing joiner-mover-leaver rigorously often introduces coordination overhead, requiring organisations to balance tighter access control against faster delivery and lower administrative friction.
- When a developer changes teams, their human access may be updated through HR events while their deployment tokens, vault permissions, and CI/CD access must be re-evaluated through the same lifecycle controls. The NHI Lifecycle Management Guide is useful here because it treats lifecycle transitions as governance events, not just provisioning tasks.
- When a service account is no longer owned by an application, the identity should be disabled, rotated, or deleted after dependency checks, especially if it appears in the patterns described in the Guide to the Secret Sprawl Challenge.
- When a workload is redeployed into a new environment, entitlements should be re-bound to the new trust boundary instead of copied forward. This is consistent with OWASP Non-Human Identity Top 10 guidance on limiting standing access and reducing credential reuse.
- When an AI agent receives a new tool permission, the lifecycle should include approval, scoped grant, monitoring, and revocation triggers. That prevents long-lived access from drifting beyond the agent’s intended task.
- When a contractor exits, the lifecycle must cover accounts, tokens, certificates, and any shared secrets stored in code or tickets, not just the directory record.
In advanced environments, the same pattern is applied to rotation and expiry. The Guide to NHI Rotation Challenges shows why mover events often expose hidden credential dependencies that a simple HR-driven workflow misses.
Why It Matters in NHI Security
Joiner-mover-leaver failures are one of the fastest paths from ordinary access drift to material exposure. NHI programs fail when access is granted once and never reconciled after role change, environment change, or offboarding. That is where lifecycle control becomes a security boundary, not an administrative convenience.
NHIMG research shows that 91% of former employee tokens remain active after offboarding, which is exactly the kind of gap joiner-mover-leaver controls are meant to eliminate. The same body of research also shows that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why secret sprawl and stale entitlements persist together.
This lifecycle matters because automation can scale either good hygiene or bad inheritance. If a moved workload keeps old permissions, or if a leaver’s access is not revoked across vaults, code repos, and cloud roles, compromise becomes easier and harder to detect. Practitioners should pair lifecycle governance with static versus dynamic secret strategy so revocation is practical, not theoretical. Organisations typically encounter the cost only after an offboarding event, service migration, or incident review, at which point joiner-mover-leaver 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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret misuse and lifecycle gaps that JML processes must prevent. |
| NIST CSF 2.0 | PR.AC-1 | Access provisioning and revocation support least-privilege access control outcomes. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires continuous verification as identities and contexts change. |
Tie JML events to automated provisioning, review, and revocation workflows.
