What breaks when separation of duties is enforced only on paper?

Why This Matters for Security Teams

Separation of duties only matters if the control is enforced where work actually happens: in workflows, entitlements, approvals, and audit trails. When it exists only as policy language, teams can still bypass it through temporary exceptions, shared admin paths, or unreviewed automation. NIST guidance in the NIST Cybersecurity Framework 2.0 treats governance as an operational capability, not a document, which is the right lens here.

The practical risk is that SoD becomes a reassurance signal instead of a control. That gap is especially dangerous in identity-heavy environments where a single credential can trigger code changes, payment actions, or access escalation. NHIMG has repeatedly shown how identity failures cascade when credentials are over-permissioned or poorly governed, as seen in the Ultimate Guide to Non-Human Identities. In practice, many security teams encounter SoD failure only after an exception path has already been used repeatedly enough to become the real process.

How It Works in Practice

Effective SoD requires that no single actor, account, or automation path can complete a sensitive action end-to-end without independent review. That means the control must be embedded in identity design, ticketing, privileged access workflows, and logging. If an approver can also execute the action, or if the execution path is available through a shared service account, SoD is materially weakened even when the policy is formally correct.

Practitioners usually enforce SoD through a mix of entitlement segmentation, dual control, and evidence capture. In mature environments, that looks like:

• distinct identities for request, approval, and execution
• role boundaries that prevent approvers from holding execution rights
• time-bound elevation through NHI lifecycle governance
• immutable logs that show who approved, who executed, and what changed

For machine and service identities, static SoD checks are often too coarse. A better pattern is to use policy-driven controls that evaluate context at request time, then issue only the minimum privilege needed for a bounded task. That aligns with current guidance in NIST CSF 2.0, especially where traceability and access governance must be proven during audit. The same control logic should also apply to automation accounts, because they can be used to route around human approval chains. NHIMG’s research on the ASP.NET machine keys RCE attack illustrates how trust in a hidden credential or configuration path can turn into execution authority very quickly.

These controls tend to break down when legacy systems force shared admin access, because the business process depends on exceptions that cannot be independently enforced.

Common Variations and Edge Cases

Tighter SoD often increases operational friction, requiring organisations to balance control strength against response time and staffing overhead. That tradeoff is real, especially in incident response, production support, and small security teams. Current guidance suggests that not every exception can be eliminated, but every exception should be pre-approved, time-bounded, and separately monitored.

One common edge case is emergency access. If break-glass credentials are exempt from SoD, they must be isolated, heavily logged, and reviewed after use. Another is automation. Best practice is evolving, but there is no universal standard yet for how to model SoD when an agent or workflow engine requests, approves, and executes tasks across multiple systems. In those cases, the right question is not whether the policy exists, but whether the environment can prove independent control in practice.

That is where documentation-only SoD fails hardest: the audit trail may show that policy exists, while the operational trail shows one person, one token, or one pipeline doing everything. Security teams should treat that as a control design defect, not a paperwork issue, and align remediation with least privilege, workflow segregation, and evidence retention.

Related resources from NHI Mgmt Group

• What breaks when separation of duties is not enforced in regulated environments?
• What breaks when segregation of duties is not enforced in identity governance?
• What breaks when employee role changes are not tied to separation of duties?
• What breaks when segregation of duties is enforced only in core ERP?