Separation of Duties is a control that splits critical tasks across different people or systems so no single identity can complete an entire sensitive process alone. In IAM and NHI governance, it reduces fraud, error, and abuse by separating provisioning, approval, execution, and review privileges across distinct roles or accounts.
What Separation of Duties Means in Practice
Separation of Duties is not just a policy statement, it is a structural control that forces critical work to pass through different people or systems so no single actor can start, approve, and complete a sensitive action alone. That design reduces both malicious abuse and accidental mistakes.
The control matters most where one action can create irreversible consequences, such as granting access, moving money, changing production settings, or approving high-risk exceptions. By splitting responsibility, organisations make collusion harder, create review points, and reduce the chance that a single compromised account can complete an entire harmful workflow.
It is also important to distinguish separation of duties from simple role assignment. A role-based design can still fail if one role accumulates too much authority, if emergency access is left unchecked, or if systems let the same person approve their own request. SoD only works when the workflow itself prevents that concentration of control.
Where Separation of Duties Shows Up
In IAM and access governance, SoD commonly appears in joiner-mover-leaver workflows, privileged access approval, entitlement changes, and periodic access review. The idea is to separate request, approval, provisioning, and certification so that the same identity does not own every step.
In finance, procurement, and ERP processes, SoD blocks toxic combinations such as creating a vendor, approving a payment, and reconciling the transaction. In security operations, it can separate administrative access from oversight, or separate the person who deploys a change from the person who signs it off.
In modern environments, the same principle extends beyond human users. IAM and IGA Basics covers how access governance, entitlements, and access reviews support these separations across both people and machines.
Why Separation of Duties Is a Control, Not a Checkbox
SoD only creates real assurance when it is enforced by process and technology together. A policy document without workflow enforcement can be bypassed by shared accounts, manual overrides, or informal approvals.
Effective SoD usually depends on explicit approval chains, independent review, and clear ownership of privileged activities. It also requires visibility into exceptions, because emergency access, delegated administration, and temporary overrides are the places where the control is most likely to weaken.
That is why many programmes treat SoD as part of broader access governance rather than a standalone rule. Segregation of Duties (SoD) Guide shows how to build rulesets, manage conflicts, and extend segregation into service accounts, bots, and AI agents.
What Happens When SoD Is Weak or Missing
When duties are not separated, the same identity can create a request, approve it, and execute it, which removes the control point that would otherwise catch fraud, error, or misuse. That creates a classic trust failure: the system assumes separation exists, but the workflow actually concentrates power.
The security impact is broader than theft. Weak SoD can hide privilege creep, mask insider abuse, and make post-incident review harder because one account may have touched every step of the process. It also increases the blast radius of any account compromise, since a single credential can inherit multiple decision points.
For that reason, auditors and defenders often look for conflicting access paths, excessive standing privilege, and weak exception handling. In practice, SoD is strongest when the organisation can show that sensitive actions are both authorised and independently checked before completion.
Risk and Threat Considerations
When SoD breaks down, the main risk is concentration of trust. A single identity, especially a privileged one, may be able to authorise, execute, and conceal a sensitive action, which increases fraud potential, insider abuse, and the impact of credential compromise.
Failure mechanism: Conflicting permissions, shared accounts, emergency access, or poorly enforced workflow approvals let one actor bypass the intended second line of review and complete a sensitive process alone.
Impact: The result can be unauthorised payments, illicit access grants, hidden configuration changes, or difficult-to-detect abuse that survives routine review because no independent control ever intervened.
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 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | Defines separation of duties as a core access-control safeguard. |
| AC-6 — Least Privilege | SoD works with least privilege to prevent one identity from accumulating complete workflow power. | |
| Recommendation — Apply AC-5 to divide sensitive tasks across separate roles or accounts. Limit each role to the minimum access needed so no single account can complete every step. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Covers operational access governance, including restricting and reviewing privileged access paths. |
| Recommendation — Use CIS-6 to govern access approvals, reviews, and privilege separation across critical systems. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control governance underpins role separation and approval boundaries. |
| Recommendation — Define and enforce access rules that keep conflicting duties separated. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | SoD is material where non-human identities can accumulate conflicting privileges across workflows. |
| Recommendation — Split provisioning, approval, and execution so an NHI cannot complete a sensitive process alone. | ||
Practitioner Guidance
Why practitioners should care: Treat SoD as an operating control, not an audit artifact. If the same person can request, approve, and complete a high-risk action, the control is functionally absent even if the policy says otherwise.
What to watch for: Shared administrative accounts, exception-heavy workflows, temporary access that becomes permanent, and roles that quietly accumulate incompatible permissions are the clearest signs that the control is degrading.
Practitioner takeaway: The strongest SoD designs make the unsafe path impossible by default, then require explicit, reviewable exceptions when business reality forces an override.