Notifications
Clear all
Topic starter
04/06/2026 6:49 pm
TL;DR: Cloud segregation of duties is harder to enforce in AWS, Azure, and GCP because permissions now shift through IaC, CI/CD, temporary elevation, and non-human identities, according to SecurEnds. The core governance problem is that static review models cannot keep pace with distributed cloud access, overprivileged workloads, and dynamic privilege changes.
NHIMG editorial — based on content published by SecurEnds: segregation of duties in cloud environments across AWS, Azure, and GCP
Questions worth separating out
Q: How should security teams implement segregation of duties in multi-cloud environments?
A: Security teams should define prohibited access combinations for each cloud platform, then enforce them before permissions are granted.
Q: Why do service accounts create segregation of duties risks in cloud IAM?
A: Service accounts create SoD risk because they often run continuously, inherit broad permissions, and are not reviewed with the same rigor as human users.
Q: What breaks when cloud access reviews do not include machine identities?
A: When machine identities are excluded, dormant service accounts, unused APIs, and overprivileged automation can keep working long after the business need has changed.
Practitioner guidance
- Define a cloud-specific SoD matrix List prohibited combinations for request, approval, deployment, production access, and audit authority across AWS, Azure, and GCP.
- Include non-human identities in access reviews Review service accounts, API keys, automation scripts, and workloads alongside human users.
- Separate privileged administration from audit oversight Ensure the same team or identity cannot assign high-risk roles and certify them.
What's in the full article
SecurEnds' full article covers the operational detail this post intentionally leaves for the source:
- Platform-by-platform SoD examples for AWS, Azure, and GCP IAM models
- Specific cloud governance patterns for separating admin, deploy, and audit responsibilities
- Operational guidance for handling service accounts, APIs, and automation identities in reviews
- Examples of SoD conflict detection and remediation inside cloud access workflows
👉 Read SecurEnds' analysis of segregation of duties across AWS, Azure, and GCP →
Cloud segregation of duties in AWS, Azure, and GCP: what breaks?
Explore further
04/06/2026 7:03 pm
Cloud segregation of duties fails when governance assumes access is static enough to review later. Modern cloud access is not static. It is minted through pipelines, elevated for short tasks, and inherited across multiple control planes, so the old assumption that an identity can be reviewed after the fact no longer holds. Practitioners should treat SoD as a runtime governance problem, not a periodic audit artifact.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
A question worth separating out:
Q: Who is accountable when a cloud identity can both approve and execute changes?
A: Accountability breaks when one identity can both authorise and perform the same sensitive action because the approval control no longer provides independent oversight. In that case, organisations need separate operational, approval, and audit roles, plus evidence that machine identities cannot bypass those boundaries.
👉 Read our full editorial: Cloud segregation of duties breaks down in multi-cloud identity governance
