Segregation of Duties (SoD) in IAM is the control that prevents one person from holding access or roles that create an unacceptable abuse or fraud path. Teams use it to stop conflicting combinations such as request and approval, create and pay, or administer and audit, and should enforce it through role design, access reviews, and exceptions management.
What Segregation of Duties Means in IAM
segregation of duties in IAM is a governance control, not just a role-design preference. It breaks up combinations of access that would let one actor both initiate and complete a sensitive action, or create and conceal misuse.
This matters because IAM often concentrates authority in roles, entitlements, approvals, and administration paths. When those paths overlap too much, the issue is not only privilege size but privilege combination, which is why SoD is used to prevent toxic access patterns before they become operationally normal.
How SoD Is Enforced Through Roles and Reviews
SoD is usually expressed through role engineering, entitlement rules, approval workflow design, and periodic access review. The control has to be embedded where access is granted, inherited, or delegated, otherwise the conflict can survive even when the underlying users change.
The strongest SoD programmes define disallowed combinations clearly, then check them against actual entitlements rather than job titles alone. That is why access certification and exception handling are part of the control, not a separate afterthought.
For broader IAM governance, NHIMG’s IAM and IGA Basics explains how entitlement models, access reviews, and segregation concepts fit together in practice.
Where SoD Breaks Down
SoD fails when organisations rely on coarse roles, emergency access, or manual approvals without continuously testing the resulting access combinations. It also weakens when one person can influence provisioning, approval, administration, and review for the same process.
In practice, the control is often defeated by role creep, compensating access, or inherited permissions from shared groups and platform roles. The technical problem is rarely the absence of policy language, it is the mismatch between policy intent and actual effective access.
NHIMG’s Segregation of Duties (SoD) Guide goes deeper on toxic combinations, mitigations, and how SoD rulesets are extended beyond human users.
SoD in Modern IAM Environments
Modern IAM makes SoD more complicated because the control must also account for service accounts, bots, workflows, and delegated automation. If the same automated path can request, approve, and execute sensitive actions, the abuse path still exists even without a single human holding every permission.
SoD therefore works best as a design principle across identity lifecycle, access governance, and privileged operations, rather than as a one-time audit rule. It should be reviewed whenever organisations introduce new platforms, shared admin models, or automation that can act on behalf of others.
For machine and service identities, NHIMG’s NHI Lifecycle Management Guide and Ultimate Guide to NHIs help connect SoD to provisioning, ownership, and lifecycle controls.
Broader NHI governance also benefits from understanding common failure patterns in Top 10 NHI Issues, especially overprivilege and reuse of access patterns.
Risk and Threat Considerations
SoD weaknesses create fraud, abuse, and concealment risk because a single identity can accumulate enough authority to initiate, alter, and approve a sensitive event. That same concentration of power also makes insider misuse and post-compromise abuse easier to hide inside legitimate workflows.
Failure mechanism: Conflicting entitlements, emergency access, or weak review processes let one actor gain a complete abuse path across request, approval, execution, and audit visibility.
Impact: Organisations can see unauthorized transactions, fraudulent changes, and reduced accountability, with detection delayed until after the harmful action is already embedded in business records.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | Directly addresses splitting conflicting access and approval responsibilities in IAM. |
| AC-6 — Least Privilege | SoD depends on limiting effective permissions so conflicting duties cannot accumulate. | |
| AU-6 — Audit Review, Analysis, and Reporting | SoD needs auditability so review teams can detect conflicting access and abuse paths. | |
| Recommendation — Enforce AC-5 to prevent one identity from holding incompatible access and approval paths. Apply AC-6 to right-size entitlements before conflicting combinations can form. Use AU-6 to review transactions and access events for SoD violations. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | CCM IAM covers identity governance, access control, and segregation of access duties in cloud environments. |
| Recommendation — Map SoD requirements into IAM controls and review effective access in cloud platforms. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Annex A access rights controls support segregating and reviewing conflicting privileges. |
| Recommendation — Review access rights so no single user can combine incompatible duties. | ||
Practitioner Guidance
Why practitioners should care: SoD should be treated as an access-governance control with operational consequences, not as a periodic compliance checkbox. The practical question is whether your current role model, approval path, and review process can still prevent a user from combining conflicting powers after exceptions, automation, and delegated access are added.
Common misunderstanding: A clean role catalogue does not prove SoD if effective access still overlaps through groups, inherited permissions, or shared administrative paths. The control only works when you evaluate the actual ability to complete a harmful sequence end to end.
Practitioner takeaway: Test SoD against real transaction paths and effective permissions, then revisit it whenever the access model, approval flow, or automation layer changes.
Related resources from NHI Mgmt Group
- How should organisations build a segregation of duties matrix for modern IAM programs?
- How should security teams enforce segregation of duties in IAM workflows?
- Why do service accounts create segregation of duties risks in cloud IAM?
- How should security teams implement segregation of duties in IAM workflows?