Mover event

Expanded Definition

A mover event is an identity lifecycle change that can invalidate previously acceptable access, even when the person remains employed. In NHI governance, the key question is not whether the employee is “active,” but whether the access still matches the new job function, team, location, manager, or operating model.

Definitions vary across vendors on whether mover events are treated as HR data changes, access governance triggers, or continuous assurance signals. In practice, mover events sit at the intersection of IAM, PAM, RBAC, and JIT controls because each of those mechanisms can be affected when responsibilities change. A role shift may justify reduced entitlements, a location change may affect privileged access paths, and a manager change can alter approval authority for future access requests. NIST’s NIST Cybersecurity Framework 2.0 reinforces the broader governance need to keep access aligned to current business context.

The most common misapplication is treating mover events as administrative updates only, which occurs when HR records change but access recertification, privilege revocation, and approval routing are left untouched.

Examples and Use Cases

Implementing mover-event controls rigorously often introduces coordination overhead, requiring organisations to weigh faster business mobility against the cost of tighter entitlement review.

• An engineer transfers from application development to a customer support function, so privileged repository access, production secrets, and deployment rights are re-evaluated immediately.
• A manager changes from one business unit to another, and RBAC inheritance is recalculated so prior team-level permissions do not persist by default.
• An employee relocates to a regulated region, triggering review of data access, PAM workflows, and any jurisdiction-sensitive systems that should now be restricted.
• A contractor becomes a full-time employee, and previously narrow JIT access is expanded only after formal approval and entitlement validation.

NHIMG research on NHIs shows why movers matter beyond human accounts: only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have robust rotation procedures. That gap, described in the Ultimate Guide to NHIs, often mirrors the way mover events are handled for service identities, scripts, and automations that follow employees across teams. For identity-driven operations, the same change event can require updates to both human approvals and the linked NIST Cybersecurity Framework 2.0 access controls.

Why It Matters in NHI Security

Mover events are dangerous because they create a false sense of continuity. A person may still be trusted, but their access assumptions no longer match the new role. That mismatch is especially risky when access is granted through standing permissions, shared service credentials, or broad group memberships that were never designed to shrink automatically.

In NHI governance, mover handling should be as important as joiner and leaver handling because privilege creep often begins with a legitimate transfer, not a malicious action. NHIMG research shows that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. When employee transitions are not tied to immediate entitlement review, the same drift can affect machine identities, automation accounts, and delegated access paths. The Ultimate Guide to NHIs frames this as a lifecycle governance issue, while the NIST Cybersecurity Framework 2.0 emphasizes continuous access governance and risk reduction.

Organisations typically encounter lateral movement, audit findings, or unexpected data exposure only after a role change has already taken effect, at which point mover event controls become operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What makes Shai Hulud 2.0 different from a normal npm malware event?
• What is the difference between quarterly certification and event-driven access control?
• When does event-driven IAM reduce risk more than periodic access reviews?
• When should organisations treat a successful login as a security event?