A common mistake is treating access changes as isolated tickets instead of a governed lifecycle. At scale, joiners, movers, and leavers require policy driven automation, role alignment, and timely revocation across systems. If organisations rely on manual updates, they increase the chance of orphaned access, excessive permissions, and compliance gaps when employees change jobs or leave.
Why Security Teams Misread Joiner, Mover, and Leaver Risk
Joiner, mover, and leaver processes are often framed as HR workflow problems, but the real risk is identity drift across every downstream system. Security teams get this wrong when they assume a single HR event will reliably update SaaS apps, cloud roles, SSH keys, API tokens, and privileged access in time. At scale, small delays become standing access, and standing access becomes audit exposure.
This is especially visible when teams treat JML as a periodic reconciliation task instead of a continuous control. The issue is not just entitlement removal. It is whether access is governed as a lifecycle with enforceable policy, traceability, and revocation across human and non-human identities. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which shows how often access ownership is already unclear before a move or exit happens.
Practitioners also underestimate how quickly entitlement sprawl accumulates when identity governance is fragmented across HR, IAM, PAM, and application owners. In practice, many security teams discover the failure only after a leaver still has active access or a mover retains privileges from a previous role.
How Joiner, Mover, and Leaver Access Should Work at Scale
At scale, JML should operate as a policy-driven lifecycle, not a ticket queue. The source of truth should trigger role assignment, access changes, and revocation automatically, with exceptions routed through approval and logging. Current guidance from NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point toward least privilege, continuous oversight, and faster lifecycle control rather than static entitlement assumptions.
For joiners, the goal is to provision only what the role requires, then verify that access is bounded and logged. For movers, the key control is removing old access before new access accumulates, because role changes often create privilege layering that no one notices until review time. For leavers, revocation must cover every credential class: SSO sessions, VPN, PAM, service accounts, API keys, certificates, and delegated app access. NHIMG’s Lifecycle Processes for Managing NHIs is relevant here because the same lifecycle logic applies to secrets and service identities that outlive employee status.
- Use role design that is narrow enough to support auto-provisioning without broad exceptions.
- Trigger deprovisioning from authoritative lifecycle events, not from manual email requests.
- Separate standard access from privileged access so revocation is complete, not partial.
- Log every entitlement change with who approved it, when it happened, and what it affected.
Where teams mature, they add continuous access reviews, SoD checks, and just-in-time elevation for privileged tasks instead of permanent entitlement grants. These controls tend to break down when legacy apps, shared accounts, or manually managed exceptions sit outside the identity governance plane because those systems cannot enforce revocation consistently.
Common Failure Modes and the Edge Cases That Break Automation
Tighter JML automation often increases integration and governance overhead, so teams must balance speed against exception handling and data quality. That tradeoff becomes obvious when HR records are incomplete, role mappings are outdated, or application owners resist standardization. Current guidance suggests that this should be treated as an operating model problem, not just an IAM tooling issue.
The most common edge case is the mover event that spans multiple job functions, business units, or regions. A person may keep access needed for transition work while also receiving new access for the next role, which creates temporary overlap that can persist indefinitely if no expiry is enforced. Another failure mode is contractors, vendors, and service accounts, where offboarding is less visible and often detached from employee workflows. NHIMG’s Key Challenges and Risks section highlights why lifecycle gaps matter so much when identities are numerous and poorly owned.
The most practical benchmark is whether a leaver can still authenticate anywhere after the offboarding event has closed. In many environments, the answer is yes because access removal is distributed across too many systems, too many owners, and too many manual steps. Organizations that rely on periodic cleanup usually find orphaned access only during audit sampling or incident response, not during the actual departure.
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 AI RMF 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-03 | JML failures often leave NHI credentials active after role change or exit. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access and approval workflows are central to JML control. |
| NIST AI RMF | Lifecycle governance needs accountable processes and continuous monitoring. | |
| CSA MAESTRO | GOV-2 | Agentic governance patterns help structure lifecycle policy and oversight. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust reinforces dynamic access decisions and limited standing privilege. |
Automate entitlement changes and review exceptions against PR.AC-4 least-privilege expectations.
