How should security teams implement segregation of duties in cloud and IAM environments?

Why This Matters for Security Teams

segregation of duties is not just an audit control in cloud and IAM. It is a practical safeguard against one identity being able to request, approve, deploy, and prove its own access. That pattern becomes especially dangerous when the same administrator, pipeline, or service account can alter privileged roles and then generate the evidence used to show compliance. NIST Cybersecurity Framework 2.0 treats governance and access control as connected disciplines, not separate checkboxes, because control failure usually starts with weak accountability, not a missing rule.

In cloud environments, the risk expands quickly across accounts, tenants, and automation layers. NHIMG research on the 2024 Non-Human Identity Security Report shows that 88.5% of organisations say their non-human IAM practices lag behind or merely match their human IAM maturity, which helps explain why SoD failures keep surfacing in machine identities and infrastructure automation. The practical issue is not whether a role exists, but whether one identity can both change privilege and conceal the change. In practice, many security teams discover SoD gaps only after a cloud admin, CI/CD pipeline, or service principal has already created the access path and the audit trail.

How It Works in Practice

Effective segregation of duties in cloud and IAM starts with mapping the lifecycle of privilege, not just the privilege itself. Teams should separate at least four functions: request, approve, provision, use, and certify. The person or system that approves elevated access should not be the same one that grants it, and the identity that exercises privileged access should not be the one that signs off on the review. Where automation is involved, the same principle applies to service accounts, pipelines, and control-plane identities.

In practice, this usually means combining RBAC with workflow controls, independent review, and tightly scoped break-glass access. Current guidance suggests using policy-as-code to enforce these boundaries at request time, rather than relying on informal process checks after the fact. For cloud operations, that can include separate admin roles for IAM policy changes, role assumption, logging configuration, and evidence export. For NHI governance, the same pattern should extend to secrets management and workload identity. The Azure Key Vault privilege escalation exposure example illustrates how a control plane path can become a privilege path when administrative duties are not split cleanly.

• Use distinct identities for approval, provisioning, and certification.
• Require independent review for changes to privileged roles, trust policies, and secrets access.
• Restrict evidence creation to read-only or reporting identities that cannot modify the underlying control.
• Log administrative actions to immutable systems that the administrator cannot alter.
• Use just-in-time elevation for human admins and short-lived workload credentials for automation.

When cloud teams have to prove SoD, the strongest evidence is usually architectural separation plus enforced workflow separation, not a policy statement alone. These controls tend to break down when infrastructure-as-code pipelines, shared break-glass accounts, and overloaded platform admins all sit inside the same trust boundary because the same actor can both change the control and validate the outcome.

Common Variations and Edge Cases

Tighter segregation often increases operational overhead, so organisations have to balance audit strength against delivery speed. That tradeoff is real, especially in platform engineering teams where one person may wear multiple hats. Best practice is evolving here: there is no universal standard for how many duties must be split in every cloud model, but the rule is consistent that no single identity should be able to create, approve, and certify privileged access without independent oversight.

Some environments need compensating controls rather than perfect separation. For example, a small team may not be able to fully split IAM administration from review, but it can still require an independent approver outside the platform group, enforce time-bound elevation, and use immutable logs for post-change verification. Multi-cloud operations add another layer of difficulty because the same person may manage AWS, Azure, and identity provider policies through different consoles and APIs. The 230M AWS environment compromise and the Snowflake breach both reinforce a familiar lesson: once privilege and evidence creation converge, abuse becomes much easier to hide. Current guidance suggests treating SoD as a control design problem across identity, workload, and logging layers, not only a compliance review item.

Related resources from NHI Mgmt Group

• How should security teams implement segregation of duties in multi-cloud 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 zero trust IAM in cloud-native environments?