They often treat SoD as a role design problem instead of an effective permissions problem. A role may look compliant on paper while the underlying application access still allows conflicting actions. Teams need to test actual privilege paths, not just review job titles or role names.
Why Security Teams Misread Separation of Duties
Separation of duties is often treated as a paperwork exercise: one role for requests, another for approvals, and a third for execution. That model helps only if the actual permissions enforce the separation. In modern environments, the real risk sits in effective access paths, delegated admin rights, service accounts, and automation that can bypass the intended human workflow. NIST’s NIST Cybersecurity Framework 2.0 frames access control as an operational discipline, not a naming convention, and NHIMG’s Ultimate Guide to NHIs shows why this matters when non-human identities carry broad, persistent privilege.
The common failure is assuming that a clean role matrix means safe separation. In practice, an approval flow may be intact while an API token, CI/CD runner, or shared service account can still perform both sides of a sensitive transaction. That gap is especially dangerous because auditors often see policy, not executable privilege. In practice, many security teams encounter SoD failures only after a fraudulent change, abuse of a privileged workflow, or an incident review exposes the missing control path.
How Separation of Duties Breaks in Practice
Effective SoD depends on testing what identities can actually do, not what job titles imply. Security teams need to trace the full privilege chain across humans, NHIs, application roles, and automation. If one identity can request, approve, and execute through different interfaces, the separation is cosmetic. If an engineer can trigger a pipeline that deploys to production using a service account with broad rights, the SoD boundary is already gone.
This is why NHI governance is central to SoD. NHIs often outnumber human identities by 25x to 50x, and the Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges. Those realities make static role reviews weak unless teams also inspect secrets placement, token scope, and execution context. Current guidance suggests treating SoD as an effective permissions problem with continuous validation, not a one-time access review.
- Map each sensitive action to the identities that can initiate, approve, and complete it.
- Check whether any NHI, token, or shared account can bypass the intended human approval path.
- Review effective permissions in apps, pipelines, and cloud control planes, not just RBAC assignments.
- Use short-lived credentials and tightly scoped workload identities where automation is involved.
Where possible, pair access reviews with logging that proves who or what actually executed the action. This aligns with the broader NIST Cybersecurity Framework 2.0 emphasis on control effectiveness, but the test must be real-world: can one identity still complete conflicting steps by chaining tools or reusing a privileged token? These controls tend to break down when automation platforms share credentials across environments because the same identity can inherit approval, deployment, and data-access rights through inherited trust.
Where SoD Controls Need Extra Scrutiny
Tighter separation of duties often increases operational overhead, requiring organisations to balance abuse resistance against delivery speed. That tradeoff is real in DevOps, cloud operations, and agentic workflows where hard separation can slow recovery or make emergency changes cumbersome. Best practice is evolving here, especially for autonomous systems and NHIs, so teams should be explicit about which exceptions are temporary, which are monitored, and which are never allowed.
Special care is needed when a single platform owns too much of the workflow. For example, a ticketing system that can both create and approve changes, or a CI/CD service account that can deploy and rollback, may collapse SoD even if the human roles look distinct. The same problem appears when vendor access, OAuth apps, or shared secrets give one identity multiple paths into the same control plane. NHI programs that improve secret rotation and visibility reduce this risk, and the Ultimate Guide to NHIs is clear that weak offboarding and over-privilege remain recurring gaps. In environments with shared admin consoles, long-lived API keys, or informal emergency access, SoD tends to fail because the exception path becomes the normal path.
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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | SoD fails when NHIs have conflicting effective privileges across workflows. |
| NIST CSF 2.0 | PR.AC-4 | Access control must be enforced by effective permissions, not role labels. |
| NIST AI RMF | Governance should assess whether autonomous systems can bypass intended separation. |
Validate NHI privilege paths and remove any identity that can both approve and execute sensitive actions.
