The mover state is the mid-lifecycle condition where an identity remains active but its access requirements change because the person, role or business context changes. It is a key governance state in IAM because many compliance failures happen when teams track birthrights and exits but ignore transfers.
What the mover state means in IAM governance
The mover state is the point in the identity lifecycle where access must be re-evaluated because the person has changed jobs, responsibilities, teams, locations, or business context. It is not a new account event, but a change event that should trigger entitlement review.
This is why mover handling sits at the center of identity governance. When organisations focus only on joiners and leavers, they often preserve access that made sense in the old role but no longer fits the current one.
Why mover state matters operationally
Mover state matters because access rarely becomes wrong all at once. It drifts as role changes accumulate, which is how least privilege erodes quietly over time. Joiner-Mover-Leaver (JML) Guide treats movers as a distinct lifecycle step because old-role access should be removed, not just left in place alongside new access.
The practical issue is that movers can inherit both the old and the new permission sets. That creates excessive access, separation-of-duties conflicts, and a higher chance that dormant entitlements remain available long after the business need has changed.
How mover state differs from joiner and leaver states
Joiner states are about initial provisioning, and leaver states are about removal. Mover state is different because the identity stays active while the access model must change. That makes it a governance checkpoint rather than a simple onboarding or offboarding task.
IAM and IGA Basics frames this distinction clearly by separating authentication, authorization, provisioning, and access review. In mover scenarios, the core question is not whether the identity still exists, but whether its entitlements still match the current business role.
This is also where role-based access, attribute-based access, and entitlement governance matter most. A well-run mover process should reconcile role changes against current access, not merely add new permissions on top of the old ones.
What can go wrong when mover events are missed
When mover events are not detected or acted on, access creep becomes structural rather than accidental. Top 10 NHI Issues shows the same pattern in machine and application identities, where stale privileges, ownership gaps, and weak visibility create persistent exposure.
For human identities, the failure mode is similar: the account still works, but it now carries permissions that no longer align with the person’s actual duties. That increases insider-risk surface, audit findings, and the chance that sensitive systems remain reachable without a current business justification.
Risk and Threat Considerations
Mover state creates risk because it is the lifecycle moment where old access is most likely to survive a business change. If teams do not remove outdated entitlements quickly, the identity can retain access to systems, data, or functions that the new role does not require.
Failure mechanism: The mover event is missed, delayed, or only partially processed, so the account keeps legacy entitlements alongside new ones. That produces privilege accumulation, segregation-of-duties violations, and a wider window for misuse or abuse of access.
Impact: The result can be overprivilege, audit failure, unauthorized access to sensitive resources, and a higher blast radius if the account is compromised or misused.
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 surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Mover state requires updating and reviewing active account access as roles change. |
| AC-6 — Least Privilege | Mover handling prevents legacy access from persisting after a role change. | |
| IA-5 — Authenticator Management | Mover events often require rotating or reissuing credentials tied to changed access. | |
| Recommendation — Update account entitlements promptly when a user changes roles or responsibilities. Remove access that is no longer required after a mover event. Reissue or revoke authenticators when a role change affects credential use. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Mover state is an access-rights review and adjustment problem in the identity lifecycle. |
| A.5.16 — Identity management | Mover state depends on keeping identity records aligned with current business context. | |
| Recommendation — Review and adjust access rights whenever an employee's role changes. Keep identity records and role assignments current after internal transfers. | ||
| CIS Controls v8 | CIS-5 — Account Management | Mover events require controlled account changes, removal, and review of stale access. |
| Recommendation — Remove outdated access when accounts move to new roles or functions. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Mover state shares lifecycle governance with timely access removal when identity context changes. |
| Recommendation — Reconcile legacy access during lifecycle transitions before it becomes stale. | ||
Practitioner Guidance
What to watch for: Treat mover events as a governance trigger, not an administrative afterthought. The key operational question is whether role, manager, location, or function changes automatically drive access review and entitlement removal before the old access becomes stale.
Practitioner note: The strongest mover controls are usually the simplest ones: accurate source-of-truth data, timely recertification, and explicit removal of no-longer-required access. If those three are weak, mover risk will reappear even when joiner and leaver controls look mature.
Related resources from NHI Mgmt Group
- What breaks when identity detection does not see joiner, mover, and leaver state?
- Who is accountable when an AI agent exposes credentials or changes identity state?
- Why do mover-leaver processes miss so many non-human identities?
- How should security teams implement state, nonce, and PKCE together in OIDC flows?