Old access often remains in place while new permissions are added, which creates overlapping privileges and hidden conflicts. That overlap defeats the purpose of SoD because the user now carries both the old and new duties at once. Movers are one of the clearest places to look for SoD drift.
Why This Matters for Security Teams
Role changes are not just HR events. They are access transition events that can quietly turn separation of duties into a paper control if old entitlements are not removed when new ones are added. That matters because SoD is meant to prevent one person from completing conflicting steps in the same process, especially across finance, approval, provisioning, and remediation paths.
When movers keep legacy access, the organisation often ends up with overlapping privileges that are hard to see in review cycles. The result is not always immediate abuse. More often it is accumulated risk: a user can approve, request, and execute the same workflow in ways the control design never intended. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, a useful reminder that privilege creep is a lifecycle problem, not a one-time provisioning problem. The same lesson applies to employee transitions.
Security teams also miss how role changes can interact with privileged workflows already governed under NIST Cybersecurity Framework 2.0. If access review does not trigger revocation and re-approval at the moment of change, SoD gaps persist until an audit, incident, or control failure exposes them. In practice, many security teams encounter SoD drift only after a high-risk transaction has already been approved twice by the same person, rather than through intentional access design.
How It Works in Practice
Effective SoD during employee changes depends on synchronising identity lifecycle events, entitlement recalculation, and privileged access governance. The core operational rule is simple: a move should be treated as a partial deprovision plus re-provision, not as an additive update. That means old permissions must be evaluated for conflict before new ones are issued, and conflicting access should be removed or placed behind compensating controls before the new role becomes active.
In mature environments, this is usually handled with identity governance, ticketed approval workflows, and policy checks against role catalogs. The workflow should compare the target role against conflicting duties, then enforce one of three outcomes: revoke the old access, deny the new access, or require exception approval with documented compensating controls. Where privileged access is involved, PAM and JIT provisioning should be used so that elevated access is short-lived and tied to a specific task rather than left standing indefinitely.
- Map each role to permitted and prohibited duties before the move is approved.
- Recompute access at the time of change, not at the next quarterly review.
- Remove conflicting access first, then grant the minimum needed for the new role.
- Log approvals, revocations, and exceptions so auditors can trace the decision path.
NHI Management Group’s Schneider Electric credentials breach is a reminder that identity sprawl and weak lifecycle control can turn access into exposure faster than teams expect. For this reason, NHI guidance on lifecycle hygiene is directly relevant even in a human-role question. These controls tend to break down when role definitions are poorly maintained across multiple HR, IAM, and PAM systems because entitlement conflicts are detected too late to prevent activation.
Common Variations and Edge Cases
Tighter SoD enforcement often increases operational overhead, requiring organisations to balance workflow speed against control assurance. That tradeoff is most visible in lean teams, matrix organisations, and environments where employees cover multiple functions during vacations, incident response, or restructuring.
There is no universal standard for every exception path yet, so current guidance suggests using documented compensating controls rather than silently allowing overlap. For example, a manager moving from requestor to approver may need temporary read-only access while the conflicting approval right is removed. In highly regulated environments, dual-control or independent review may be necessary before the new access is activated.
Edge cases also arise when entitlements are inherited through groups, nested roles, or automation accounts. A user may appear clean at the direct assignment layer while still retaining conflict through a shared group or delegated admin path. That is why SoD reviews must inspect effective access, not just assigned access. The issue is especially acute in organisations that rely on ad hoc approvals, because manual exceptions tend to outlive the move that justified them. NHI Management Group’s research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, which underscores how often lifecycle transitions are undercontrolled across identity types. The same discipline should be applied to human movers.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Role-change access conflicts are an access control issue under least privilege. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Lifecycle drift and stale privileges mirror NHI entitlement sprawl. |
| NIST AI RMF | Governance and accountability are needed for policy-driven access transitions. |
Treat every role change as a lifecycle reset and remove conflicting access before provisioning replacement rights.
