Segregation of duty policies prevent one person or system from holding enough access to perform conflicting actions alone. In access governance, they reduce fraud and operational error by splitting request, approval, and execution responsibilities across roles, systems, or review paths.
Expanded Definition
Segregation of duty policies, often shortened to SoD, are governance rules that ensure no single actor can request, approve, and execute the same sensitive action without independent review. In NHI and IAM programs, this applies to service accounts, API keys, automation pipelines, and privileged workflows, not just human users. The aim is to break a risky end-to-end path into distinct responsibilities so that misuse, mistakes, or compromised credentials are harder to turn into unauthorised change.
Definitions vary across vendors when SoD is mapped into access tooling, but the underlying control intent is stable: reduce conflict concentration and create verifiable checks before a high-impact action occurs. That aligns closely with the intent of the NIST Cybersecurity Framework 2.0, especially where identity governance supports risk reduction and accountability. In practice, SoD must be designed around workflows, not titles, because a role name alone does not prove separation if one automation path still performs every step. The most common misapplication is treating shared approval roles as true segregation, which occurs when a single team can still control both the policy and the system that enforces it.
Examples and Use Cases
Implementing segregation of duty policies rigorously often introduces workflow friction and additional review time, requiring organisations to weigh faster delivery against stronger abuse resistance.
- A CI/CD pipeline can be configured so one engineer submits a deployment change, another approves it, and a protected runtime identity performs the release.
- An API key request can be approved by a manager while a separate security function issues the secret through a vault, reducing the chance of self-approval.
- Database administration can be split so one NHI can create privileged access while another NHI must validate and log the request before activation.
- Finance-related automations can separate payment initiation, approval, and reconciliation so a compromised service account cannot move funds alone.
- Audit teams can compare role assignments against the Ultimate Guide to NHIs guidance and then test whether the same identity can still complete conflicting actions through tooling.
For implementation patterns, the Ultimate Guide to NHIs is useful because SoD should follow the full credential lifecycle, not only provisioning. In standards terms, the control logic is consistent with access governance guidance in the NIST Cybersecurity Framework 2.0, even though SoD is implemented differently across platforms and business functions.
Why It Matters in NHI Security
SoD is especially important for NHIs because automation can execute faster, more frequently, and with broader reach than a human operator. If one service account can both approve and perform an action, then a stolen token or misconfigured pipeline may turn into immediate privilege abuse. That risk is amplified when organisations have weak visibility into service accounts, and NHIMG notes that only 5.7% of organisations have full visibility into their service accounts, making hidden conflict paths hard to detect. This is one reason SoD sits alongside Zero Trust and lifecycle governance in mature NHI programs.
In practice, SoD also supports auditability. The Top 10 NHI Issues research shows how excessive privilege, misconfigured vaults, and weak remediation patterns often combine into a broader governance failure. When access, approval, and execution are not separated, incident response becomes slower and accountability becomes ambiguous. Organisations typically encounter the consequences only after an unauthorised deployment, fraudulent transaction, or compromised API key has already been used, at which point segregation of duty policies become operationally unavoidable to address.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | SoD reduces conflicting NHI actions and limits abuse of privileged automation paths. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should enforce least privilege and separated control paths. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires explicit verification before sensitive actions are allowed. |
Separate approval, issuance, and execution for NHI workflows to prevent one identity from completing all steps.
