They often treat JML as an HR workflow instead of an identity control. JML only works when access, device state, and application entitlements are updated together, otherwise privilege creep accumulates after every move or offboarding event.
Why This Matters for Security Teams
Joiner-mover-leaver programs fail when teams assume a ticket closed by HR equals access removed in reality. The security risk is not the formality of the process, but the timing and completeness of identity changes across directories, SaaS apps, device posture, and privileged entitlements. NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which shows how often lifecycle control is incomplete. The same lifecycle logic appears in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, where offboarding, rotation, and visibility are treated as one control plane rather than separate tasks.
Teams also underestimate how fast privilege accumulates when movers keep old access. A user can change teams, retain legacy group memberships, inherit new entitlements, and still keep dormant tokens or cached device trust. That creates a hidden gap between identity records and actual access paths, which is exactly where attackers and insider risk thrive. The NIST Cybersecurity Framework 2.0 frames identity governance as an ongoing protection function, not a one-time HR event. In practice, many security teams encounter excessive access only after an audit, a termination dispute, or a post-incident review, rather than through intentional lifecycle enforcement.
How It Works in Practice
Effective JML is an identity control because every lifecycle event should trigger synchronized changes across identity, access, and trust state. For joiners, that means provisioning only the minimum required roles, apps, and device policies on day one. For movers, it means removing legacy entitlements first, then adding only the access needed for the new role. For leavers, it means revoking sessions, tokens, API keys, certificates, device trust, and app access together, not in separate queues.
Practitioners usually get better results when they treat JML as a policy-driven workflow with clear ownership and machine-enforced checkpoints:
- Bind HR events to identity workflows so a change in employment status triggers downstream access updates.
- Use role-based baselines for common jobs, but review exceptions separately so temporary access does not become permanent.
- Reconcile directory groups, SaaS permissions, privileged access, and local device state after every move.
- Automate revocation for secrets and sessions, especially where service portals or shared admin consoles exist.
- Measure completion, not ticket closure, because closed tickets can still leave live credentials behind.
This is especially important where entitlement sprawl is already high. The NHIMG lifecycle guidance for NHIs reinforces the same principle: access must be rotated, reviewed, and decommissioned as part of the full lifecycle, not after the fact. Current guidance suggests mapping JML controls to identity governance, privileged access management, and device management as one operational chain. These controls tend to break down in decentralised environments because application owners can approve exceptions faster than security teams can detect lingering access.
Common Variations and Edge Cases
Tighter JML control often increases operational overhead, requiring organisations to balance fast onboarding against consistent deprovisioning. That tradeoff becomes visible in environments with contractors, shared service accounts, mergers, or frequent role changes, where the identity state is not cleanly tied to a single HR record.
Best practice is evolving for edge cases, and there is no universal standard for this yet. Some organisations use just-in-time access for movers so elevated rights expire automatically at the end of a project. Others create separate access tracks for privileged admins, because a normal mover process is too slow for emergency response or production support. The key is to prevent exceptions from bypassing the lifecycle record entirely.
One common mistake is assuming offboarding is complete when the account is disabled. That misses cached sessions, API tokens, mobile device trust, federated access, and delegated permissions in SaaS platforms. The lifecycle model in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because it emphasises revocation, rotation, and visibility as linked actions. In mature programs, JML succeeds only when access review, device control, and entitlement cleanup happen from the same source of truth.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | JML is about least-privilege access changes across the identity lifecycle. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Lifecycle and revocation failures map directly to lingering NHI credentials. |
| NIST AI RMF | AI RMF governance supports accountable identity lifecycle decisions and oversight. |
Assign lifecycle ownership and auditable decision points for access changes end to end.
