What breaks when organisations treat movers like joiners and leavers?

Why This Matters for Security Teams

Movers are the identity lifecycle case that most often exposes hidden dependency debt. A person changes role, team, location, project, or system scope, but their access rarely changes in a clean joiner-or-leaver pattern. If security treats that change as a simple provision or deprovision event, it misses the real problem: the identity already has accumulated permissions that must be assessed selectively, not reset blindly.

This is especially risky in environments that already struggle with non-human identity sprawl. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges in many environments. Those conditions make mover events dangerous because access is often inherited, indirect, or forgotten. The same blind spots that affect service accounts also affect employee and contractor transitions when account ownership, approvals, and entitlements are not continuously reconciled. For broader lifecycle context, see the Ultimate Guide to NHIs and the access governance emphasis in the NIST Cybersecurity Framework 2.0.

In practice, many security teams discover this only after a role change has already left stale access in place, rather than through intentional mover review.

How It Works in Practice

Effective mover handling starts with identity state, not with a ticket queue. The programme needs to know what the identity already holds, where those entitlements came from, and which of them are role-derived, exception-based, or permanently assigned. That is why treating movers like joiners and leavers breaks automation: joiner logic adds from zero, leaver logic removes everything, and neither logic understands selective retention.

Good mover governance usually combines HR event ingestion, entitlement inventory, policy evaluation, and approval workflow. The goal is to compare the new state against the old state and decide what should be removed, retained, or newly granted. Current guidance suggests this should be driven by authoritative source data and reviewed with least privilege in mind, not by manual guesswork. In an NHI-heavy environment, the same logic should extend to service accounts, API keys, and delegated automation privileges, because identity changes often affect both people and the systems they own. The Ultimate Guide to NHIs highlights why offboarding, visibility, and rotation matter across the lifecycle, not just at termination.

• Map current entitlements before the role change is executed.
• Classify access as inherited, approved exception, or explicit business need.
• Revoke only what is no longer justified by the new role or project scope.
• Retain only access with a current, documented ownership basis.
• Re-run the same logic for tied resources such as shared mailboxes, CI/CD tokens, and admin groups.

The access model should be evaluated at change time, not scheduled for a later cleanup cycle. That aligns with the runtime control mindset reflected in the NIST Cybersecurity Framework 2.0, where access governance is a continuous process rather than a one-time event. These controls tend to break down when entitlement data is fragmented across HR, IAM, SaaS, and infrastructure systems because the organisation cannot reconstruct the identity’s true access state.

Common Variations and Edge Cases

Tighter mover controls often increase workflow overhead, requiring organisations to balance faster role transitions against stronger access assurance. That tradeoff becomes more visible in matrix organisations, M&A integrations, and contractor-heavy environments where a single person may have multiple sponsoring managers or overlapping business roles.

There is no universal standard for mover handling yet. Current guidance suggests the safest model is one that can distinguish between access that should be removed immediately, access that should be time-bound, and access that should survive the move with explicit reapproval. This matters when an employee moves between sensitive functions, such as finance to engineering, or when a contractor remains on a shared platform but should lose admin or production access. It also matters for accounts tied to automation, because a person’s move may require changing ownership of secrets, pipelines, or delegated permissions even when the account itself remains active.

Edge cases often involve temporary dual-hatting, where a user must retain old access for a short transition period. That should be handled as a documented exception with expiry, not as an open-ended grant. The same principle applies to privileged non-human identities: keep what is still required, revoke what is not, and make the expiry visible. For broader lifecycle and excessive-privilege risk context, the Ultimate Guide to NHIs is the clearest reference point.

Related resources from NHI Mgmt Group

• What breaks when organisations treat agent identities like service accounts?
• What breaks when organisations treat agent workflows like ordinary automation?
• What breaks when organisations treat agent detection like ordinary vulnerability management?
• How can organisations reduce the risk of stale API keys and machine tokens?