The risk created when users or service identities change roles, systems, or responsibilities and retain permissions that no longer fit. This is one of the most common sources of privilege accumulation because the identity has not left, but its access should have changed.
What mover risk means in practice
Mover risk is the security gap that appears when a person, service account, workload, or other identity changes role, system, team, or responsibility, but its access is not updated fast enough. The identity has moved, while its permissions have not.
This is usually a governance and lifecycle problem, not a one-time misconfiguration. The core failure is stale authorization, where old access remains valid after the business need has changed, creating privilege accumulation and unnecessary trust.
Why mover risk matters
Movers sit at the point where access should be re-evaluated, because role changes often alter what data, systems, and administrative functions are appropriate. If those changes are not reflected in entitlements, the result is excess privilege that can outlast the business event that justified it.
The issue is especially important in environments with shared platforms, delegated administration, or automated access paths. The same lifecycle weakness that affects a person can also affect machine and service identities, where old permissions can remain attached to a workload long after its purpose has shifted.
Common ways mover risk shows up
Mover risk often appears as role creep, inherited access that is never pruned, or access reviews that confirm what an identity has rather than what it still needs. It can also emerge when teams treat a transfer as an HR event instead of an authorization change.
It is closely related to Joiner-Mover-Leaver (JML) Guide, because movers are the point where old access must be removed and the new access model must be re-established. It also aligns with IAM and IGA Basics, where entitlement governance and access review are central to keeping permissions tied to current job function.
How organizations reduce mover risk
Effective handling depends on treating role change as a trigger for access recalculation, not as a notification that the move already happened. That means ownership, approval, and review processes must be able to identify which permissions are no longer justified and which new ones are actually required.
For non-human identities, the same principle applies to lifecycle management, especially when accounts, keys, tokens, or automation change purpose. NHI Lifecycle Management Guide and Top 10 NHI Issues both reinforce that stale permissions and poor lifecycle hygiene are recurring sources of overprivilege.
Risk and Threat Considerations
Mover risk becomes material when old access survives a legitimate role change, because that leftover access can be used for unintended activity, lateral movement, or privilege abuse. The problem is not just excess permission in the abstract, it is that an identity may now carry authority from a previous context that no longer applies.
Failure mechanism: Access is not revoked or re-scoped when the identity changes responsibility, so authorization remains broader than the current need and can be exploited by the holder or by anyone who compromises the identity.
Impact: Sensitive systems, administrative functions, and regulated data can remain reachable after the business justification has expired, increasing the chance of unauthorized action, audit findings, and breach amplification.
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 risk is a lifecycle account-governance problem where entitlements must track role changes. |
| AC-6 — Least Privilege | Mover risk directly creates excess permissions beyond current job need. | |
| IA-5 — Authenticator Management | Mover events often require refreshing or retiring credentials, tokens, or keys tied to changed authority. | |
| Recommendation — Review and update account access when roles change, then revoke permissions that no longer match current duties. Reduce permissions to the minimum needed after each role change and remove inherited access that is no longer justified. Rotate or retire authenticators and related credential material when ownership or role changes. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Mover risk is an identity lifecycle control issue requiring current ownership and access mapping. |
| A.5.18 — Access rights | Mover risk arises when access rights are not amended or removed after a role change. | |
| Recommendation — Keep identities and their access assignments aligned to current roles and responsibilities. Revoke or adjust access rights promptly when a user or service changes function or ownership. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Mover risk is controlled by managing who can access what as responsibilities change. |
| CIS-5 — Account Management | Mover risk reflects stale accounts and permissions left behind across lifecycle events. | |
| Recommendation — Continuously review and correct access after transfers, promotions, and ownership changes. Track account changes through lifecycle events and remove access that no longer matches the role. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Mover risk for non-human identities includes leaving permissions behind after responsibility shifts. |
| NHI-05 — Overprivileged NHI | Mover risk frequently leaves NHI permissions broader than the new operating need. | |
| NHI-07 — Long-Lived Secrets | Mover risk often persists through credentials, keys, and tokens that outlive the old role. | |
| Recommendation — Remove or reassign NHI access when ownership or purpose changes. Re-scope non-human permissions to the current task after each move or ownership change. Shorten secret lifetimes and retire stale credentials when access requirements change. | ||
Practitioner Guidance
What to watch for: The strongest signal is a move event with no corresponding entitlement change. That includes promotions, transfers, team reorganizations, platform migrations, and service ownership changes where access still reflects the prior role.
Governance implication: Mover risk should be owned as part of identity lifecycle governance, with clear accountability for who approves removal, addition, and recertification of access after a change in role or responsibility.