What happens when a mover workflow adds new access but does not remove old permissions?

The employee keeps the rights tied to the previous role while also receiving the new ones. That creates privilege creep, expands the attack surface, and can leave finance, administrative, or other sensitive access active after a role change. A mature mover workflow must recalculate entitlements, remove obsolete permissions, and confirm the final access state in the target systems.

What the missing deprovisioning step changes in a mover workflow

When a mover process grants the new role but leaves the old one in place, access becomes cumulative instead of conditional. That means the user is no longer operating under a clean role change, but under overlapping entitlements that can survive long after the move should have narrowed access. The practical result is privilege creep, weaker segregation of duties, and a larger blast radius if the account is later misused.

This is not just a housekeeping defect. In role changes, the security outcome depends on whether the workflow recalculates the target access state, not whether it merely adds the new permissions successfully. If the old access remains, the system has effectively accepted two roles at once, which can preserve finance, administrative, or privileged paths that the new job no longer requires.

That is why a mover event should be treated as a state transition, not an add-only update. The control objective is to converge the account on the final approved entitlement set for the new role, then verify that obsolete access was actually removed in the systems that enforce it.

Why privilege creep becomes a security and governance problem

Over time, untouched old permissions create accumulated access that may look legitimate in isolation but is excessive in combination. The issue is especially acute where access is role-based, because stale entitlements can quietly bypass least privilege and undermine access reviews that assume each role has a bounded entitlement set. A user may appear properly transferred while still retaining paths that were meant to be removed.

In practice, the problem also distorts accountability. If an incident occurs, it becomes harder to tell which permissions were intended for the current role and which ones were left behind by a failed mover action. That weakens auditability, complicates recertification, and can leave an organisation with access that no manager would consciously approve if it were presented as a single package.

For lifecycle-controlled access, the security question is not whether the new access exists, but whether the old access was fully retired at the same time. A mature process enforces both sides of the change: add what the new role requires, and remove what no longer fits that role.

What a sound mover workflow has to prove

A reliable mover workflow does three things well: it calculates the new entitlement set, removes superseded permissions, and confirms the final state after propagation. The confirmation step matters because entitlement changes often fail unevenly across applications, directories, and downstream systems, leaving a partial state that looks complete in the workflow but not in reality.

This is where access governance becomes operational rather than theoretical. The workflow should compare intended access against actual access, especially for sensitive systems where the old role may have created broad visibility or privileged functions. If the final state cannot be verified, the move is not finished from a security standpoint.

Where the business uses approvals or recertification, the mover event should also trigger a fresh evaluation of the new entitlement set. A role change is the right time to reassess whether the new access is still appropriately scoped, because the move often changes both the legitimate need and the risk profile.

Risk and Threat Considerations

Leaving old permissions in place creates a durable exposure because the account can continue to perform actions that no longer match the user’s current function. In a sensitive environment, that can turn a routine role change into unauthorized access, separation-of-duties failure, or an easier path for misuse if the account is later compromised.

Failure mechanism: The mover process updates the new role but does not revoke the prior entitlements, so the account retains overlapping access across multiple business functions and systems.

Impact: Stale access can persist unnoticed, expand the number of systems exposed to misuse, and create preventable audit, compliance, and incident-response problems when the retained permissions are eventually discovered.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Improper Offboarding	Mover failures can leave old entitlements active after role change.
	NHI-05 — Overprivileged NHI	Retained permissions create excessive access beyond the new role's need.
Recommendation — Revoke obsolete access paths when a mover changes role and verify the final entitlement state. Reduce entitlements to least privilege after each mover event and remove stale access.
NIST SP 800-53 Rev 5	AC-2 — Account Management	Account changes require timely updates and removal of obsolete access.
	AC-6 — Least Privilege	Old permissions left in place violate least-privilege access minimization.
	AC-2(3) — Disable accounts / manage account changes	Mover workflows must ensure prior access is removed when the account changes.
Recommendation — Update account attributes and deactivate unneeded permissions when a user's role changes. Limit retained access to the minimum required for the new job function. Disable or remove obsolete access as part of the role-change workflow.

Practitioner Guidance

What to verify: Treat a mover as incomplete until the target systems show the final entitlement state, not just the approval record. Verify that old permissions were removed from every authoritative enforcement point, especially where access is replicated across directories, applications, and SaaS platforms.

Decision rule: If the role change affects sensitive or privileged access, prioritise deprovisioning of obsolete rights before you consider the move closed. If the old access remains because a downstream system could not process the removal, treat that as an exception with an explicit owner and expiry.

Practitioner takeaway: The real test of a mover workflow is whether it ends with one coherent access state, not whether it managed to add the new rights. Add-only changes create hidden privilege accumulation, and hidden accumulation is exactly what access governance is meant to prevent.