Topic starter
04/06/2026 6:49 pm
TL;DR: Cloud segregation of duties weakens when the same identity can request, approve, and exercise access through automated workflows, according to SecurEnds. Cloud governance has to track temporary elevation, CI/CD paths, and machine identities together, not just assigned roles.
Editorial analysis by NHI Mgmt Group, based on content published by SecurEnds: “Segregation of Duties in Cloud Environments (AWS, Azure, GCP)”.
Key questions
Q: Why do conflicting cloud privileges create both security and compliance risk?
A: Conflicting privileges let one subject alter infrastructure, approve changes, and hide evidence of those actions without independent oversight.
Q: What signs show that SoD governance is failing in practice?
A: Common signs include users who can both create and approve transactions, admins who review their own privileged activity, recurring access creep, and unresolved toxic entitlement combinations.
Q: What breaks when cloud segregation of duties is enforced only through static role reviews?
A: Static role reviews miss the real control path in cloud environments, where permissions change through pipelines, temporary elevation, and delegated automation.
Practitioner guidance
- Define a cloud-specific SoD matrix List prohibited combinations for provisioning, approval, audit, and production access across AWS, Azure, and GCP so conflict detection can run before access is granted.
- Include non-human identities in access certifications Recertify service accounts, workloads, API keys, and automation identities alongside human users, with the same conflict rules applied to each.
- Separate IAM administration from audit oversight Ensure the same administrator cannot both assign privileged roles and validate whether those roles were appropriate or compliant.
Bottom line: Cloud segregation of duties weakens when the same cloud identity can request, approve, and exercise access through automated workflows.
Glossary terms: Segregation of Duties, Cloud Identity, Non-Human Identity (NHI), Temporary Privilege Escalation
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 18 hours ago by NHI Mgmt Group
04/06/2026 7:03 pm
Cloud segregation of duties now fails at the permission-state level: The classic model was designed for stable roles and centralized administration, not for cloud access that appears and disappears inside deployment workflows. In AWS, Azure, and GCP, the important control question is no longer who owns the role, but who can create, approve, and exercise it within the same operational chain. Practitioners should treat SoD as a governance problem over mutable permission states, not a static role chart.
A question worth separating out:
Q: How should teams separate cloud administration from audit oversight?
A: Teams should split the authority to grant access from the authority to validate it, and apply that split consistently across AWS, Azure, and GCP. The practical test is simple: no single role should be able to assign privileged access and then certify that same access as acceptable.
👉 Read our full editorial: Cloud segregation of duties breaks down in multi-cloud identity governance