Several major frameworks require SoD or controls that align with it. SOX focuses on internal controls over financial reporting, PCI DSS separates development, test, and production, and NIST 800-53 includes a dedicated SoD control. ISO 27001, HIPAA, GDPR, COBIT, and FISMA also support the same underlying governance principle.
Why This Matters for Security Teams
Separation of duties (SoD) is not just a compliance checkbox. It is one of the few governance controls that limits single-person or single-process abuse when privileged access, approvals, and execution all sit too close together. Frameworks such as NIST Cybersecurity Framework 2.0 and NIST SP 800-53 treat this as a foundational control principle, while audit-driven programs use it to reduce fraud, error, and unauthorized change.
For non-human identities, the issue becomes sharper because service accounts, API keys, CI/CD tokens, and automation pipelines can execute faster and more broadly than any human operator. NHIMG’s Ultimate Guide to NHIs – Regulatory and Audit Perspectives ties SoD to governance, auditability, and lifecycle control, while the broader Ultimate Guide to NHIs – Standards section shows how identity controls become enforceable only when access and execution are deliberately separated. In practice, many security teams first discover SoD gaps after a deployment pipeline, admin script, or finance workflow has already made an irreversible change.
That is why SoD matters most where one identity can both request and approve, or both create and use, a privilege. Framework alignment is strongest when those powers are split across roles, systems, or checkpoints.
How It Works in Practice
SoD is implemented by making sure no single actor can complete a sensitive action end to end. In human workflows, that may mean one person prepares a payment and another approves it. In NHI governance, the same principle applies to automation: the identity that builds a release should not also deploy it unreviewed, and the identity that requests a secret should not be the only entity able to consume it.
Most mature implementations combine role separation, workflow approval, immutable logging, and environment boundaries. NIST Cybersecurity Framework 2.0 provides a useful governance lens, while NIST SP 800-53 includes a dedicated separation-of-duties control family for restricting conflicting responsibilities. On the NHI side, the practical challenge is often lifecycle control. NHIMG’s Ultimate Guide to NHIs – Lifecycle Processes for Managing NHIs is useful here because SoD only works when identities are inventoried, bounded, and revocable across build, test, and production.
- Split request, approval, and execution across different identities or systems.
- Keep production credentials out of build and test pipelines.
- Use just-in-time elevation for privileged steps rather than persistent access.
- Log approvals, changes, and execution paths in a tamper-evident way.
- Review service accounts for privilege overlap and hidden admin relationships.
For organisations operating in regulated environments, NIST Cybersecurity Framework 2.0 is often used to map SoD into governance and control assurance, but the actual control must be enforced in tooling, not just written in policy. These controls tend to break down when CI/CD systems, infrastructure-as-code, and emergency admin access all share the same NHI or token because the boundary between approval and execution disappears.
Common Variations and Edge Cases
Tighter SoD often increases operational overhead, requiring organisations to balance fraud reduction and change control against speed, staffing, and automation complexity. That tradeoff is especially visible in cloud-native environments, where teams want rapid delivery but still need reviewable control points.
Best practice is evolving for highly automated environments. There is no universal standard for how much SoD is enough when an AI-assisted pipeline or DevOps workflow needs to self-remediate, self-deploy, or self-heal. In those cases, the safer pattern is usually compensating controls: short-lived access, dual control for high-risk actions, and strong separation between the identity that proposes a change and the one that applies it.
Frameworks often differ in emphasis. PCI DSS strongly supports environment separation, especially between development, test, and production, while SOX focuses on internal control over financial reporting where the risk is unauthorized or unreviewed change. For NHI-heavy estates, the recurring gap is not the policy language but the shared credentials hidden in scripts, CI/CD tools, and automation accounts. NHIMG’s Top 10 NHI Issues is relevant because excessive privilege and poor lifecycle discipline frequently undermine SoD before auditors ever see it.
In short, the strongest SoD programs do not rely on trust in the operator. They rely on architecture that makes conflict of interest hard to create in the first place.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Access permissions should enforce separation between conflicting duties. |
| NIST SP 800-53 Rev 5 | AC-5 | Explicitly addresses separation of duties in access control. |
| OWASP Non-Human Identity Top 10 | NHI-03 | NHI credential sprawl can collapse SoD across automation paths. |
| NIST AI RMF | GOVERN | AI governance requires accountability and controls around automated actions. |
| CSA MAESTRO | TRAIN-03 | Agentic pipelines need role boundaries and runtime control points. |
Use AC-5 to prevent one identity from requesting, approving, and executing the same sensitive action.
Related resources from NHI Mgmt Group
- How can organizations manage the risk of credential leaks in MCP frameworks?
- When should organizations consider updating their IAM frameworks?
- Which frameworks require or strongly expect MFA for enterprise access?
- What breaks when organisations rely only on segregation of duties checks in ERP cloud security?
