The Mover Problem: Automating Access Changes When Employees Change Roles
The Mover Problem: Automating Access Changes When Employees Change Roles
TL;DR
- The mover problem occurs when employees receive access for a new role but keep permissions from previous responsibilities.
- Mover access automation should calculate both sides of a role change: what access must be added and what should be removed.
- HR events such as department, title, location, manager, or employment changes can trigger access reassessment.
- Do not automatically remove everything associated with the previous role. Some legitimate access may still be required.
- Temporary handover access should have an owner and expiration date.
- The workflow should finish with fulfillment, reconciliation, exception handling, and evidence showing what actually changed.
A Promotion Adds Access. Who Removes What Came Before?
An employee spends three years in Accounts Payable.
They can create vendors, view invoices, run reports, and manage several finance-system permissions.
Then they move into Procurement.
The new manager immediately requests procurement applications and supplier-management access. Those requests are approved because the employee needs them to start the new role.
Nothing removes the old finance permissions.
A year later, the employee moves again.
Another set of access is added.
This is the mover problem.
It is different from onboarding and offboarding because the identity remains active. There is no obvious moment when administrators feel compelled to remove everything.
Effective mover access automation treats an internal role change as an access recalculation event—not simply a reason to provision more permissions.
The question becomes:
What should this person have now, and what access no longer belongs?
What Is the Mover Problem in Identity Governance?
A mover is an employee or other workforce identity whose organizational context changes while their relationship with the company continues.
Mover events can include:
- promotion
- department transfer
- job-title change
- location change
- manager change
- business-unit transfer
- temporary assignment
- contractor-to-employee conversion
- project reassignment
These events matter because access was often granted using the person’s previous responsibilities.
When responsibilities change but permissions do not, access can accumulate.
That accumulation is commonly described as privilege creep or access creep.
NIST SP 800-53 AC-2 explicitly connects account management with employee transfers and changes in need-to-know. It also calls for account management processes to align with personnel transfer processes.
The control problem is therefore not simply provisioning the new role.
It is keeping access aligned as the person’s business context changes.
Why Are Movers Harder Than Joiners and Leavers?
Joiners and leavers usually provide clear signals.
A joiner needs access.
A leaver generally needs access removed.
A mover requires comparison.
Suppose someone transfers from Operations to Finance.
Some access should be removed.
Some should be retained because both roles use it.
Some new access should be added.
One temporary permission may need to remain for a 30-day handover.
One requested finance entitlement may conflict with another permission the employee still holds.
That makes the mover event a change-of-state problem.
Modern identity lifecycle management approaches recognize this distinction by treating role changes as events that may add, update, or remove access as employees move between roles, teams, or locations.
What Goes Wrong When Mover Access Is Managed Manually?
A common process looks like this:
- HR updates the employee’s new role.
- New manager submits access requests.
- IT grants the requested access.
- Nobody receives a complete list of old permissions.
- Access removal waits until the next certification campaign.
This creates several problems.
Old access has no requester pushing for removal
New access affects productivity, so someone follows up.
Removing obsolete access usually has no equivalent business urgency.
Application ownership is fragmented
One manager may know what the new employee needs but not what they held in previous systems.
Historical access looks legitimate
Six months later, another reviewer may assume an old permission exists for a valid reason because it has already survived several months.
Access reviews become cleanup exercises
Periodic access reviews start discovering permissions that should have been addressed when the employee moved.
Mover automation changes the control from detect later to recalculate when the change occurs.
How Should Mover Access Automation Work?
A strong mover workflow should evaluate the identity’s previous state against the new expected state.
1. Detect a Trusted Workforce Change
Start with an authoritative event.
Depending on your environment, that could come from an HR system or another approved identity source.
Possible trigger attributes include:
- department
- job code
- job title
- location
- manager
- worker type
- legal entity
Not every change should trigger access updates.
For example, a manager change may affect approval routing without changing application permissions.
Define which attributes have governance meaning before automating them.
2. Establish the Employee’s New Expected Access
Determine the standard access associated with the new responsibility.
This can be based on:
- approved identity profiles
- role definitions
- access templates
- department rules
- location rules
- approved attribute combinations
With SecurEnds Identity Lifecycle Management, we support attribute-based identity profiles using information such as title, location, and department, with lifecycle automation for transfers.
The objective is to establish a defensible baseline for the new position.
3. Compare Existing Access With the New Baseline
This is the part that solves the mover problem.
Create three buckets:
| Access Category | Action |
| Required in both roles | Retain |
| Required only in the new role | Add |
| Associated with the old role and no longer justified | Remove or review |
Do not simply run the new role’s provisioning workflow.
Calculate the delta.
With SecurEnds Access Analysis, we can help identify common entitlement patterns and use those patterns to inform reusable Access Templates for similar roles or business groups.
4. Route Ambiguous Access for Review
Not every old permission should be automatically removed.
An employee may retain responsibilities across teams.
They may be supporting a transition.
They may hold a specialist entitlement that is unrelated to department.
They may have access from an approved project assignment.
For uncertain permissions, create a targeted decision:
Does this access still have a valid business reason after the move?
Route it to an appropriate manager, application owner, entitlement owner, or security owner.
This avoids two bad outcomes:
- keeping everything
- removing legitimate access indiscriminately
What Should Happen to Temporary Handover Access?
Internal transfers often involve overlap.
A finance employee moving to procurement may need two weeks to close previous work.
That can be legitimate.
The mistake is treating temporary retention as an indefinite exception.
Record:
- access being retained
- business reason
- approving owner
- start date
- expiration date
- expected removal path
At expiration, remove the access or require a new decision.
This allows the organization to support operational handovers without turning them into permanent access creep.
Mover Automation Should Check for SoD Conflicts
A role change can create risk even when every individual entitlement appears legitimate.
Consider an employee moving into a role that approves payments while retaining an old permission to create vendors.
Neither permission is necessarily inappropriate alone.
Together, they may create a segregation-of-duties concern.
Mover workflows should therefore consider whether the combination of:
existing access + newly required access
creates a policy conflict.
NIST account-management guidance also calls for closer attention to privileged role assignments and revocation when those assignments are no longer appropriate.
For higher-risk moves, evaluate the complete access combination rather than only the new entitlements.
How Do You Handle Applications That Cannot Be Automatically Updated?
Mover automation does not require every application to support direct provisioning.
You may have:
- SaaS platforms with automated provisioning
- Active Directory or Entra-based access
- database applications
- ERP platforms
- custom business applications
- legacy systems requiring administrators
The workflow can use different fulfillment methods.
Supported automated target
Provision or revoke access directly.
Service-management workflow
Create a controlled fulfillment task.
Administrator-managed legacy application
Assign the specific change to the application owner or administrator and track completion.
With our lifecycle and integration approach, we can support governance across different application types. The exact fulfillment method still depends on the target system and configured integration.
The important requirement is that manual fulfillment does not become invisible fulfillment.
Reconcile the Access After the Move
A workflow should not close merely because provisioning actions were sent.
Suppose five obsolete permissions should be removed.
Four disappear.
One remains because the target application failed.
The employee is still overprivileged.
A stronger mover workflow is:
HR event → calculate expected access → approve exceptions → fulfill changes → refresh application data → compare expected and actual state → remediate differences → close
This produces better evidence than simply recording:
Role-change workflow completed.
The control outcome is the new access state.
What Metrics Should You Track for Movers?
Mover-specific metrics can reveal whether privilege creep is actually being reduced.
Mover events processed
How many role, department, or relevant attribute changes occurred?
Old access removed
How many entitlements were identified as no longer required?
Mover deprovisioning lag
Time between the effective role change and removal of obsolete access.
Exceptions created
How often is prior-role access intentionally retained?
Expired exceptions still active
Temporary access that survived beyond its intended period.
Reconciliation failures
Changes reported as complete that do not match target-system access.
Access found later during certification
How much stale access from previous roles is still being discovered during periodic reviews?
The last metric can tell you whether your mover process is preventing privilege creep or simply postponing cleanup.
What Should Buyers Test in Mover Access Automation Software?
Do not evaluate lifecycle software using only a new hire and termination.
Create a real mover scenario.
For example:
Current role: Accounts Payable Analyst
New role: Procurement Specialist
Then ask the vendor to demonstrate:
- What event detects the move?
- Which employee attributes drive the change?
- How is new expected access calculated?
- How is old access identified?
- Which permissions are retained automatically?
- Which require review?
- Can temporary overlap expire?
- Are SoD conflicts evaluated?
- How are disconnected applications handled?
- How is completed removal verified?
- What evidence remains for audit?
This is a stronger lifecycle test because it forces the platform to handle both provisioning and subtraction.
How We Support Mover Access Governance at SecurEnds
At SecurEnds, we treat role changes as lifecycle events that should trigger a reassessment of access—not simply another round of provisioning.
Our Identity Lifecycle Management capabilities support attribute-based identity profiles and lifecycle automation for transfers, provisioning, and deprovisioning.
We can also use access patterns and Access Templates to help establish repeatable expected access for similar roles or business groups.
For organizations using supported HR and downstream integrations, workforce changes can feed governed access workflows across the environment.
A useful evaluation is to give us one of your real role-change scenarios and test:
workforce event → new access baseline → identify obsolete access → route exceptions → fulfill additions/removals → verify target state → retain evidence
That gives your team a clearer view of how mover governance would operate in your environment.
Best Practices for Solving the Mover Problem
- Treat every move as both an add and remove event.
A role change should not only provision new access. Review what the employee already holds and remove permissions that no longer match the new responsibility. - Use authoritative workforce data.
Trigger mover workflows from trusted HR or identity-source changes. This reduces dependence on IAM teams manually discovering department, role, or location changes. - Define expected access before automating.
Establish approved profiles or Access Templates for important roles. Business and application owners should confirm what access genuinely belongs in each baseline. - Calculate the access delta.
Compare the employee’s current access with the access expected for the new role. Retain shared permissions, add missing access, and identify obsolete entitlements for removal. - Protect legitimate overlapping responsibilities.
Do not blindly remove every permission associated with the previous role. Some employees may temporarily support both functions or retain specialist responsibilities. - Expire temporary handover access.
If old-role access must remain during a transition, assign an owner and end date. Revoke it when the handover finishes unless another approval extends it. - Check sensitive access combinations.
New permissions may become risky when combined with entitlements from the previous role. Review SoD and privileged-access conflicts before completing the move. - Reconcile important removals.
Do not assume that a deprovisioning request succeeded. Verify that target applications actually reflect the intended access change before closing the workflow. - Document the complete change.
Preserve the role-change trigger, old and new access, approvals, removals, exceptions, fulfillment, and final state. This creates clearer evidence for future reviews and audits.
Frequently Asked Questions
What is the mover problem in IAM?
The mover problem occurs when an employee changes roles, departments, locations, or responsibilities but their previous permissions are not updated appropriately. New access is often added quickly while obsolete access remains, causing permissions to accumulate over time.
What is mover access automation?
Mover access automation uses workforce events and identity-governance policies to recalculate access when someone’s organizational role changes. It can identify new required permissions, obsolete access, exceptions, approval requirements, and downstream provisioning or deprovisioning actions.
Why are movers harder to automate than joiners?
A joiner begins with relatively little existing access. A mover already has permissions that may need to be retained, removed, or temporarily extended. The workflow therefore needs to compare old and new access requirements rather than simply assign a standard baseline.
Should all old access be removed when an employee changes roles?
No. Some permissions may still be required in the new position or shared across both roles. The correct approach is to compare existing access with the employee’s new approved access model and remove only what is no longer justified.
How can organizations prevent privilege creep after internal transfers?
Use workforce changes as governance triggers, define expected access for important roles, compare current access against the new baseline, remove obsolete permissions promptly, time-limit temporary exceptions, and verify that deprovisioning actually occurred.
Should movers still be included in periodic user access reviews?
Yes. Automated lifecycle changes can reduce unnecessary access at the point of transfer, while periodic user access reviews provide another control for validating that retained access remains appropriate. The two controls complement each other rather than replace one another.
A Role Change Should Change Access in Both Directions
The mover problem exists because organizations are usually good at addition.
The new manager asks for access.
The employee needs to become productive.
IT completes the requests.
Subtraction gets less attention.
That is where access accumulates.
A stronger mover process makes an internal transfer a complete governance event:
Detect the change → calculate the new baseline → add what belongs → remove what does not → govern exceptions → verify the result
That keeps access aligned with the employee’s current job instead of preserving a history of every job they previously held.
If internal transfers are still creating manual access-cleanup work, explore SecurEnds Identity Lifecycle Management and test the workflow using a real employee mover scenario from your environment.
