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

At a glance

What this is: This is an analysis of how segregation of duties fails in multi-cloud environments, with the key finding that dynamic cloud permissions and non-human identities undermine traditional governance models.

Why it matters: It matters because IAM, PAM, IGA, and cloud security teams must govern human and machine identities together when access can change faster than review cycles can see it.

👉 Read SecurEnds' analysis of segregation of duties across AWS, Azure, and GCP

Context

Segregation of duties in cloud environments is the practice of separating request, approval, administration, and audit responsibilities so no single identity can control a critical path end to end. In AWS, Azure, and GCP, that model is under strain because cloud permissions are assigned through APIs, IaC, pipelines, and temporary elevation rather than slow-moving on-premise processes.

The cloud governance problem is not just excessive access, but access that accumulates and changes across human users, service accounts, workloads, and automation. That makes cloud segregation of duties an IAM and NHI issue at the same time, with clear implications for access reviews, privileged access controls, and compliance evidence.

Key questions

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. The control must cover request, approval, deployment, audit, and privileged administration paths across human and machine identities. A SoD model that lives only in policy documents will not keep up with dynamic cloud access.

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. When those identities can deploy, modify, or access production systems, they can bypass the separation between operation, approval, and audit that SoD is meant to preserve.

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. That leaves hidden access accumulation in place and makes SoD conflicts invisible to certification processes, even when the human side of the environment looks compliant.

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.

Technical breakdown

Dynamic cloud permissions and SoD drift

Cloud segregation of duties breaks when permissions are not fixed at provisioning time. In AWS, Azure, and GCP, access can be granted through IaC templates, CI/CD jobs, temporary elevation, and API-driven workflows, so the same identity can move between request, deploy, and audit states very quickly. The technical problem is SoD drift: a control that looked sound during design becomes invalid once automation starts mutating entitlements at runtime. That drift is especially severe when access is inherited across projects, subscriptions, or roles and is no longer obvious from a single policy file.

Practical implication: map prohibited access combinations to the actual cloud workflow, not to an assumed stable role model.

Non-human identities and hidden privilege accumulation

Service accounts, APIs, automation scripts, and machine identities often carry the most dangerous SoD conflicts because they operate continuously and are rarely reviewed with the same discipline as human users. In cloud environments, these identities are frequently given broad permissions for convenience, then left active after the workload changes or ends. That creates hidden privilege accumulation, where the identity still has access even though the business need has disappeared. The risk is not only overprivilege, but also weak accountability when a shared secret or unattended workload can make changes without a clear human owner.

Practical implication: include machine identities in certifications, entitlement reviews, and dormant-access cleanup.

Cloud IAM conflict detection across AWS, Azure, and GCP

Each major cloud platform uses different IAM structures, which makes SoD enforcement inconsistent unless the organisation normalises controls above the platform layer. AWS uses policies, roles, and groups; Azure combines RBAC with Entra ID and privileged role governance; GCP centres on project and organisation-level permissions. The technical challenge is detecting when one identity can both perform and approve a sensitive action across these different permission models. Without a common conflict matrix, teams can miss cross-platform combinations that are safe in isolation but risky in aggregate.

Practical implication: build a cloud-specific SoD matrix that spans platforms and validates access before it is assigned.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

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 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.

Non-human identities are now the most consequential SoD problem in cloud environments. Service accounts and automation identities often receive broad rights because they are seen as operational plumbing rather than governed subjects. That framing breaks down once machine identities outnumber human users and retain privileges long after their original purpose has ended. The implication is that identity governance must cover workloads, APIs, and scripts with the same scrutiny applied to privileged humans.

Multi-cloud SoD is a control translation problem, not just a policy problem. AWS, Azure, and GCP express privilege differently, which means a conflict may be invisible unless the organisation translates entitlements into a shared control language. That is why fragmented review processes miss cross-cloud privilege paths. Practitioners should think in terms of entitlement equivalence, not vendor-specific role names.

The named concept here is identity blast radius. Once cloud permissions are dynamic and distributed, the damage from one misconfigured identity depends on how far that identity can move across production, audit, and deployment functions. The more automated the environment, the larger that blast radius becomes when SoD is not enforced at workflow level. Teams need to govern the path of privilege, not just the identity itself.

SoD governance in cloud now depends on linking human approval, machine execution, and audit evidence. A review process that only looks at end-user access misses the actual control plane where cloud risk accumulates. The discipline must extend across human approvals, service account permissions, and continuous logging. Practitioners should expect SoD failures to appear first in workflow design, not in annual certification reports.

From our research:

• 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.
• That gap is why practitioners should also use the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs to align access reviews, rotation, and offboarding with cloud SoD controls.

What this signals

Cloud segregation of duties is moving from a periodic review problem to a continuous control problem. When access changes through pipelines and automation, the real question is whether your governance stack can evaluate privilege at the moment it is created, not after the fact. Teams that still rely on static certification cycles will keep missing conflict paths that emerge inside deployment workflows.

Identity blast radius: the practical limit of how far one cloud identity can move across deploy, approve, and audit functions. As that blast radius expands across AWS, Azure, GCP, and SaaS, SoD has to be expressed in workflow terms, not just role names. That makes central visibility and entitlement translation essential for IAM, PAM, and IGA teams.

With 67% of organisations still relying heavily on static credentials in agentic environments, according to the 2026 Infrastructure Identity Survey, cloud SoD failures will increasingly appear as credential governance failures, not just approval-process failures. Practitioners should expect machine identities to be the first place where separation breaks down.

For practitioners

• Define a cloud-specific SoD matrix List prohibited combinations for request, approval, deployment, production access, and audit authority across AWS, Azure, and GCP. Use the matrix as a pre-provisioning control so conflicting access is blocked before it becomes active.
• Include non-human identities in access reviews Review service accounts, API keys, automation scripts, and workloads alongside human users. Remove stale access, revalidate business ownership, and treat dormant machine identities as first-class governance subjects.
• Separate privileged administration from audit oversight Ensure the same team or identity cannot assign high-risk roles and certify them. Split role management from governance review so approval evidence remains independent of operational control.
• Validate cloud access before it is assigned Integrate SoD checks into provisioning workflows and CI/CD gates so new permissions are tested against policy before deployment. That reduces the chance that temporary access or inherited roles create a lasting conflict.

Key takeaways

• Cloud segregation of duties now fails most often because permission changes happen faster than traditional review cycles can observe them.
• Machine identities and automation scripts are central SoD risk points because they accumulate privilege outside normal human governance paths.
• Effective cloud governance requires a pre-assignment conflict matrix, separate audit authority, and continuous review of both human and non-human identities.

Key terms

• Segregation of Duties: Segregation of duties is a governance control that separates sensitive responsibilities so one identity cannot complete a risky action end to end. In cloud environments, it must account for human users, service accounts, automation, and inherited permissions across multiple platforms.
• Non-Human Identity: A non-human identity is any machine-controlled account or credential used by software, workloads, automation, or services. In cloud governance, these identities often hold persistent access and can create hidden risk when they are not reviewed, rotated, and offboarded like human accounts.
• Cloud-Specific SoD Matrix: A cloud-specific SoD matrix is a control model that lists which access combinations are prohibited across cloud workflows and platforms. It helps teams translate governance rules into enforceable checks for provisioning, deployment, approval, and audit responsibilities.
• Identity Blast Radius: Identity blast radius is the amount of damage one identity can cause across systems, workflows, and control boundaries. In cloud settings, it expands when a single account can deploy, approve, and modify production or audit functions without independent oversight.

Deepen your knowledge

Cloud segregation of duties across AWS, Azure, and GCP is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to govern machine identities alongside human access, this is a practical place to start.

This post draws on content published by SecurEnds: segregation of duties in cloud environments across AWS, Azure, and GCP. Read the original.