Privilege creep compounds in two directions for employee movers

At a glance

What this is: This is an analysis of how privilege creep builds in two dimensions during internal job moves, with access sprawl and permission inflation compounding together.

Why it matters: It matters because IAM and IGA teams often clean up leavers and onboard joiners, but movers can quietly retain old access and elevated rights across multiple roles and teams.

Context

Privilege creep is not just a matter of too many accounts or too many admin roles. In internal moves, the same identity can keep old access while also gaining new access and higher privilege, which makes the problem larger than a simple provisioning error.

For identity governance, that means joiner-mover-leaver workflows need to treat role changes as reconciliation events, not just entitlement additions. When movers are handled as additive cases, stale access and obsolete admin rights survive across the employee lifecycle.

Key questions

Q: What breaks when internal moves are handled only as entitlement additions?

A: When movers are processed only as additions, the old role never gets reconciled. That leaves stale access, retained admin rights, and a growing privilege footprint that no longer matches the employee’s current responsibility. The failure is structural: the workflow adds for the future but does not subtract for the past.

Q: Why do internal role changes create more privilege risk than joiners or leavers?

A: Joiners start from a baseline and leavers are supposed to be fully removed. Movers are different because they keep prior access while acquiring new access for the next role. That makes them the highest-risk cohort for entitlement carryover, stale admin rights, and cross-team overexposure.

Q: How can security teams tell whether mover workflows are actually working?

A: Look for evidence that access is removed as often as it is added, that app owners can approve changes quickly, and that periodic reviews catch stale entitlements. If employees keep old access after moving teams, the workflow exists on paper but not in practice.

Q: Should organisations review access and admin rights together for internal role changes?

A: Yes. Separate reviews miss the combined risk of broad access with excessive privilege. An account can look acceptable on one dimension and still be overexposed on the other. Reviewing them together is the only way to see how far a mover has drifted from the current job need.

Technical breakdown

Horizontal expansion and vertical escalation are the same failure mode

Horizontal expansion is the growth of application access over time, while vertical escalation is the growth of privilege within those applications. In the article’s example, both happened together: access kept increasing as the employee moved roles, and admin rights accumulated inside systems already granted. The technical issue is not simply overprovisioning. It is the absence of a control that reconciles both the application inventory and the privilege level attached to each entitlement after every internal move.

Practical implication: Review movers against both access count and privilege count, not one or the other.

Why movers defeat additive JML workflows

Typical JML processes are designed to add access for a new job and revoke access when someone leaves. Movers sit between those two states, so the process often only executes the provisioning half. The result is a retained base of old entitlements plus new access grants and new admin assignments. In practice, the workflow needs a subtraction step as part of every role change, otherwise each move becomes an accumulation event rather than a recalibration event.

Practical implication: Build mover workflows that remove old access and downgrade obsolete privilege during the same change request.

The blast radius grows when old admin rights survive role changes

When old admin roles remain active, the damage is not limited to excess access volume. Elevated rights in systems tied to prior teams or functions create cross-team privilege chains and make compromise more consequential. An attacker who lands on that account inherits legitimate reach into multiple environments and control planes without needing to exploit a separate privilege-escalation path. That is why retained admin access is more dangerous in movers than in static users.

Practical implication: Map retained admin roles across prior teams and revoke elevation that no longer matches current responsibility.

Threat narrative

Attacker objective: Exploit an employee’s accumulated access to move laterally and act with unnecessary privilege across multiple systems.

1. Entry occurs through a legitimate employee account that has accumulated access across multiple role changes rather than through an exploit.
2. Credential use is already powerful because the account still holds old application access and elevated permissions from earlier positions.
3. Escalation is compounded by role changes that keep adding access and admin rights without removing previous entitlements.
4. Impact is broader blast radius, because one compromised mover account can pivot across teams and perform privileged actions in systems no longer tied to the current role.

Breaches seen in the wild

• Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

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

NHI Mgmt Group analysis

Privilege creep in movers is a two-dimensional governance failure, not a single entitlement problem. The article shows that internal role changes can add more systems on one axis and higher privilege on another, creating compounding exposure instead of simple drift. That distinction matters because a programme that only measures app count or only measures admin count will miss the real control failure. Practitioners need a mover model that treats access and privilege as separate but linked inventories.

Joiner-mover-leaver design still behaves as if movers are a minor edge case. The article makes clear that movers are often the largest source of accumulation because the workflow is additive by default. New role requests are processed, but old access and old elevations are rarely reconciled with equal rigor. That is a structural gap in identity governance, not a staffing issue, and it should be treated as such.

Horizontal access sprawl and vertical privilege inflation should be governed as one blast-radius metric. The article’s strongest insight is that an account with broad access and elevated rights is materially different from an account with only one of those conditions. That combined footprint is what creates compounding risk across teams and systems. In governance terms, the unit of concern is no longer entitlement volume alone, but the total privilege footprint left behind by each move.

Access reviews are too late if they only see the final state of a mover account. By the time a review flags a director with dozens of apps and multiple admin roles, the accumulation has already happened through earlier transitions. The useful governance question is not just who has access now, but which role changes created residual privilege that was never retired. Organisations should make mover reconciliation a lifecycle control, not an audit afterthought.

Privilege creep from internal moves is now a named control gap worth tracking explicitly. The pattern has a clear shape: each move adds new rights, retains old ones, and leaves obsolete privilege in place. That makes mover-driven accumulation distinct from ordinary entitlement drift and deserving of its own governance label. Security and IAM teams should report on mover accumulation as a separate risk class, because the remediation logic is different from joiner or leaver cleanup.

What this signals

Two-dimensional privilege creep needs its own governance lens. Internal moves are not just a provisioning event. They are a reconciliation problem across both access scope and privilege level, and organisations that track only one of those dimensions will underestimate their exposure.

Residual access after a role change is the real mover risk. The practical signal is simple: if a person can move teams or levels and keep the same old access, the governance model is too additive. Access review and recertification need to expose what should have been removed, not just what was approved.

Privilege footprint should become a lifecycle metric. Security teams should measure how many applications and elevated roles survive each internal move, because that number reveals whether JML is functioning as a cleanup process or merely a provisioning queue.

For practitioners

• Define mover reconciliation as a required control Treat every internal role change as both an add and remove event. The change ticket should request new access, identify obsolete access to revoke, and specify any admin rights that must be downgraded before the move is closed.
• Track horizontal and vertical drift together Build reporting that shows application count, admin role count, and change history in one view. A mover should be flagged when access expands without a matching reduction in old entitlements or when privilege rises across multiple role transitions.
• Review cross-team access after each promotion or transfer Check whether the account still holds access to tools owned by prior teams and whether elevated permissions remain in systems the employee no longer manages. Remove both when they are no longer justified by current responsibilities.
• Use mover-specific access reviews Separate movers from static employees in recertification so reviewers can see what was inherited from previous roles. The review should focus on stale access, obsolete admin rights, and permissions that survived the last transition.

Key takeaways

• Internal role changes can create privilege creep in two directions at once, with access sprawl and admin inflation compounding over time.
• The article’s example shows how a mover can end up with 52 applications and 14 admin roles after repeated moves, illustrating how quickly residual privilege can build.
• The control gap is not the promotion itself, but the failure to remove old access and downgrade obsolete rights during the same lifecycle event.

Key terms

• Privilege Creep: Privilege creep is the gradual accumulation of access rights beyond what an identity actually needs. It usually happens when permissions are added for convenience and never removed. For NHIs, privilege creep expands blast radius and makes old credentials far more dangerous than their original purpose suggests.
• Horizontal Expansion: Horizontal expansion is the growth of a user’s access footprint across more applications, systems, or teams. In identity governance, it becomes a problem when each move adds new reach but old team access remains active, creating cross-functional exposure and stale entitlements.
• Vertical Escalation: Vertical escalation is the accumulation of higher privilege inside systems, such as admin or owner roles. It is not the same as broader access. The control concern is that elevation granted for one role often persists after the role changes, leaving excess control behind.
• Mover: A mover is an identity whose role, responsibilities, or context has changed enough that its access should change too. The mover stage is where privilege drift starts if old permissions are not removed as carefully as new ones are added, creating excess access over time.

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.