Use the risk lens first. Leavers usually deserve top priority because missed offboarding leaves a live account behind with no active owner. Movers come next because old access often accumulates quietly after role changes. Joiners are still important, but their failures are visible immediately. The right order depends on whether your goal is to reduce silent exposure or to fix the loudest operational pain.
Why Joiner, Mover, and Leaver Priorities Should Be Risk-Based
Identity teams often treat joiners, movers, and leavers as a queue management problem, but real access risk is not evenly distributed across the lifecycle. Leavers matter because stale accounts can remain active without an owner, while movers create hidden drift as roles, systems, and entitlements change over time. Joiners are operationally visible, but they usually create less silent exposure than forgotten access. NHIMG’s research shows how quickly identity weaknesses become material, including the finding that Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges, which is a reminder that unused or outdated access is often the larger issue than initial provisioning.
This is why current guidance suggests prioritising the controls most likely to eliminate dormant privilege, not simply the tickets that are easiest to process. The same logic appears in external frameworks such as the NIST Cybersecurity Framework 2.0, which emphasises governance, protective access management, and ongoing control of identity exposure rather than one-time setup. In practice, many security teams discover leaver failures only after an audit, an incident, or a manager dispute, rather than through deliberate lifecycle design.
How Risk-Based JML Triage Works in Practice
The practical shift is to score each JML event by the likelihood that it leaves behind active access someone should no longer have. That means leaver workflows should trigger immediate deprovisioning for high-value systems, privileged accounts, tokens, and shared administrative paths. Movers should trigger entitlement review, because role changes often leave old permissions in place long after the business need has disappeared. Joiners still need fast onboarding, but the risk usually sits in over-provisioning, not in leaving behind hidden access.
A useful operating model is to separate speed from depth. Speed handles day-one access so people can work, while depth handles risk review so access does not accumulate. Teams often combine HR events, manager attestations, application ownership, and access recertification to decide what must be removed immediately and what can wait for scheduled review. This is especially important because NHI governance patterns often mirror human lifecycle weaknesses. NHIMG notes in the 52 NHI Breaches Analysis that compromised identities repeatedly turn into repeated incidents, which reinforces the value of fast revocation and consistent follow-up.
- For leavers, revoke access by system criticality, starting with privileged, externally exposed, and hard-to-detect entitlements.
- For movers, compare old and new roles to remove access that no longer has a business justification.
- For joiners, use least privilege by default and grant exceptions only when there is explicit owner approval.
- For all three, maintain a clear record of who approved, who removed, and when the action completed.
Frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls support this approach through access enforcement, auditability, and account lifecycle controls. These controls tend to break down when HR data is delayed or when application owners cannot tell which entitlements are still genuinely required.
Where the Standard Priority Order Breaks Down
Tighter lifecycle control often increases operational overhead, requiring organisations to balance reduction of silent exposure against the speed of onboarding and role change. There is no universal standard for this yet, because the right priority depends on business context, regulatory exposure, and the quality of identity data. A regulated environment with privileged admin access will usually place leavers first; a fast-moving operations team may focus on movers because role drift accumulates faster than offboarding errors.
The main exception is when joiners are tied to sensitive applications or emergency access paths. In those cases, onboarding mistakes can create immediate exposure, so the risk lens should override any fixed order. Best practice is evolving toward lifecycle segmentation by access tier rather than a single enterprise-wide queue. For example, a leaver from a low-risk team may be less urgent than a mover who just retained production privileges across multiple systems.
The useful rule is simple: prioritise the event that most likely leaves behind access without a legitimate owner, then measure whether your process actually removes it. If the identity team is only tracking ticket closure, it will miss the real control failure, which is whether old access is still live after the business change has already happened.
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 CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Identity lifecycle controls help reduce stale access across joiners, movers, leavers. |
| NIST SP 800-53 Rev 5 | AC-2 | Account management directly governs provisioning, modification, and removal of access. |
| OWASP Non-Human Identity Top 10 | NHI-01 | NHI lifecycle risk mirrors stale access problems in JML workflows. |
| NIST AI RMF | GOVERN | Risk-based prioritisation needs governance, ownership, and accountability decisions. |
| CSA MAESTRO | ICM | Lifecycle governance for autonomous workloads follows identity and access control discipline. |
Inventory identities and remove orphaned or overprivileged accounts as part of JML handling.
Related resources from NHI Mgmt Group
- How should app teams reduce identity attack risk when multiple login methods can attach to the same account?
- How should security teams reduce the risk of OAuth 2.0 consent phishing in enterprise identity environments?
- How should security teams reduce the risk of cloud secrets repositories being abused for credential access?
- How should teams reduce the risk from exposed NHI secrets?