Mover events become invisible to automation, so access changes happen late or not at all. That allows old entitlements to persist after responsibilities shift, which creates entitlement creep, audit noise, and unnecessary privilege accumulation across roles.
When mover events are not formalised, what stops working in JML governance?
JML governance depends on the system knowing that a person’s role has changed. When a mover event is not captured, the identity and access process cannot reliably trigger removal, replacement, or recertification of entitlements. The result is a gap between real-world role change and control enforcement, which leaves access state stale even though the business context has moved on.
That failure is not just administrative. It breaks the assumption that access should track current duties, so old permissions remain in place while new permissions are added elsewhere. Over time, that distorts role design, weakens least privilege, and makes access reviews harder to trust because the record no longer reflects the operating reality.
In practice, formal mover handling is the difference between a controlled transition and a silent accumulation of residual access. Without it, the governance model still exists on paper, but the workflow that should enforce it no longer has a dependable event to act on.
How mover-event gaps create entitlement creep and audit noise
When mover events are invisible to automation, downstream workflows miss the moment when entitlements should be changed. That means old-role access can survive for weeks or months, especially where access is granted through multiple systems, shared approvals, or manual tickets. The longer the gap, the more likely the user collects overlapping access paths that no single owner reviews as a whole.
This is where entitlement creep becomes measurable. A moved employee may keep legacy access from the previous function, inherit new access for the current one, and retain exceptions that were only meant to be temporary. The audit consequence is noisy evidence, duplicated approvals, and recertification cycles that keep confirming a broken baseline rather than cleaning it up.
The same problem shows up when teams rely on Joiner-Mover-Leaver (JML) Guide style automation but fail to formalise mover triggers from the authoritative source. If the mover event is missing or ambiguous, the workflow cannot distinguish a legitimate role change from a harmless attribute update, so the entitlement state drifts instead of converging.
Why informal mover handling weakens least privilege over time
Formal mover governance is what prevents role changes from becoming a privilege-stacking exercise. Once movers are handled informally, access is often changed opportunistically, by exception, or only when someone notices a problem. That creates a bias toward retention: people keep what they already have because removal is harder than addition.
The risk grows across roles that span departments, projects, or platforms. A user can move from one job function to another and still retain prior administrative, data, or application access because the old entitlement is not tied to the change event. Even if no single permission looks excessive, the combined set can become broader than any current role justifies.
Good governance treats mover events as a control point, not a convenience signal. Once a mover is recognised, the access decision should compare current duties against current entitlements, then remove or revalidate anything that no longer has a business owner. That is the practical mechanism that keeps least privilege from eroding through routine organisational change.
Risk and Threat Considerations
Unformalised mover events create an exposure window where access outlives business need. The main risk is not only missed removal, it is cumulative privilege accumulation across multiple moves, which increases the blast radius if the account is misused, compromised, or simply over-empowered for its new role.
Failure mechanism: the governance system never receives a dependable mover signal, so entitlement changes are delayed, incomplete, or bypassed, leaving stale access active and creating invisible permission overlap.
Impact: organisations see entitlement creep, noisier audits, weaker recertification, and a larger set of permissions that can be abused if the account is compromised or misused.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Mover events often require credential and entitlement changes across accounts and tokens. |
| AC-2 — Account Management | JML mover handling is fundamentally about updating account status and access when duties change. | |
| AC-6 — Least Privilege | Stale mover access directly undermines least-privilege enforcement and increases excess permissions. | |
| Recommendation — Revoke or reissue credentials when role changes alter access needs. Automate account updates and removals when employees move roles. Strip permissions that are no longer justified by the new role. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Mover events must be managed so identities reflect current roles and responsibilities. |
| A.5.18 — Access rights | Formal mover governance is needed to grant, adjust and remove access as responsibilities change. | |
| Recommendation — Ensure identity records and role changes stay synchronised. Review and adjust access rights whenever duties change. | ||
Practitioner Guidance
What to verify: confirm that mover events are sourced from a single authoritative business record and that the access workflow can distinguish movers from simple attribute updates. If a move changes manager, department, location, or job family, there should be an explicit entitlement review path, not an informal ticket trail.
Decision rule: if a role change alters what the person should be able to do, treat the event as an access recalculation trigger, not a notification. Remove old-role access first, then approve only the access that is still justified for the new role.
What good looks like: mover events are timestamped, traceable, and tied to automated entitlement updates, with exceptions limited to documented edge cases. Access reviews should show a clean before-and-after picture, not repeated justification of legacy permissions.
Practitioner takeaway: mover governance fails when organisations treat role change as metadata instead of an access-control event; the control objective is to make every meaningful move force a visible entitlement decision.