Why do cloud admin roles make segregation of duties harder to enforce?

Why cloud admin roles concentrate power so quickly

Cloud administration is usually built around platform-wide roles that can create resources, change policies, assign permissions, and read logs from one control plane. That design is efficient, but it compresses multiple checks into a small number of roles. When those roles are broad, separation of duties becomes harder because the same actor can touch provisioning, access control, and oversight without a natural boundary between them.

This is also why role design matters more in cloud than in many legacy environments. A role that looks operationally convenient can quietly combine requests, approvals, implementation, and review into one identity path. IAM and IGA Basics explains how access governance is supposed to separate entitlement decisions from execution, which is exactly the boundary cloud roles tend to blur when they are too powerful.

Cloud platforms often reward speed and scale, so organisations inherit prebuilt admin roles that are intentionally broad. That helps with automation and standard operations, but it also means the practical unit of privilege is often the role itself rather than the task being performed. If that role is reused across teams or environments, the SoD problem is not just technical, it is structural.

Why SoD breaks when provisioning and review live in the same place

segregation of duties depends on keeping incompatible actions apart, such as creating access, approving access, and auditing access. In cloud, those actions are often available through the same identity, the same API surface, or the same administrative console. Once a single admin can both grant a privilege and verify their own work, the control becomes self-referential instead of independent.

The weakest point is not always the permission itself, but the combination of permissions. A cloud admin who can modify a role, attach a policy, and suppress or alter logging can create an access path that is difficult to challenge after the fact. Segregation of Duties (SoD) Guide is useful here because it shows that SoD rules must be written around toxic combinations, not just around single entitlements.

In practice, cloud SoD failures often appear when teams use broad platform roles as a shortcut for day-to-day work. The role may be justified as temporary, but temporary access that is rarely reviewed becomes standing privilege by another name. The result is that the control model says “two people,” while the operational model behaves like one person with too much reach.

How cloud operating models make enforcement harder than policy suggests

Cloud governance is harder because the environment is dynamic. Permissions are often granted through infrastructure as code, automation, delegated admin rights, or provider-native policy services, so the control boundary is not a single badge or account but a moving set of configuration states. That makes SoD dependent on both identity design and change discipline.

Another challenge is that cloud admin activity often crosses account, subscription, project, and workload boundaries. One administrator may legitimately need broad reach to support production, but the same reach can also let that person bypass review or create exceptions that are hard to distinguish from normal operations. This is why cloud SoD usually needs explicit role decomposition, not just a rule that “admins should not do everything.”

External control guidance reflects this same pattern. NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST SP 800-207 Zero Trust Architecture both reinforce least privilege and continuous verification, which are the control ideas cloud SoD depends on when roles are broad and access is highly dynamic.

Risk and Threat Considerations

Cloud admin roles create a concentration risk because one compromised or over-assigned role can affect provisioning, access control, and visibility at the same time. That increases blast radius and makes it easier for misuse or compromise to hide inside normal operational activity.

Failure mechanism: A role with overlapping create, approve, and observe capabilities removes independent review. An insider, contractor, or attacker who obtains that role can grant access, change policy, and reduce the chance of timely detection.

Impact: The organisation can lose trust in its access records, its audit trail, and its ability to prove that approvals were independent. In regulated or sensitive environments, that can also turn a routine admin role into a systemic control failure.

Practitioner Guidance

What to prioritise: Start by identifying cloud roles that can both change access and verify the result, then split them into distinct build, approve, and review functions where the platform allows it. The most important question is whether any one role can create its own exceptions.

What to verify: Check whether logging, policy administration, and privilege assignment are controlled by different people or only separated on paper. If the same team owns all three, SoD is probably enforced by process, not by the platform.

Common mistake: Treating “admin” as a single job title instead of a bundle of incompatible duties. That shortcut is often acceptable for emergency access, but not for steady-state operations.

Practitioner takeaway: Cloud SoD fails less because cloud is inherently ungovernable and more because its role model often reflects operational convenience rather than independent control.

Related resources from NHI Mgmt Group

• Why do standing admin roles make cloud risk harder to contain?
• Why do hybrid IAM environments make Segregation of Duties harder to enforce?
• Why do cloud environments make zero trust harder to enforce?
• Why do service accounts and automation identities make segregation of duties harder?