Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
Expanded Definition
Segregation of Duties, often abbreviated as SoD, is a control design principle that prevents one identity from both initiating and approving the same sensitive action. In NHI and IAM programs, it applies to service accounts, agents, deployment pipelines, and business process roles as much as to human users. The control is closely aligned with least privilege and with the access governance expectations reflected in NIST Cybersecurity Framework 2.0, but no single standard governs SoD implementation across all enterprise systems.
Definitions vary across vendors because ERP platforms, cloud control planes, and CI/CD environments model permissions differently. A practical SoD policy therefore has to map roles to transactions, approval paths, and compensating controls instead of relying on a generic role matrix. In NHI security, this is especially important where an AI Agent or automation identity can perform both read and write actions, or where MCP-connected tooling can trigger workflows that span multiple systems.
The most common misapplication is treating RBAC as sufficient SoD enforcement, which occurs when a role design is reviewed in isolation while transaction-level combinations and emergency access paths remain unchecked.
Examples and Use Cases
Implementing Segregation of Duties rigorously often introduces workflow friction, requiring organisations to weigh fraud prevention and change integrity against slower approvals and more complex exception handling.
- A payroll service account can submit employee adjustments, but a separate approval role must authorize the final payment run.
- An engineering deployment agent may push code to production, while a different identity validates change tickets and records release approval in the audit trail.
- A finance NHI can create vendor records, but a distinct human reviewer or compensating control must approve bank-detail changes before payment.
- An operations bot can rotate Secrets in a vault, while another role reviews rotation logs and confirms that no privileged path was broadened during the update.
- An emergency admin account may bypass normal workflow only under documented break-glass conditions, with post-event review and time-bounded access enforced afterward.
These patterns are easier to sustain when teams anchor them to governance references such as Ultimate Guide to NHIs and then test them against the control intent described in NIST Cybersecurity Framework 2.0. In practice, SoD also needs to account for workflow orchestration tools, because a single automation chain can quietly collapse multiple approved steps into one execution path.
Why It Matters in NHI Security
SoD failures are dangerous because non-human identities often accumulate broad, persistent access across systems that were never designed with identity separation in mind. NHIMG research shows that 97% of NHIs carry excessive privileges, which widens the blast radius when one account can both initiate and approve sensitive actions. That risk becomes more severe when secrets are stored in code or CI/CD systems, or when an AI Agent can invoke tools without a second control point. The governance lesson is reinforced by the Ultimate Guide to NHIs, which highlights how visibility, rotation, and offboarding failures compound identity risk.
For practitioners, SoD is not just a finance control. It is a core trust boundary for privileged automation, especially where Zero Trust Architecture expects every action to be continuously authorized and logged. That is why NIST Cybersecurity Framework 2.0 remains useful as a governance anchor even when the underlying implementation spans IAM, PAM, and workflow engines.
Organisations typically encounter SoD gaps only after a fraudulent change, an unauthorized production update, or an audit finding exposes that one identity could complete the full action chain, at which point Segregation of Duties becomes 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 |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Access control and authorization controls support separation of duties. |
| NIST Zero Trust (SP 800-207) | POL | Zero Trust requires policy enforcement that limits overbroad combined access. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Non-human identities need governance that prevents excessive privilege accumulation. |
Separate approve, execute, and review privileges so no single NHI can complete a sensitive transaction alone.
