What breaks when separation of duties is missing in hybrid systems?

Why This Matters for Security Teams

Separation of duties is the control that stops one identity from initiating, approving, and completing a high-risk action without challenge. In hybrid systems, that control often degrades at the seams between legacy applications, cloud services, and manual approval paths. The result is not just convenience risk but a structural governance failure: access reviews miss effective privilege, audit trails lose context, and exceptions become permanent.

This matters even more for non-human identities because service accounts, API keys, and workflow credentials often sit outside the normal joiner-mover-leaver process. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges, which makes duty separation difficult to enforce consistently. For a broader governance baseline, Ultimate Guide to NHIs is a useful reference, while NIST SP 800-53 Rev 5 Security and Privacy Controls remains the standard control catalogue for separating approval, execution, and review responsibilities.

In practice, many security teams encounter SoD failures only after an incident review shows that the workflow was never technically capable of preventing self-approval in the first place.

How It Works in Practice

Effective separation of duties in hybrid environments requires more than policy language. It needs enforced control points across identity, workflow, and logging layers. In practice, organisations should map each risky action to distinct identities or roles for request, approval, and execution, then verify that no single human or NHI can satisfy all three paths. That often means limiting shared accounts, replacing standing access with time-bound access, and routing sensitive actions through ticketed approvals or policy engines.

For NHIs, the same principle applies but the mechanics differ. Service accounts should be bounded by workload identity, short-lived tokens, and explicit task scope rather than reusable secrets with broad reach. When a pipeline, agent, or integration can both request and execute a change, the control should be shifted into runtime policy rather than manual sign-off. Current guidance from OWASP and NIST strongly supports least privilege, strong authentication, and auditable approvals, even though there is no universal standard for hybrid SoD design yet.

Good implementations also add detective controls: immutable logs, independent review queues, exception expiry, and periodic recertification of any accounts used for emergency access. NHI Management Group’s Ultimate Guide to NHIs highlights why rotation, visibility, and offboarding matter when machine identities are part of the approval path. These controls tend to break down when legacy systems require shared administrator access because the application cannot distinguish who approved the action from who executed it.

Common Variations and Edge Cases

Tighter separation of duties often increases operational overhead, requiring organisations to balance fraud prevention and change safety against delivery speed and support burden. That tradeoff is especially visible in hybrid estates where older platforms cannot enforce granular RBAC, and where cloud automation expects machine speed rather than human review.

One common edge case is emergency access. Best practice is evolving toward tightly controlled break-glass accounts with approval, alerting, and mandatory post-use review, but there is no universal standard for how long those privileges may remain active. Another edge case is automation that spans procurement, finance, and ITSM. If the same workflow identity can create a request, approve it, and trigger downstream execution, SoD is functionally absent even if different systems appear involved. This is where policy-as-code and workflow segregation become more important than static role names.

Hybrid systems also create false comfort through partial controls. A legacy system may separate human approvers while a connected API still allows an NHI to post the final transaction. That is why OWASP guidance and NIST control families should be applied to the whole transaction path, not just the user interface. Where organisations rely on exceptions, the exception register itself becomes a privileged asset and must be reviewed with the same discipline as the underlying account model.

Related resources from NHI Mgmt Group

• What breaks when organisations rely only on segregation of duties checks in ERP cloud security?
• What breaks when SAP roles and authorisations are not aligned to real business duties?
• What breaks when organisations launch AI systems without formal risk assessment and approval workflows?
• What breaks when customer identity journeys are split across disconnected systems?