Why movers are the hardest part of JML governance

At a glance

What this is: This is a short analysis of why mover events are harder to govern than joiner or leaver events, with entitlement creep identified as the main risk.

Why it matters: It matters because IAM and IGA teams often design lifecycle controls around clean start and end points, while movers require continuous recalculation of access across changing roles, contexts, and approvals.

Context

Mover governance is the identity lifecycle problem that sits between onboarding and offboarding, but it rarely behaves like either. The issue is not whether access should change, but when role changes are complete enough to justify removing old permissions and adding new ones.

That timing gap is what creates entitlement creep. In practice, people move between teams, projects, and responsibilities before their access model catches up, so the identity programme ends up preserving access that no longer matches the current job.

For IAM and IGA teams, this is a programme design problem as much as a workflow problem. If the mover event is not formalised, access reviews, provisioning, and approvals will always arrive after risk has already accumulated.

Key questions

Q: What breaks when mover events are not formalised in JML governance?

A: 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.

Q: Why does access creep happen when employees move between roles?

A: It happens because role changes are often gradual, ambiguous, and cross-functional, while access governance assumes a clean handoff. If revocation is not explicitly tied to the move, legacy permissions remain attached and the account slowly accumulates history instead of reflecting current duties.

Q: How should security teams handle transitional access during internal moves?

A: They should separate temporary transition access from long-term entitlements, give the overlap a clear end point, and review it as part of the move itself. Transitional access should support continuity, not become a permanent exception that defeats least privilege.

Q: How do managers and IAM teams prevent mover drift across departments?

A: They need a shared mover process that links HR, IT, security, and managers to the same event definition. When the organisational record, the ticketing workflow, and the access policy all move together, the chance of stale permissions surviving the transition drops sharply.

Technical breakdown

Why mover events break lifecycle triggers

Joiner and leaver processes usually rely on clear HR signals such as start dates and termination dates. Mover events are different because internal role changes are often partial, informal, or delayed in system records, so the access engine never sees a clean trigger. That makes automation brittle: a title change may happen before duties change, or duties may change without any HR record at all. The result is a governance gap where access remains valid in one system and obsolete in another.

Practical implication: design mover workflows around verified role-change signals, not just HR title updates.

Entitlement creep in role transitions

Entitlement creep occurs when a user keeps accumulating permissions as they shift roles, projects, or managers. In a mover scenario, the danger is not only excess access after the move, but also the tendency to keep legacy access because someone still ‘might need it’ for a transitional period. Without a deliberate revocation point, temporary overlap becomes permanent sprawl. Over time, the account no longer reflects one role but several historical ones, which weakens least privilege and complicates audit decisions.

Practical implication: separate temporary transition access from enduring access and review both on a defined schedule.

Why RBAC alone struggles with movers

Fixed role models work well when job functions are stable, but movers expose the limits of static RBAC because the same title can imply different tools, regions, or responsibilities. The article points to the need for more context-aware policies, including ABAC and task-based patterns, when access varies by team or assignment. This is not a rejection of RBAC. It is a reminder that role labels are too coarse when the underlying work changes faster than the role catalogue.

Practical implication: augment RBAC with contextual policy logic where role change does not map cleanly to a single access package.

Breaches seen in the wild

• Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Mover governance is a lifecycle discipline, not a cleanup task. Organisations that treat movers as a side effect of onboarding or offboarding end up managing access after the fact. The real problem is that the identity state changes before the governance state does, which means over-permissioning becomes the default unless mover events are explicitly modelled. Practitioners should treat role transition as a first-class lifecycle state.

Access reviews alone do not solve mover drift. Reviews are useful, but they are retrospective by design, and mover risk is created in the interval between the role change and the next certification cycle. That gap is where old entitlements persist and new ones accumulate. The operational lesson is that the control needs to move closer to the event itself, not just to the review calendar.

Mover access creep is the right named concept for this failure mode. It describes the way permissions remain attached to a person as responsibilities shift, creating a layered identity history that no longer matches the current job. This is especially visible when HR, IT, and managers each hold part of the truth but none owns the full revocation decision. The implication is that lifecycle governance must be continuous, not episodic.

Cross-functional silence is an access control issue. When HR updates, IT requests, and manager expectations are not synchronized, the mover event becomes a black hole for entitlement decisions. That is not just a process inefficiency. It is a structural governance weakness that keeps stale permissions alive and makes compliance evidence unreliable. The answer is coordinated ownership, not one more manual exception path.

Formal mover states should be treated as a governance primitive. Once an organisation recognises movement as its own lifecycle event, policies, reviews, and automation can align around transition windows rather than around the blunt joiner and leaver model. That is the only practical way to reduce drift without constantly overcorrecting access for people whose responsibilities are still changing.

From our research library:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• Read next: NHI Lifecycle Management Guide

What this signals

Mover access creep is the practical failure mode that appears when identity programmes rely on joiner and leaver logic to govern role changes. The access state lags the work state, so entitlement decisions happen after drift has already formed.

Access reviews remain necessary, but they are too late on their own for fast-moving organisations. The governance shift is to treat mover events as structured lifecycle changes that trigger policy evaluation at the moment of transition, not after the fact.

For practitioners

• Formalise mover as a distinct lifecycle event Trigger access changes from an explicit mover state, not from ad hoc manager requests or informal team reshuffles. Define when the move starts, which approvals apply, and when old access expires.
• Separate transitional access from permanent access Allow temporary overlap only for named duties during the transition period, and label those entitlements so they can be removed without affecting the destination role.
• Use contextual access policies for role variants Build access profiles around responsibilities, team context, and geography where a title alone is too coarse to govern what the person should still keep.
• Tie access reviews to known mover events Schedule certifications after promotions, transfers, and team restructures so reviewers can compare current access against the new operating context, not the old one.
• Close the HR to IT notification gap Require automated notifications from HRIS or manager-initiated changes into IAM and ITSM so access changes do not depend on manual follow-up across silos.

Key takeaways

• Mover governance fails when organisations treat internal role changes as informal exceptions instead of formal lifecycle events.
• The main risk is entitlement creep, where people retain legacy access after responsibilities have shifted.
• The control that matters most is a defined mover process with coordinated notifications, role-aware policy logic, and timely revocation.

Key terms

• Mover Governance: Mover governance is the set of identity controls that manage access when a person changes roles, teams, or responsibilities. It focuses on updating, removing, and validating permissions so the identity record matches the current job instead of preserving old access by default.
• Entitlement Drift: Entitlement drift is the slow accumulation of permissions that no longer match the original purpose, role, or workload. In cloud-native and NHI-heavy environments, it usually happens because access changes faster than review cycles, leaving organizations with more privilege than they intended.
• Transition Access: Transition access is temporary permission kept during a role change so work can continue while responsibilities shift. It needs a clear end point and explicit ownership, otherwise it becomes a disguised form of persistent access that weakens least privilege.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.