The workflow logic that handles role changes by granting new access and removing outdated access in the same event. In mature identity programmes, mover logic prevents permission accumulation and reduces the gap between business change and access correction.
What mover logic does in an identity workflow
Mover logic is the workflow step that updates access when a person changes roles, teams, locations, or responsibilities. It grants the new access the job now requires and removes access that no longer fits the new position.
Its purpose is to keep access aligned to current business need in the same change event, rather than waiting for separate manual cleanup. That matters because role changes are one of the most common places where stale privileges accumulate.
Why mover logic matters for access accuracy
Mover logic sits between business change and access change. Without it, a promotion, transfer, or reassignment can create a period where the user has both the old access and the new access, or where needed access arrives late.
That gap creates joiner-mover-leaver drift, which is why mature programmes treat movers as a distinct lifecycle event rather than a minor variant of onboarding or offboarding. The same lifecycle discipline is also central to IAM and IGA Basics, where entitlement changes, access reviews, and governance need to stay synchronized with real-world role changes.
For non-human access, the same logic applies to service accounts, workload identities, and other machine-held entitlements. A role change should not leave behind unused permissions, shared access paths, or secrets that no longer match the new operational need, which is why the NHI Lifecycle Management Guide is relevant to mover-style access correction.
How mover logic reduces permission creep
The key security value is symmetry: access that is added for the new role should be balanced by removal of access tied to the old role. That reduces permission creep, limits overprivilege, and makes entitlement state easier to explain during review or audit.
Well-designed mover logic usually relies on authoritative role or job data, controlled entitlement mapping, and clean deprovisioning of outdated access. The better the source data and access model, the less likely it is that mover event leave behind contradictory permissions or exceptions that outlive the business need.
Strong mover handling also supports access governance across both human and non-human populations, because organisations increasingly manage mixed estates of staff, contractors, bots, services, and applications through the same identity control plane. The broader lifecycle and governance pattern is reflected in Lifecycle Processes for Managing NHIs.
Where mover logic can fail
Mover logic fails when role data is incomplete, entitlement rules are stale, or downstream systems do not process the change consistently. In that case, access can be over-retained, under-granted, or corrected only after a manual ticket cycle.
Those failures are especially visible when organisations rely on fragmented identity sources or keep special-case permissions outside the normal lifecycle flow. Mature governance programmes treat mover handling as a control point, not just a workflow convenience.
Risk and Threat Considerations
Mover logic creates risk when a role change is processed incompletely, because the user may retain access that should have been removed or may receive new access before old access is revoked. That can expose sensitive systems, create segregation-of-duties conflicts, or leave a short but meaningful window for misuse.
Failure mechanism: Entitlements are not updated atomically across connected systems, so old permissions persist after a move or are rebuilt from outdated source data.
Impact: Access creep, unauthorized use of legacy privileges, audit findings, and a larger blast radius if the account is later abused or compromised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Mover logic updates account entitlements when roles change. |
| AC-6 — Least Privilege | Mover logic prevents users from retaining access beyond current job need. | |
| IA-5 — Authenticator Management | Mover events often require changing or revoking credentials tied to old access paths. | |
| Recommendation — Automate role-change entitlement updates under AC-2 to remove obsolete access promptly. Apply AC-6 to strip outdated privileges during mover events and keep access minimal. Use IA-5 to rotate or revoke credentials that no longer match the new role. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Mover logic operationalizes access control by keeping permissions aligned to changed roles. |
| Recommendation — Update access-control records and entitlements when a user moves roles or responsibilities. | ||
| CIS Controls v8 | CIS-5 — Account Management | Mover logic is a lifecycle account-management function that prevents stale access. |
| Recommendation — Remove outdated access and adjust account assignments immediately after a role change. | ||
Practitioner Guidance
What to watch for: Treat mover logic as a governance control with operational consequences, not as a convenience feature. If role changes regularly require manual exceptions, the underlying role model, entitlement mapping, or deprovisioning path is probably too brittle to keep access aligned at scale.
Practitioner takeaway: The best mover logic makes access correction automatic, timely, and auditable, so business change does not outpace identity governance.