How should IAM teams govern access changes after role moves?

How mover events should be governed

A role move should be treated as an access decision, not a clerical update. The governance question is whether the person still needs each entitlement in the new context, whether the old access is now excessive, and whether the move changes segregation-of-duties boundaries. If teams only update the title and leave entitlements untouched, they preserve stale privilege and make later reviews less trustworthy.

That is why mover handling belongs in the same control conversation as IAM and IGA Basics and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs: the lifecycle event is where entitlement scope changes, not after drift has already accumulated.

What access review should happen after a move?

Best practice is to revalidate the mover against the target role, then compare current entitlements to the role's approved access profile. Anything no longer justified by business need should be removed, and anything newly required should go through the normal request and approval path. That keeps access changes auditable and prevents "carry forward" permissions from surviving by default.

In mature environments, the review should include direct roles, nested group membership, application-specific entitlements, privileged access, and any dormant access inherited from the prior function. If the moved employee now sits in a different reporting line or business unit, the entitlement review should reflect that new operating context rather than the old one.

The strongest internal navigation for this is the Authorisation Models Guide, because mover governance is really a question of how roles, attributes, and policies determine what should still be granted after the job change.

Why mover events create hidden privilege creep

Mover events are a common source of privilege creep because entitlement changes tend to lag behind HR changes. A user can accumulate old access from previous teams, temporary exceptions, project-based access, or inherited group membership, then keep it long after the need has expired. Over time, that broadens blast radius and makes it harder to prove least privilege.

The risk is larger in directory-driven environments and application estates where access is granted indirectly through groups, role templates, or automation. The visible role may change quickly, while the real permission footprint changes slowly, if at all. That gap is where overpermission quietly becomes normal.

For practitioners managing that risk at scale, the clearest operational reference is the Identity Security Programme Guide, because mover governance only works when ownership, review cadence, and remediation responsibility are explicit.

Risk and Threat Considerations

Mover events are a high-value control point because stale access often persists precisely when an employee becomes less visible to the original owning team. That creates unnecessary exposure, especially where old entitlements include privileged functions, sensitive data, or cross-environment access.

Failure mechanism: The role change is processed as a HR or workflow event, but the entitlement set is not fully revalidated, so previous access remains active and continues to expand the user's effective privilege.

Impact: Excess access increases the likelihood of misuse, accidental data exposure, unauthorized administrative actions, and audit findings tied to privilege creep or weak access governance.

Practitioner Guidance

What to prioritise: Start with entitlements that are most likely to outlive the move, shared groups, privileged roles, application-admin access, and exceptions granted for temporary projects. Those are the permissions most likely to survive unchanged unless someone explicitly challenges them.

What to verify: Confirm that the post-move access set is tied to the new role, not the old manager or legacy approval chain. Verify that the review includes indirect access paths such as group nesting and inherited application permissions, because those are the ones teams miss when they only inspect direct assignments.

Decision rule: If the moved user cannot justify an entitlement under the current role, remove it rather than waiting for the next periodic certification. If the entitlement is genuinely needed for transition work, time-box it and require a clear expiry.

Practitioner takeaway: The goal is not to preserve continuity of access, but to preserve continuity of legitimate business need; if the need changed, the access must change with it.

Related resources from NHI Mgmt Group

• How should IAM and PAM teams govern secret access after a role change or offboarding?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams stop access creep after role changes?