How should security teams implement segregation of duties in multi-cloud environments?

Why This Matters for Security Teams

segregation of duties in multi-cloud is not just a compliance checkbox. It is a way to prevent a single person, service account, or automation path from creating and approving the same risky change. In cloud estates, the problem is amplified by overlapping control planes, inherited permissions, and machine identities that can move faster than review cycles. Current guidance from NIST Cybersecurity Framework 2.0 still maps well here: separate authority, verify access, and keep privileged actions accountable.

The practical risk is easy to miss because cloud teams often focus on who can deploy, while attackers and insiders exploit who can also approve, attach, or audit that deployment. NHIMG research shows multi-cloud consistency is a real problem: 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge. That gap is where SoD fails when it exists only as a policy matrix instead of an enforced control. In practice, many security teams discover SoD drift only after a privileged change has already been made, not through intentional review.

How It Works in Practice

Effective SoD starts by defining prohibited combinations, then encoding them into access workflows before permissions are issued. For example, the same identity should not be able to request, approve, deploy, and audit a production change across AWS, Azure, and GCP. That separation must apply to human admins, CI/CD service accounts, and any non-human identity that can call infrastructure APIs. For NHI-heavy environments, this is where The 2024 Non-Human Identity Security Report is useful: 59.8% of organisations see value in dynamic ephemeral credentials, which supports SoD by reducing how long any one actor can accumulate privilege.

Practitioners usually need four control layers:

• Pre-request checks that block forbidden role combinations before access is granted.
• Approval workflows that require a different identity class than the requester.
• Deployment guardrails that prevent a deployer from also changing policy, secrets, or network exposure.
• Audit separation so the entity performing the action cannot also certify the action.

For implementation, teams should use RBAC only as a coarse starting point, then add policy-as-code, JIT access, and privileged session controls. Where possible, map cloud permissions to business functions rather than job titles, because job titles drift while cloud entitlements do not. The NIST Cybersecurity Framework 2.0 governance and protection functions help structure this, but the operational test is simple: no single identity should be able to both make and bless a sensitive change. This guidance tends to break down in large multi-account platforms when legacy IAM roles are reused across environments because inherited trust relationships blur the separation.

Common Variations and Edge Cases

Tighter segregation often increases operational overhead, requiring organisations to balance change velocity against abuse resistance. That tradeoff becomes more visible in DevOps-heavy estates, where teams want self-service access and automated releases. Current guidance suggests that the answer is not to weaken SoD, but to shift it from manual approvals to runtime controls that are easier to sustain.

There is no universal standard for how fine-grained the split should be. In smaller cloud environments, separating request and approval may be enough; in regulated or high-risk environments, teams should also split build, deploy, break-glass, and audit functions. The challenge is that some workflows are inherently shared, especially incident response and emergency remediation. In those cases, use time-bound exceptions, post-event review, and explicit compensating controls rather than permanent shared privilege.

Cloud-native attack paths often expose where SoD weakens under pressure. The Codefinger AWS S3 ransomware attack and Snowflake breach both underscore how quickly over-broad access and weak workflow separation can become an incident. For teams aligning to ZTA, SoD should be treated as an identity-layer control, not a procurement or audit exercise. The main exception is highly automated platform engineering, where too much manual separation can slow safe delivery unless JIT approval and workload-specific policies are built in from the start.

Related resources from NHI Mgmt Group

• How should security teams implement segregation of duties automation in hybrid environments?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• How should security teams implement JIT access in multi-cloud environments?