TL;DR: Segregation of duties prevents one privileged person from creating access, approving changes, and erasing evidence, reducing insider misuse and audit exposure across cloud, SaaS, and data center environments, according to SecurEnds. The control only works when identity governance, role design, and exception handling stay current with real admin workflows.
At a glance
What this is: This article argues that segregation of duties is the control that prevents one privileged person from owning access creation, approval, and evidence removal in the same workflow.
Why it matters: It matters because IAM, IGA, and PAM teams need to split administrative power in ways that hold up under audits, reduce insider abuse, and limit the blast radius of compromised admin access.
Context
Segregation of duties is an identity governance control that breaks critical work into separate roles so no single admin can create access, approve it, and hide the trail. In practice, it is the difference between controlled administration and unchecked privilege.
The article frames this as a cybersecurity baseline, not an accounting nicety, because cloud, SaaS, and data center operations now rely on distributed admin access. When those duties collapse into one identity, the governance model fails before the breach even starts.
For IAM and IGA programmes, the issue is not whether access exists. The issue is whether the people who grant, use, and review access are deliberately different, and whether exceptions are documented tightly enough to survive scrutiny.
Key questions
Q: What breaks when one admin can create access and approve it too?
A: The control breaks at the point where access creation, approval, and oversight collapse into one identity. That makes abuse easier to hide, weakens audit evidence, and removes the second check that SoD is meant to provide. In practice, the organisation loses both preventative control and reliable proof that privileges were assigned legitimately.
Q: Why do cloud admin roles make segregation of duties harder to enforce?
A: Cloud platforms often centralise powerful actions into a few broad roles, so one person can accumulate more authority than legacy operating models expected. That raises risk because provisioning, privilege assignment, and logging can all converge in the same control plane. SoD fails when the role model does not reflect how admins actually work.
Q: How do organisations know whether segregation of duties is actually working?
A: Segregation of duties is working only if no identity can combine enough permissions to complete the full banking workflow without an independent check. The test is not whether a policy exists, but whether cross-system role combinations are blocked before they create an end-to-end abuse path. If combinations are still possible, the control is only documented, not enforced.
Q: When should organisations rely on compensating controls instead of perfect SoD splits?
A: Use compensating controls only when team size or operating model makes a full split impossible, and document the reviewer, frequency, and evidence trail. They are not a substitute for separation, but they can reduce risk where one person must hold more than one function temporarily.
Technical breakdown
How segregation of duties breaks privileged admin workflows
Segregation of duties works by separating provisioning, approval, and oversight so that high-risk actions cannot be completed end to end by one identity. In a well-designed model, the person who creates an account is not the same person who grants elevated rights or certifies the resulting access. That split matters because admin abuse usually succeeds when the same account can act, approve, and conceal in a single path. In cloud and SaaS, this is harder because control planes often centralise powerful roles, so SoD must be enforced through governance and workflow, not just policy language.
Practical implication: Map every privileged workflow to distinct actor roles and block self-approval wherever an admin can materially change access.
Why cloud admin rights and audit trails fail without SoD
Cloud and SaaS environments concentrate power into a small number of roles, which makes SoD failures more dangerous than in older, slower-moving systems. If one administrator can provision accounts, grant privilege, and disable logging, the environment loses both prevention and detection at the same time. Auditors care about this because the control is not only about stopping abuse, but also about preserving evidence that duties were split. The technical problem is less about one setting and more about role overlap across provisioning systems, directory services, logging platforms, and approval chains.
Practical implication: Review cloud admin roles for overlap across account creation, privilege assignment, and log control before audit findings expose the conflict.
How identity governance enforces SoD in daily operations
Identity governance makes SoD operational by evaluating access assignments against role conflict rules and exception logic. That means checking whether a user has two or more incompatible duties, such as requester and approver, or system admin and audit reviewer. The control is only effective when those checks run continuously enough to catch role drift after reorganisations, vendor changes, or emergency access grants. Manual reviews help, but they usually lag behind the pace of real admin work. SoD becomes durable only when access review, approval routing, and exception handling are all tied to the same governance model.
Practical implication: Automate conflict detection in IAM and IGA workflows so toxic role combinations are flagged before they become normal.
Threat narrative
Attacker objective: The objective is to gain unchecked administrative control while preserving plausible deniability and weakening the audit trail.
- Entry begins when a privileged insider or compromised admin account already has enough access to perform high-risk system changes.
- Escalation occurs when the same identity can create users, grant elevated roles, and modify controls without a second approval path.
- Impact follows when logs, approvals, and ownership records can all be altered by the same actor, making abuse harder to detect and prove.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Segregation of duties is an access governance control, not a paperwork control. The article is right to frame SoD as a guardrail that limits what a single privileged identity can do end to end. In modern environments, the real risk is not only misuse, but the concentration of authority across provisioning, approval, and oversight. Practitioners should treat role separation as a runtime control over admin power, not a compliance label.
Cloud and SaaS have made SoD a role design problem rather than a perimeter problem. Centralised admin consoles compress many actions into a small number of privileges, so separation must be engineered into roles and workflows. That shifts the governance burden onto IAM, IGA, and PAM teams, which must model who can request, approve, and execute changes. The practical conclusion is that role overlap now creates the breach condition.
SoD only remains credible when exception handling is tightly governed. The article correctly notes that small teams, emergency work, and business change can all erode the control if exceptions become routine. A standing exception is just hidden privilege concentration with better documentation. The implication for identity programmes is that exception review, not just baseline role design, determines whether SoD still exists in practice.
Auditability is the second half of SoD, not a by-product. If one person can change access and suppress the evidence, the organisation has lost both control and proof. That is why SoD belongs alongside identity governance and privileged access management as a combined discipline. The practitioner takeaway is simple: if the trail cannot survive the actor, the control has already failed.
Identity governance maturity is measured by how well it prevents duty collapse under real operating pressure. Many teams can describe SoD on paper, but fewer can keep it intact through cloud sprawl, emergency access, and delegated administration. The controls that matter are the ones that hold when operations move fast. For practitioners, the question is whether SoD still works after exceptions, not whether it looks sound in policy.
From our research library:
- U.S. fraud losses are projected to reach $40 billion by 2027.
- Read next: Segregation of Duties (SoD) Guide
What this signals
Duty separation now sits at the centre of admin governance. As infrastructure spans cloud, SaaS, and data centre systems, teams can no longer rely on informal checks to stop one identity from owning the full control path. The operational question is whether access design still creates real separation between request, approval, and execution.
Exception handling is where SoD programmes usually drift. Temporary access, emergency changes, and small-team workarounds often become permanent shortcuts unless they are actively reviewed. That is where identity governance, PAM, and audit teams need a shared operating model, because policy alone does not stop privilege concentration.
SoD is a role architecture problem as much as a compliance control. When role definitions are stale, every access review becomes retrospective damage control rather than preventative governance. Programmes that keep duty maps current will have a much easier time proving control effectiveness under regulatory scrutiny.
For practitioners
- Define toxic role combinations Map the specific duty pairs that must never sit in one identity, such as requester and approver, builder and reviewer, or admin and audit owner.
- Separate privileged workflow steps Break account creation, privilege assignment, and monitoring into distinct approval paths so one admin cannot complete the full action chain alone.
- Review emergency access exceptions Document every exception to SoD, assign compensating review ownership, and retire exceptions before they become de facto operating practice.
- Automate conflict detection in IGA Use identity governance rules to flag users who accumulate incompatible duties after role changes, mergers, or temporary admin grants.
Key takeaways
- Segregation of duties prevents a single privileged identity from controlling the full admin lifecycle, which is why it remains central to access governance.
- The article shows that SoD failures create both abuse potential and audit exposure, especially when one person can provision access and suppress evidence.
- The control works only when role design, identity governance, and exception handling stay aligned with how administrators actually operate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST SP 800-53 Rev 5, NIST CSF 2.0 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-6 — Least Privilege | SoD depends on limiting one admin from holding end-to-end authority over critical actions. |
| Recommendation — Apply AC-6 to separate privileged duties and block one identity from executing the full control path. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about governing entitlements so no one identity can own access, approval, and review together. |
| Recommendation — Use PR.AA-05 to review entitlements for conflicting duties and remove overlapping admin authority. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account management is the operational layer where SoD conflicts appear and must be controlled. |
| Recommendation — Apply CIS-5 to manage privileged accounts, role conflicts, and exception handling in one governance process. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SoD is an access-control discipline that depends on defined and enforced role boundaries. |
| Recommendation — Implement A.5.15 by defining access boundaries that prevent one person from holding incompatible duties. | ||
| MITRE ATT&CK | TA0006; TA0004 — Credential Access; Privilege Escalation | The article describes abuse paths where one privileged identity can gain and misuse additional power. |
| Recommendation — Map SoD gaps to TA0006 and TA0004 to prioritise controls that stop privilege accumulation and abuse. | ||
Key terms
- Segregation of Duties: 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.
- Compensating Control: A compensating control is a measure that reduces risk when the ideal fix, such as immediate patching or redesign, is not possible. In OT, compensating controls often include session recording, access restriction, and tighter monitoring. They do not eliminate the underlying issue, but they narrow exposure until safer remediation can happen.
- Privileged Workflow: A privileged workflow is any access or administrative process that can change sensitive systems, accounts, or controls. Because these workflows can create audit and abuse risk quickly, they need independent approval, logging, and review, especially when one person could otherwise control multiple steps.
- Access Review: A formal process for confirming whether access is still needed and justified. In IAM programs, the review becomes an evidence-bearing control when decisions are recorded, scoped correctly, and traceable to the right reviewer, application owner, or auditor.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 25, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org