Cloud segregation of duties breaks down in multi-cloud identity governance

At a glance

What this is: This article explains why cloud segregation of duties weakens in multi-cloud environments when permissions are delegated through automation, temporary access, and non-human identities.

Why it matters: It matters because IAM, IGA, and PAM teams must govern cloud privileges that change faster than manual approval, recertification, and audit workflows can track.

Context

Cloud segregation of duties is the practice of keeping conflicting access paths apart so the same subject cannot create, approve, and audit sensitive changes. In AWS, Azure, and GCP, that model is stressed by ephemeral permissions, delegated administration, and automated deployment paths that move faster than traditional review cycles.

The governance gap is not just more access, but more dynamic access. When infrastructure, workloads, and machine identities can gain privileges through CI/CD, IaC, or temporary elevation, segregation of duties must cover the full lifecycle of cloud permissions rather than a static role map.

Key questions

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. That means the same subject can create, approve, and exercise access before the next certification cycle sees it. Effective SoD has to inspect permission transitions, not just assigned roles.

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. That raises the likelihood of unreviewed production changes, privilege abuse, and weak auditability. Compliance frameworks care because the control failure is not just exposure, but broken accountability across the full change path.

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. If those patterns appear across ERP, cloud, or IAM systems, the control is probably being managed as a periodic review exercise rather than an enforced governance rule.

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.

Technical breakdown

Why cloud SoD breaks under dynamic permission paths

Traditional segregation of duties assumes permissions are assigned, reviewed, and changed on a human timeline. Cloud platforms replace that with policy-driven automation, just-in-time elevation, and deployment-time permission changes. Once access is granted through pipelines or scripts, the effective authority may exist only for a task window and then disappear, or worse, linger after the task completes. That makes the control problem one of governing permission state transitions, not just role assignments. In AWS, Azure, and GCP, SoD failures often appear when the same workflow can both request and exercise privileged access.

Practical implication: Model cloud SoD as a control over permission transitions, not only over account roles.

Non-human identities are now part of the SoD boundary

Service accounts, APIs, automation scripts, containers, and workload identities often carry the permissions that cloud teams use to make delivery fast. The issue is that these identities can accumulate broad rights without the organisational checks applied to people. Unlike human users, they may run continuously, inherit permissions through tooling, and escape the normal notice of access reviews. That creates hidden privilege combinations across production systems, monitoring, and identity administration. In cloud governance terms, the SoD boundary has expanded to include machine actors that can independently exercise sensitive operations.

Practical implication: Include service accounts and workloads in SoD design, certification, and conflict detection.

Multi-cloud governance fails when policy models stay fragmented

AWS IAM, Azure RBAC, and GCP IAM all express access differently, but practitioners still need one coherent view of conflicting privilege. Fragmented policy models make it difficult to see when a user can provision infrastructure in one environment, approve changes in another, and audit activity elsewhere. The result is governance by local exceptions rather than enterprise control intent. Cloud SoD therefore depends on normalising privilege visibility across environments and correlating operational, approval, and audit responsibilities into one control view.

Practical implication: Build a cloud-wide conflict matrix that spans AWS, Azure, and GCP permission models.

Threat narrative

Attacker objective: The objective is to gain enough cloud authority to make and hide high-risk changes without independent oversight.

1. Entry occurs through legitimate cloud administration paths such as DevOps pipelines, CI/CD automation, temporary elevation, or overbroad IAM assignments.
2. Credential or privilege exposure follows when users, roles, or service accounts inherit permissions that let them request, approve, or execute sensitive changes.
3. Escalation happens when the same identity can combine operational access with governance authority, including production changes, IAM administration, or audit visibility.
4. Impact is governance failure: unauthorized or unreviewed changes, excessive privilege accumulation, and reduced accountability across cloud environments.

Breaches seen in the wild

• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.
• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Non-human identities are not a side issue in cloud SoD: Service accounts and automation identities are often the effective operators in modern cloud estates, yet many governance models still recertify only human users. That creates a blind spot where machine identities can hold production authority, audit access, or IAM privileges with less scrutiny than employees receive. The implication is that cloud SoD is incomplete unless the same conflict rules apply to workloads and humans alike.

Multi-cloud SoD needs a unified conflict model, not three separate rule sets: AWS, Azure, and GCP expose access through different constructs, but the governance failure is the same when one subject can provision, approve, and monitor the same change path. A cloud-specific SoD matrix becomes the control language that translates local permissions into enterprise risk. The practical conclusion is that fragmented admin domains must be normalised into one cross-cloud decision model.

Ephemeral privilege debt: Temporary elevation and just-in-time access reduce standing access, but they also create short-lived authorities that are easy to miss in traditional certification cycles. If the governance process only sees the end state, it misses the decision path that created conflicting access in the first place. The implication is that SoD oversight must move closer to issuance time and away from periodic retrospective review.

Audit independence becomes harder, not easier, in cloud operations: When cloud admins can both assign and inspect privileged access, oversight becomes circular even if the policy language looks compliant. That is especially dangerous in environments where operational speed is prized and exceptions are normalised. Practitioners should reassert separation between those who operate cloud access and those who validate its legitimacy.

What this signals

Cloud SoD has become an identity governance problem, not a policy checklist: The failure mode is not the absence of rules, but the mismatch between static governance and cloud-native access churn. Organisations need control views that follow the identity across provisioning, elevation, and audit phases, because those are now the real boundaries of authority.

Machine identity belongs inside the segregation model: Service accounts and automation identities can carry the most dangerous cloud permissions precisely because they are treated as operational plumbing. Once those identities can provision, deploy, or audit without review, the human-only SoD model no longer describes how the environment actually works.

For practitioners

• 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.
• Track temporary elevation as a governance event Record just-in-time access, time-bound roles, and CI/CD-granted privileges as first-class governance changes, not as implementation noise.
• Continuously review dormant and overprivileged cloud identities Look for unused service accounts, broad project roles, cross-account access, and workload permissions that no longer match current tasks.

Key takeaways

• Cloud segregation of duties weakens when the same cloud identity can request, approve, and exercise access through automated workflows.
• The main control gap is not a missing policy statement but a governance model that cannot see temporary elevation, CI/CD-driven access, and machine identities together.
• Practitioners need cross-cloud conflict detection, independent audit authority, and lifecycle reviews that include both human and non-human identities.

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.
• Cloud Identity: A cloud identity is any account, role, token, or credential used to access cloud services and resources. In practice, it includes both human and non-human identities that can authorize actions in infrastructure, applications, or automation pipelines. Governance depends on knowing which identity type is active and what it can do.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Temporary Privilege Escalation: A short-term increase in access rights granted to keep business operations moving. It is legitimate only when it has a clear owner, an expiry condition, and a revocation path, otherwise it becomes indistinguishable from standing privilege once the holiday period passes.

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.