Why do mover events create privilege creep so quickly?

Why This Matters for Security Teams

Mover events are dangerous because they change what an identity needs faster than governance processes can remove what it no longer needs. The access review problem is not the move itself, but the lag between a role change, project handoff, or temporary coverage assignment and the cleanup of old entitlements. That lag is where privilege creep becomes routine.

This is especially visible in environments that already struggle with visibility. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs — Key Challenges and Risks, which is a warning sign for teams that rely on periodic certification alone. The same pattern applies to human identities when transfer workflows and access removal are not tightly linked. OWASP’s OWASP Non-Human Identity Top 10 frames this as an identity lifecycle issue, not just an access request issue.

In practice, many security teams encounter privilege creep only after audit findings, service outages, or a lateral movement incident has already exposed it.

How It Works in Practice

A mover event often starts with a legitimate business change: a new team, a new application, an interim manager, or a temporary project. The problem is that access grants are easy to add and hard to fully subtract. If a person moves from one function to another, old group memberships, shared mailbox access, admin rights, data exports, and emergency coverage permissions can remain in place because each entitlement was justified at the time it was added.

That creates cumulative privilege. A mature program needs a joiner-mover-leaver process that treats movers as a full entitlement reconciliation event, not a simple delta update. Best practice is evolving toward explicit removal logic, ownership checks for every access package, and current-state visibility before any new access is approved. The same operational lesson appears in the Ultimate Guide to NHIs — Key Challenges and Risks: without lifecycle control, excess privilege becomes the default.

• Compare current entitlements against the new role before granting anything additional.
• Revoke access tied to the old function unless a documented exception exists.
• Require business owners to revalidate temporary coverage permissions with an expiry date.
• Use policy-as-code or access rules that evaluate whether the mover still needs each entitlement now.

For teams aligning to identity guidance, the principle is consistent with the OWASP Non-Human Identity Top 10: entitlement sprawl is a lifecycle control failure, not an isolated admin mistake. These controls tend to break down in large federated organisations because access is distributed across HR, IAM, application owners, and local support teams, so no single workflow sees the full picture.

Common Variations and Edge Cases

Tighter mover controls often increase workflow overhead, requiring organisations to balance faster business changes against more frequent access review and revocation activity. That tradeoff is real, especially where teams move often or where shared services support multiple departments. Current guidance suggests the highest-risk movers are not the obvious promotions, but the silent transitions: acting roles, cross-functional projects, mergers, contractor-to-employee conversions, and emergency backfills.

There is no universal standard for exactly how much access should be removed on every move, because the right answer depends on data sensitivity, segregation-of-duties rules, and how the organisation defines role overlap. A common failure mode is assuming that a transfer preserves most prior access because the person is “still trusted.” Trust is not the control. Current necessity is the control.

Where visibility is poor, mover events also hide dormant excess access that only becomes obvious during incident response or entitlement recertification. That is why NHI Mgmt Group highlights both visibility gaps and the high rate of excessive privileges in its Ultimate Guide to NHIs — Key Challenges and Risks. In mature programs, movers are treated as a reset point. In immature ones, they become the mechanism by which yesterday’s access quietly survives into the next role.

Related resources from NHI Mgmt Group

• Why do ITSM-based access workflows create privilege creep?
• Why do mover events create more risk than joiner or leaver events?
• Why do manual IT processes create privilege creep?
• Why do mover events create so much access risk in IAM programmes?