Why does SoD often fail in cloud and SaaS environments?

Why This Matters for Security Teams

Segregation of duties is meant to prevent one identity from creating, approving, and executing the same sensitive action. In cloud and SaaS, that separation is harder to preserve because privileges are modular, API-driven, and often delegated through roles, service accounts, and connectors that do not look risky in isolation. NIST Cybersecurity Framework 2.0 treats identity governance as a core security outcome, but the control objective only works when entitlement data is current and complete.

This is where teams get surprised: a principal can hold several narrow permissions that combine into an effective end-to-end path. That pattern shows up in incidents such as the Snowflake breach and the Salesloft OAuth token breach, where exposed identities and over-broad trust relationships created real operational risk. NHI Management Group’s 2024 Non-Human Identity Security Report found that only 19.6% of security professionals expressed strong confidence in their ability to securely manage non-human workload identities, which is a useful signal for how quickly cloud-scale access models can drift out of control. In practice, many security teams discover SoD failure only after a workflow has already been automated around the gap, rather than through intentional review.

How It Works in Practice

In cloud and SaaS environments, SoD usually fails because the control is designed as a governance rule, while the environment behaves like a constantly changing graph of entitlements. A user may be unable to approve and execute a payment in one system, but still be able to create an API integration, assign a delegated admin role, and trigger the same outcome through a different path. That is why static role design and quarterly access reviews often lag behind real usage. Current guidance suggests pairing SoD with live entitlement monitoring, policy-as-code, and event-driven recertification rather than relying on a document-level segregation matrix.

Practically, strong programs do three things:

• Map effective privilege across human, NHI, and SaaS admin paths, not just named roles.
• Continuously evaluate toxic combinations across consoles, APIs, OAuth grants, and automation tokens.
• Require just-in-time elevation and time-bounded approval for sensitive actions instead of permanent compatibility-based access.

This matters especially for non-human identities because a single workload can inherit access through cloud IAM, SaaS delegated admin, secret stores, and CI/CD pipelines. The NIST CSF identity outcomes and NIST Cybersecurity Framework 2.0 are useful anchors, but they do not replace the need for live entitlement correlation. NHI Management Group’s 2024 Non-Human Identity Security Report also highlights the demand for dynamic ephemeral credentials, which is directly relevant when standing privileges make SoD impossible to enforce consistently. These controls tend to break down when one SaaS tenant can delegate admin rights to another integration because privilege inheritance becomes indirect and difficult to recertify.

Common Variations and Edge Cases

Tighter SoD often increases operational overhead, requiring organisations to balance control integrity against deployment speed and automation reliability. That tradeoff is most visible in environments that use CI/CD, serverless functions, or SaaS marketplaces, where an approval workflow can be technically separate but functionally equivalent to execution authority.

There is no universal standard for this yet, but current guidance suggests treating these cases as risk-based exceptions rather than assuming a classic human SoD model will fit. For example, a build pipeline may be allowed to deploy code but not approve its own release, while a finance SaaS integration may be allowed to reconcile transactions but not create vendor records. The challenge is that cloud tools often blur those boundaries through delegated scopes and nested admin roles. This is why the Azure Key Vault privilege escalation exposure and the Codefinger AWS S3 ransomware attack are useful reminders that effective privilege is often larger than the label suggests. Best practice is evolving toward continuous controls, with SoD checks triggered by change events, token issuance, and role binding updates rather than by periodic review alone.

Related resources from NHI Mgmt Group

• How should security teams identify shadow data across cloud and SaaS environments?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• Why do segregation of duties controls fail in cloud and SaaS environments?