A mover flow is the access change path triggered when an employee, contractor, or account changes role, manager, status, or privilege boundary. It is often the most failure-prone part of identity governance because it must remove old access and grant new access in the same transition.
Expanded Definition
Mover flow describes the identity governance sequence that should happen when a person or account changes jobs, teams, reporting lines, contract status, or privilege boundary. It is not just an HR event. In NHI and IAM operations, it is the controlled re-evaluation of access so that obsolete permissions are removed and needed permissions are added without creating overlap, delay, or manual exception risk.
Definitions vary across vendors on whether mover flow is treated as a lifecycle event, an access recertification trigger, or a workflow category. NHI Management Group treats it as a governance transition that spans joiner, mover, and leaver controls, with special attention to service accounts, delegated access, and privileged entitlements. The operational goal is to preserve business continuity while preventing privilege accumulation, standing access, and inherited access that no longer matches the new role. This aligns closely with the NIST Cybersecurity Framework 2.0 emphasis on access governance and ongoing risk management.
The most common misapplication is treating mover flow as a simple add-only ticket, which occurs when old entitlements are not removed before new ones are granted.
Examples and Use Cases
Implementing mover flow rigorously often introduces workflow latency, requiring organisations to weigh clean access transitions against the cost of coordination across HR, IAM, PAM, and application owners.
- An engineer is promoted to team lead, and their production write access is removed while approval rights and reporting dashboards are added.
- A contractor moves from one project to another, and access to the first client’s repositories, secrets, and API keys is revoked before the second project’s access is provisioned.
- An account shifts from standard user to privileged operator, triggering step-up controls, tighter approval paths, and new monitoring expectations.
- A service account changes ownership after a system migration, requiring entitlement review, credential rotation, and confirmation that inherited permissions are still justified.
- During a role change, the access workflow checks existing assignments against the current job code and removes entitlements that no longer match the new function, consistent with guidance in the Ultimate Guide to NHIs.
These scenarios are often evaluated alongside access lifecycle patterns described by NIST and operational identity guidance from NHI Management Group, especially where the mover event affects privileged or machine-held access.
Why It Matters in NHI Security
Mover flow matters because identity risk often increases at the exact moment a role changes. If old access lingers, a user or NHI may retain rights that no longer fit the new task, and that gap can become a path for lateral movement, data exposure, or unauthorized administrative action. In NHI environments, the problem is amplified because service accounts, tokens, and API keys do not naturally “self-correct” when organisational structure changes.
This is one reason NHI Mgmt Group highlights that only 20% have formal processes for offboarding and revoking API keys, a signal that lifecycle control is still weak in many organisations. A mover event should therefore be handled as a security checkpoint, not an admin convenience. It also fits the access governance expectations in the NIST Cybersecurity Framework 2.0, where identity changes are part of ongoing protection and response discipline.
Organisations typically encounter the consequences only after a role change exposes stale access in an audit, incident review, or breach investigation, at which point mover flow becomes operationally unavoidable to address.
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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 | Mover events often create stale access and privilege creep in NHI lifecycles. |
| NIST CSF 2.0 | PR.AC-4 | Covers access permissions management during identity and role changes. |
| NIST SP 800-63 | Supports identity proofing and lifecycle assurance for account state changes. |
Require strong identity governance before changing authoritative access tied to an identity record.
