Why movers are the hardest part of JML governance

At a glance

What this is: This is a short vendor analysis of why the mover stage in JML is the hardest to govern and how access creep builds during role changes.

Why it matters: It matters because mover events can quietly expand access across human IAM and IGA programmes, and the same lifecycle blind spot also mirrors how NHI entitlements drift when no one owns cleanup.

👉 Read Lumos's analysis of why movers are the hardest part of JML

Context

Mover governance is the identity problem that sits between onboarding and offboarding: access changes when a person changes role, but the old permissions do not always disappear. In practice, that creates entitlement creep, where access accumulates across departments, tools, and data sets unless lifecycle controls are tied to the move itself.

For IAM, IGA, and PAM teams, the hard part is not the concept of least privilege. It is the organisational fact that role changes are messy, partial, and often missed by HR, IT, and managers at the same time. When mover events are not formalised, access reviews become a cleanup exercise instead of a control.

Key questions

Q: How should organisations manage access when employees change roles?

A: Treat the move as a lifecycle event, not a manual exception. The workflow should revoke access tied to the old role, provision only the access needed for the new role, and require manager validation for any temporary overlap. This prevents entitlement creep and keeps access aligned to current responsibilities.

Q: Why do mover events create more access risk than joiners or leavers?

A: Mover events are harder because they rarely have a clean start or end point. Employees may keep supporting their previous role while taking on new duties, which makes it easy for old access to linger. That lingering access is what turns a routine transfer into a governance problem.

Q: What breaks when organisations rely on access reviews to handle movers?

A: Reviews happen after the access has already drifted, so they cannot prevent the accumulation of stale entitlements. If the mover workflow does not remove old access automatically, a quarterly review only confirms the problem later. Good governance uses reviews to validate outcomes, not to replace revocation.

Q: How do managers and HR reduce mover-related privilege creep?

A: They need a shared process that sends a reliable mover signal as soon as a transfer, promotion, or department change is confirmed. That signal should trigger entitlement mapping, approval of new access, and removal of obsolete permissions. Without a shared signal, each team sees only part of the lifecycle.

Technical breakdown

Why mover events break policy mapping

Mover access is difficult because job changes rarely map cleanly to a single entitlement package. A title can stay the same while responsibilities shift, or the title can change while the actual toolset stays in transition. That makes static RBAC brittle, because the control assumes a stable role-to-access mapping that does not exist in real organisations. ABAC can help, but only if the underlying attributes are current, specific, and tied to business context rather than broad org charts. The technical challenge is not policy syntax. It is the quality of the trigger data that decides when policy should change.

Practical implication: tie mover policy decisions to validated business events, not just title changes in HR records.

Entitlement creep across hybrid app estates

Entitlement creep occurs when a user keeps legacy access after taking on new duties. In hybrid estates, that risk grows because some apps are covered by workflow controls while others sit outside mature IGA reach. The result is a split control plane, where access can be granted quickly but removed slowly or not at all. This is especially risky when old permissions include sensitive pipelines, customer records, or privileged operational functions. The technical issue is not only excess privilege. It is uneven lifecycle enforcement across the application estate, which creates blind spots that accumulate over time.

Practical implication: measure mover cleanup coverage by application and remove any estate segment that cannot revoke access at the same speed it grants it.

Why access reviews alone do not fix movers

Access reviews are a backstop, not a mover strategy. If a user has already crossed into a new role but still has old access, a quarterly certification cycle may preserve the problem for months. Reviews also depend on managers understanding both the new responsibilities and the residual access that should be removed, which is often incomplete. Effective mover governance needs event-driven remediation, not just periodic verification. Without that, reviews become a confirmation step for stale entitlements rather than a control that prevents them from persisting.

Practical implication: use access reviews to validate mover outcomes after the event, but make revocation the default action in the mover workflow.

NHI Mgmt Group analysis

Mover governance is a lifecycle control problem, not a role-change administration problem. The article correctly shows that movers become risky when organisations treat them as an informal HR event instead of a governed identity state. In IAM terms, the control failure is not the move itself but the absence of a reliable revocation path for old access. Practitioners should read this as a warning that lifecycle design, not just access policy design, determines whether entitlement creep takes hold.

Entitlement creep is the named failure mode that explains why movers become superusers. Access accumulates when old permissions remain after a role transition and no one owns the cleanup. That pattern is especially damaging because it looks harmless in the moment and only becomes visible after enough moves have stacked up. The practitioner takeaway is that mover governance must be measured by retained access after role change, not by the volume of approvals completed.

Cross-functional drift is the operational gap that turns mover policy into a black hole. HR, IT, security, and managers each hold part of the truth, but none of them owns the full lifecycle picture unless the process is explicitly wired together. The article shows that manual coordination is too weak to handle frequent internal movement at scale. Practitioners should treat handoff failure as part of the risk, not as an administrative inconvenience.

Access policies for movers need more context than a job title can provide. A title can hide major differences in responsibilities, tools, and data access, which is why role-only models break down quickly. The stronger position is that mover governance requires policy logic that reflects responsibilities and exceptions, not just organisational labels. For practitioners, that means reviewing whether current policy models can express transitional access without leaving stale rights behind.

Formalising the mover as a first-class lifecycle event strengthens JML as a discipline. The article’s most useful contribution is its insistence that the middle of the employee lifecycle deserves the same operational attention as joiner and leaver events. That aligns with broader identity governance practice, where lifecycle state changes should trigger deterministic controls. Practitioners should stop treating mover handling as a special case and start measuring it as a standard governance event.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• For lifecycle control patterns that apply across people and machines, review NHI Lifecycle Management Guide for the governance steps that stop access from lingering after a state change.

What this signals

Mover governance is becoming a broader lifecycle maturity test, not a narrow HR workflow problem. Organisations that cannot remove obsolete access quickly after role changes will keep accumulating hidden privilege, and that same weakness will show up in service-account and workload lifecycle processes as soon as entitlements drift across teams.

Entitlement persistence debt: every delayed mover revocation adds access that no one actively needed, but everyone must now govern. The longer that debt builds, the more access reviews turn into archaeology instead of control. Teams should expect lifecycle automation to move from convenience feature to baseline governance expectation.

For a wider control baseline, the NIST Cybersecurity Framework 2.0 remains useful for tying identity lifecycle changes to protect and respond outcomes. The practical signal is simple: if mover events cannot trigger deterministic revocation, your identity programme is still relying on human memory to enforce policy.

For practitioners

• Formalise the mover as a lifecycle trigger Create a distinct mover event in JML workflows so role changes automatically initiate entitlement review, access removal, and reapproval for newly needed systems. Link the trigger to HR and manager-confirmed business context, not just a job title update.
• Map retained access after role changes Inventory which applications still carry old permissions after transfers, promotions, or team changes, then track the percentage of mover cases where legacy access remains active beyond the transition.
• Close the cross-functional handoff gap Build a shared operating model for HR, IT, security, and managers so role changes generate a single authoritative signal for access updates. Automated notifications should be the default, because manual follow-up is where mover risk usually persists.
• Use access reviews as a cleanup control Schedule certifications after known mover events, but treat the review as validation of a completed revocation workflow rather than the main control. If managers cannot explain why old access is still required, it should be removed before the next review cycle.

Key takeaways

• Mover events are the weak link in JML because role changes often leave old access behind.
• The risk is measurable as entitlement creep, where access accumulates faster than teams clean it up.
• The strongest control is a formal mover workflow that triggers revocation as part of the role-change event.

Key terms

• Joiner-Mover-Leaver: A JML lifecycle model describes how access is created, changed, and removed as people enter, move through, and leave an organisation. In practice, the mover stage is often the hardest because access must be adjusted while the user is still active and responsibilities are changing.
• Entitlement Creep: Entitlement creep is the gradual accumulation of permissions that are no longer needed after a role change. It happens when old access is never removed, leaving users with more reach than their current duties require and expanding both operational and compliance risk.
• Access Certification: Access certification is the process of reviewing whether existing permissions are still appropriate. For mover governance, it is a validation control, not the primary fix, because it checks access after change rather than ensuring obsolete permissions are removed when the move occurs.
• Role-Based Access Control: Role-Based Access Control assigns permissions based on a defined job or function. It works best when roles are stable, but mover scenarios expose its limits because real organisations change gradually, making rigid role mappings too coarse without additional context or exception handling.

What's in the full article

Lumos's full article covers the operational detail this post intentionally leaves for the source:

• A step-by-step breakdown of the mover workflow ideas the vendor recommends for role transitions and access cleanup.
• Examples of how automation and AI are positioned to support mover policy maintenance across connected systems.
• The article's own explanation of why delayed access removal is presented as a practical compromise during transitions.
• The vendor's implementation framing for connecting HRIS changes to identity workflow triggers.

👉 Lumos's full post covers mover workflow ideas, automation framing, and lifecycle transition detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle governance in your organisation, it is worth exploring.