Conflicting access can slip through role design, exception handling, and workflow shortcuts, especially when the programme is under time pressure. SoD only works when it is embedded in entitlement design, approval logic, and ongoing policy tuning.
What breaks first when SoD becomes a checklist item
Separation of duties fails most visibly at the points where policy has to influence design. If role models are built for convenience, if exceptions are approved without context, or if workflow shortcuts bypass conflict evaluation, conflicting access can be granted and left in place. The result is not just a weak control, but a control that looks present while the risky combination still exists.
SoD is strongest when it is enforced upstream, in the entitlement model and request workflow, rather than discovered after access has already been created. That is why Role Mining and Role Design Guide matters here: role structure is where many SoD failures are either prevented or quietly introduced.
Why checkbox SoD creates hidden conflict paths
Checkbox SoD usually means the programme records that a control exists, but does not continuously test whether the control is actually blocking toxic combinations. In practice, the breakpoints are role explosion, brittle exception handling, and approval logic that treats conflict review as a formality. That is especially dangerous when access is granted through multiple channels, because no single reviewer sees the whole effective entitlement picture.
In mature programmes, SoD has to survive role changes, emergency access, delegated approvals, and periodic recertification. IAM and IGA Basics is useful here because it ties SoD to entitlement governance rather than to a one-time policy declaration, and Access Reviews and Certification Guide shows why reviews must remove access, not merely acknowledge it.
How to tell whether SoD is real or performative
Real SoD shows up in design artefacts, workflow enforcement, and evidence of ongoing tuning. If conflicts are only checked at request time, but not when roles are revised, exceptions are granted, or provisioning logic changes, the control will drift. A checkbox model also tends to miss indirect combinations, where individually acceptable permissions become risky when combined across applications or steps in a process.
Practitioners should also watch for the point where operational pressure starts shaping governance outcomes. IGA Buyer’s Guide is relevant because platform choice is only part of the answer, what matters is whether the tool and operating model can express conflict rules, exceptions, and review outcomes without degrading into manual overrides.
Risk and Threat Considerations
When SoD is reduced to a box to tick, the main risk is that conflicting access is normalised inside the identity model and then reused at scale. That creates fraud, misuse, and privilege-abuse exposure, especially where one person or process can both create and approve value-bearing actions.
Failure mechanism: weak role engineering, unbounded exception handling, and workflow shortcuts allow toxic combinations to persist even though the control is marked complete.
Impact: the organisation can lose detection and prevention value at the exact point where SoD should block abuse, which increases the chance of unauthorized change, payment, or administrative misuse.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | Directly addresses SoD enforcement in access governance and workflow controls. |
| AC-6 — Least Privilege | SoD failures often coexist with excess entitlements that widen conflict combinations. | |
| IA-5 — Authenticator Management | Credential handling can undermine SoD when shared or long-lived access enables bypass paths. | |
| Recommendation — Enforce AC-5 so conflicting duties are blocked in design, approval, and review workflows. Limit entitlements to reduce the number of toxic combinations a role can create. Control credential lifecycle so privileged access paths cannot bypass SoD checks. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The question concerns duty conflicts that often arise from excessive non-human or delegated access. |
| Recommendation — Reduce overprivileged identities so automated access cannot violate duty separation. | ||
| CIS Controls v8 | CIS-5 — Account Management | SoD depends on governing accounts, roles, and exceptions across their lifecycle. |
| Recommendation — Govern accounts and access changes so conflicting duties are removed before use. | ||
Practitioner Guidance
What to prioritise: start with the control points where SoD can still stop bad access, role design, access request approvals, and periodic certification. If conflict detection happens only after provisioning, the control is already too late.
What to verify: test whether exceptions are time-bound, whether approvals are independent, and whether role changes trigger a fresh conflict check. A programme that cannot show those three things is usually relying on process theatre rather than enforceable segregation.
Practitioner takeaway: SoD should be treated as a living entitlement rule set, not a compliance label, because the control only works when it still breaks the request before the conflict becomes active access.
Related resources from NHI Mgmt Group
- What breaks when access reviews are treated as a quarterly checkbox?
- What breaks when privileged session management is treated as a compliance checkbox?
- What breaks when separation of privilege is treated as a role design exercise only?
- What breaks when employee role changes are not tied to separation of duties?