The lifecycle process that updates access as people or systems join, change role, or leave. For identity programmes, it is the mechanism that prevents rights from becoming stale and shared access from becoming unaccountable. Strong JML discipline is a continuous control, not a one-time onboarding task.
Expanded Definition
Joiner-mover-leaver flow, often shortened to JML, is the operational sequence that grants, adjusts, and removes access as an identity enters an environment, changes responsibilities, or departs. In NHI programmes, the same logic applies to service accounts, API keys, certificates, and other machine credentials, not just people. The critical distinction is that JML is a control process, while onboarding or offboarding is only one event within it. Mature JML design ties account state to authoritative lifecycle triggers, such as HR records, ITSM tickets, workload orchestration, or application events, so access changes occur consistently across systems. That aligns with the access governance emphasis in the NIST Cybersecurity Framework 2.0 and with the lifecycle discipline described in NHI governance guidance from Ultimate Guide to NHIs. Definitions vary across vendors on whether JML includes privileged elevation, secret rotation, or deprovisioning confirmation, but the security objective is stable: no identity should keep access after the business reason disappears. The most common misapplication is treating JML as an HR onboarding checklist, which occurs when systems fail to update access after role changes or machine ownership transfer.
Examples and Use Cases
Implementing JML rigorously often introduces coordination overhead, requiring organisations to balance faster provisioning against tighter control verification.
- A new engineer joins a platform team and receives only the baseline access needed for their role, with elevated permissions added through approval and logged expiration.
- A service account supporting a CI/CD pipeline is reassigned to a new application owner, and its secrets, scopes, and audit trail are updated before the old team loses control.
- An employee moves from finance to operations, triggering removal of finance system access and addition of the minimum operational entitlements required for the new role.
- When an API integration is retired, its credential is revoked, downstream references are removed, and any cached tokens are invalidated to prevent orphaned access.
- A contractor engagement ends, and the organisation confirms that all application roles, vault entries, and shared tokens tied to that identity have been removed.
These patterns are especially important where lifecycle actions touch non-human identities. NHIMG notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which makes lifecycle discipline a practical control gap rather than a theoretical one. The NIST view of continuous access governance is reinforced by the need to manage identities across change, not just creation, in the Ultimate Guide to NHIs and in identity lifecycle guidance from NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
JML matters because stale access is one of the fastest ways for routine identity changes to become security incidents. When a human or machine identity is not promptly updated, former privileges linger, shared credentials remain usable, and ownership becomes unclear. In NHI environments, that is especially dangerous because service accounts, tokens, and certificates often run quietly in the background and are rarely reviewed until something breaks. NHIMG reports that 97% of NHIs carry excessive privileges, which means lifecycle mistakes frequently interact with over-permissioning and widen blast radius during compromise. Good JML discipline supports Zero Trust, because trust must be continuously recalculated as identities move and depart, rather than assumed from a one-time approval. It also helps security teams correlate access to business purpose, which becomes essential for investigations, audits, and containment. The broader NHI risk picture is why lifecycle control is consistently highlighted in Ultimate Guide to NHIs alongside governance and offboarding. Organisations typically encounter the operational necessity of JML only after an account outlives its owner, at which point remediation becomes 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-01 | Lifecycle governance for NHIs depends on timely creation, change, and revocation of access. |
| NIST CSF 2.0 | PR.AA-01 | Identity and access governance requires access rights to follow role and status changes. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust depends on continuous reevaluation of access as identity context changes. |
Reassess privilege on each lifecycle change and remove standing access when it is no longer justified.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
