Why do SoD conflicts keep appearing even when access was originally justified?

Why This Matters for Security Teams

Separation of duties problems are rarely created by a single access grant. They usually emerge when justified access is never fully unwound after the original need changes. That makes SoD conflicts a lifecycle issue, not just a provisioning issue. Security teams often focus on who approved access, but auditors and attackers care more about what access still exists today and whether it now combines into an unsafe path.

NHI Management Group has repeatedly found that entitlement drift is a major driver of identity risk. In the Ultimate Guide to NHIs, NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, which helps explain why initially justified access so often becomes conflicting access later. This is the practical gap between approval and ongoing control. The same pattern appears in OWASP Non-Human Identity Top 10 guidance, where over-permissioning and weak lifecycle governance are treated as core failure modes.

In practice, many security teams encounter SoD conflicts only after an access review, audit finding, or incident has already exposed that a role has quietly accumulated incompatible duties over time.

How It Works in Practice

Most organisations approve access based on a point-in-time need: project assignment, backup coverage, emergency elevation, or a temporary exception. The problem is that real operations do not end neatly. Promotions happen, projects close late, and “temporary” coverage becomes the default. If the access model does not force revalidation, the original justification becomes stale while the entitlement remains active.

That is why effective SoD management is less about the first approval and more about continuous control. Current guidance suggests combining role review, entitlement review, and event-driven revocation. For NHIs and service accounts, this often means pairing RBAC with workload-specific controls, since static role membership alone does not reflect what the identity is actually doing at runtime. The 52 NHI Breaches Analysis shows how often excessive or lingering access becomes a real breach condition rather than a theoretical policy issue.

• Revalidate access after promotion, transfer, project closure, or incident response.
• Use SoD rules that evaluate effective access, not only assigned role names.
• Separate request, approval, and execution authority where possible.
• Shorten review cycles for high-risk combinations and exception-based access.
• Trigger removal when the original business justification expires.

For implementation, teams can map critical combinations into policy-as-code and enforce them through IAM, PAM, and workflow controls. NIST guidance on access governance and the principles behind zero trust support this approach, because trust is continuously reassessed rather than granted once and assumed forever. These controls tend to break down in organisations with heavy custom roles, shared admin accounts, or emergency access processes that are not tracked back to a revocation workflow.

Common Variations and Edge Cases

Tighter SoD enforcement often increases operational overhead, requiring organisations to balance risk reduction against response speed and administrative friction. That tradeoff is especially visible in emergency access, small teams, and legacy platforms where one person may need multiple duties to keep the business running. There is no universal standard for perfect SoD separation in those environments, so best practice is evolving toward compensating controls rather than all-or-nothing prohibition.

One common edge case is temporary exception access. If a manager approves short-term overlap for continuity, the exception should carry an explicit expiry and a documented review trigger. Another is role explosion: overly broad job roles can hide conflicts until a quarterly recertification exposes them. For NHIs, the issue is often even harder because service accounts do not “leave” a project on their own. Without ownership and revocation discipline, they keep their rights indefinitely, which is why the NHI lifecycle guidance in the Ultimate Guide to NHIs is so closely tied to SoD outcomes.

In short, the conflict keeps reappearing because access is usually granted for a valid reason, then allowed to outlive that reason. Organisations that treat SoD as a one-time approval problem miss the real control failure: stale access accumulation.

Related resources from NHI Mgmt Group

• Why do access conflicts keep reappearing even in mature identity programmes?
• Why do organisations keep Active Directory even after moving heavily to the cloud?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?