A mover is an identity whose role, responsibilities, or context has changed enough that its access should change too. The mover stage is where privilege drift starts if old permissions are not removed as carefully as new ones are added, creating excess access over time.
Expanded Definition
A mover is an NHI whose role, operating context, ownership, or downstream dependencies have changed enough that its access should be reviewed and adjusted. In practice, movers sit between stable identity states: they are not newly provisioned, but they are no longer safe to treat as unchanged. That distinction matters because privilege decisions tied to the old role often persist after the operational reality has shifted.
In NHI governance, mover handling is part of lifecycle control, not a one-time cleanup task. The goal is to remove access that is no longer justified before new access accumulates on top of it. This is closely aligned with the access review and least-privilege expectations described in the NIST Cybersecurity Framework 2.0, while NHI-specific guidance from Ultimate Guide to NHIs emphasizes that lifecycle drift is a core control problem. Definitions vary across vendors on whether mover status is triggered by job change, workload migration, environment change, or ownership transfer, so the operational rule should be explicit and documented.
The most common misapplication is treating a mover as a normal active identity, which occurs when old privileges are left in place after the role change is already approved.
Examples and Use Cases
Implementing mover handling rigorously often introduces coordination overhead, requiring organisations to balance fast operational changes against the cost of timely privilege recalculation and access removal.
- A service account that supported a legacy payment job is reassigned to a new pipeline, so its old database and queue permissions are removed before the new ones are granted.
- An API key used by a CI/CD workflow is moved from one repository to another, triggering a review of secrets scope, callback URLs, and deployment privileges.
- A workload migrates from a development cluster to production, requiring stricter network reachability, stronger secret handling, and narrower token permissions.
- An automation agent changes owners during an internal reorganisation, so approval paths, break-glass access, and logging expectations are revalidated.
- A third-party integration is repointed to a new tenant or business unit, and the original entitlements are revoked rather than copied forward.
For a broader view of how NHI movement contributes to exposure, Ultimate Guide to NHIs notes that many organisations struggle to maintain lifecycle visibility. That reality is why mover workflows should be tied to identity governance events and not left to ad hoc ticket handling alone.
Why It Matters in NHI Security
Mover handling is where privilege drift becomes measurable. If old access is not removed when context changes, an NHI can accumulate permissions across teams, environments, and tooling, creating broad attack paths that are difficult to detect during routine operations. This is especially dangerous for service accounts, API keys, and agent identities because they often operate without a human at the keyboard to notice that the scope is now wrong.
The risk is not theoretical. NHI Mgmt Group reports that Ultimate Guide to NHIs found 97% of NHIs carry excessive privileges, which shows how often movement without removal turns into standing over-permission. In Zero Trust programs, mover event should trigger reauthorization, secret review, and entitlement reconciliation under the same discipline reflected in NIST Cybersecurity Framework 2.0. The issue becomes visible only after an outage, audit finding, or compromise exposes permissions that no longer match the current role.
Organisations typically encounter the full cost of mover mismanagement only after an incident review or access audit, at which point the identity has already been operating with outdated privileges for weeks or months.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Mover events create privilege drift and stale access, which this control targets. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access must be revalidated when an identity's role changes. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous reauthorization as identity context changes. |
Recalculate NHI access on every role change and remove permissions that no longer match current need.
