How does the Mover Process work?

What the Mover Process is meant to change

The mover process is the access-governance response to a job change, not a one-time form update. Its job is to align access with the person’s new role, team, system set or location while removing rights that were only justified by the old position. That keeps entitlement decisions tied to current business need rather than historic convenience.

Because mover events often touch multiple systems, the process should treat access as a portfolio of entitlements rather than a single account change. A clean mover review checks what should be retained, what should be added through approval, and what should be removed because it now creates unnecessary standing privilege.

This is why mover handling sits naturally alongside Joiner-Mover-Leaver (JML) Guide and IAM and IGA Basics: the move is the trigger, but the control objective is entitlement governance, not just provisioning.

What good mover handling removes, adds and rechecks

A mover process should remove access that no longer matches the new job, grant only the new access that has been approved, and flag entitlements that are inherited, temporary or unusually broad. If the old role had privileged access, shared access, or access to sensitive environments, those rights deserve explicit review rather than automatic carryover.

The most useful practical question is whether the move changes the person’s need to perform the same functions in the same systems. If not, keep the change minimal. If yes, grant only the smallest access set that supports the new duties and document why each entitlement remains valid.

That logic is why the mover process usually benefits from Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and NHI Lifecycle Management Guide, because the same lifecycle discipline applies when privileges need to be changed, retired or re-certified after a transition.

Why mover failures create access creep

Move events are a common source of access creep because they are frequent, operationally messy and easy to treat as administrative churn. If the old entitlements are not removed, users keep permissions from two jobs at once, and that residual access can outlive the business reason for holding it.

Failure usually appears in one of three ways: teams grant new access without removing old access, the request workflow bypasses approval because the move is seen as routine, or nobody revisits whether inherited entitlements still match the new role. Over time, that creates excessive access that is harder to notice than a cleanly overprivileged new account.

For the same reason, Top 10 NHI Issues and the NIST Cybersecurity Framework 2.0 both support the core idea that entitlement drift is a control problem, not just an HR event.

Risk and Threat Considerations

Mover failures matter because they preserve access that the new job no longer needs. That creates unnecessary privilege, widens the blast radius of account compromise and can leave sensitive systems reachable long after the move should have narrowed access.

Failure mechanism: The business approves the role change, but downstream identity and access updates are incomplete, delayed or never recertified. Old entitlements remain active, new entitlements are overgranted to avoid delay, and the user ends up with a larger access set than either role justifies.

Impact: Excess access increases the chance of unauthorized data exposure, misuse of privileged functions, segregation-of-duties violations and lateral movement if the account is later compromised. It also makes access reviews less reliable because the entitlement record no longer reflects the actual job state.

Practitioner Guidance

What to verify: Treat the move as a before-and-after comparison, not a fresh account. Verify which systems, roles and group memberships were justified by the old position, which are justified by the new one, and which need explicit exception handling because they straddle both.

Decision rule: If an entitlement is not clearly required for the new role, remove it rather than keeping it on the assumption that it might still be useful. If the move introduces higher privilege, require a named approval path and recertification rather than silent expansion.

Practitioner takeaway: The quality of a mover process is measured by how well it removes obsolete access, not by how quickly it adds new access.

Related resources from NHI Mgmt Group

• What breaks when joiner-mover-leaver flows are not tied to real work changes?
• What breaks when deprovisioning is not tied to the joiner-mover-leaver process?
• Why do access reviews matter if joiner-mover-leaver workflows already work?
• How should compliance teams build KYB so UBO checks and AML screening work as one process?