What breaks when movers keep inherited access after a role change?

Why This Matters for Security Teams

When movers keep inherited access, the problem is not just excess permission. It is a broken identity lifecycle: a person changes job function, but the access graph still reflects the old one. That means RBAC, approvals, and periodic reviews can all look clean while the real risk has already shifted. The result is a hidden privilege combination that can bypass segregation of duties, especially in finance, production support, and admin workflows.

This is why NHI Management Group treats mover events as a control failure, not an HR admin task. The same pattern appears in machine identities too, where stale access survives role changes and keeps acting long after the business context has changed. In the broader NHI data set, Ultimate Guide to NHIs shows how excessive privilege is common, and the OWASP Non-Human Identity Top 10 reinforces that identity sprawl and weak lifecycle control create repeatable abuse paths.

Practitioners should also note that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. In practice, many security teams encounter privilege drift only after a mover has already touched production or finance systems, rather than through intentional access design.

How It Works in Practice

The failure usually starts with inherited entitlements. A user moves from one role to another, but the joiner-mover-leaver workflow only adds the new permissions and does not fully remove the old ones. That leaves overlapping access from two different job contexts. If the target environment uses broad role groups, shared service accounts, or nested group membership, the mover can end up with a combination that no single role owner ever approved.

In practice, the safest pattern is to treat every mover event as a re-baselining exercise. Access should be recalculated against the new role, not amended on top of the old one. That means reconciling direct grants, group grants, shared mailbox rights, privileged roles, and any application-specific entitlements. Where high-risk systems are involved, current guidance suggests tying review to OWASP Non-Human Identity Top 10 style governance even for human-to-system access patterns, because the failure mode is the same: standing privilege persists longer than intended.

• Remove old role entitlements before new access is issued.
• Revalidate segregation of duties after the move, not at the next quarterly review.
• Use PAM for privileged paths and require JIT access where possible.
• Record why an exception exists, who approved it, and when it expires.

That same lifecycle discipline is a core theme in Ultimate Guide to NHIs — Key Challenges and Risks and is echoed by the breach patterns in 52 NHI Breaches Analysis, where missed offboarding and poor revocation hygiene keep access alive far beyond its business need. These controls tend to break down in environments with shared admin groups, manual ticket approvals, and no authoritative entitlement inventory because no one can prove what should have been removed.

Common Variations and Edge Cases

Tighter access removal often increases operational friction, requiring organisations to balance SoD protection against business continuity. That tradeoff is real in support teams, plant operations, and emergency response roles where a mover may need temporary overlap with the old role to finish active work. Best practice is evolving here: there is no universal standard for how much overlap is acceptable, but the exception must be time-bound, documented, and reviewable.

One common edge case is role recycling, where a job title changes but the practical duties stay similar. Even then, inherited access should not be assumed safe because the entitlement set may include legacy admin rights, stale application roles, or dormant approvals that no longer match the new reporting line. Another edge case is third-party or contractor movers, where access is often attached to a sponsor rather than a person. That can leave access in place after the role change because ownership is ambiguous. The Ultimate Guide to NHIs is useful here because it shows how visibility gaps and weak offboarding controls create the same risk pattern across identities, whether human or non-human.

The practical test is simple: if the new role does not require the old privilege, the privilege should be removed immediately, even if the approval trail looks complete. If an exception is needed, it should expire automatically. Anything longer than that becomes standing access by another name.

Related resources from NHI Mgmt Group

• What is the difference between role-based access and API key governance for NHI security?
• What breaks when Bedrock agents keep broad testing permissions in production?
• How should security teams govern NHI access across joiners, movers, and leavers?
• What breaks when access approvals stay in ticket queues too long?