They fail because authority is distributed across many consoles, delegated roles, and automation paths, so conflicts can hide outside one system. A clean policy in one platform does not prevent overlapping privilege elsewhere. Teams need cross-system entitlement mapping and conflict detection to see the full risk picture.
Why Segregation of Duties Breaks Down in Cloud and SaaS
segregation of duties was built for a world where one system held the full workflow and a few named humans moved work through it. Cloud and SaaS break that assumption. Admin rights, API tokens, delegated app permissions, and workflow automation can each bypass a clean RBAC chart, so the conflict is often invisible unless entitlement data is joined across platforms. NIST guidance on identity and access management still matters, but the operating model now spans many control planes, not one.
That is why breach patterns keep repeating through indirect access paths such as the Snowflake breach and the Salesloft OAuth token breach: the risk was not simply a user having too much access in one console, but the way trusted integrations, stored secrets, and delegated sessions created overlapping authority. In practice, many security teams only discover the SoD gap after an audit exception, incident review, or customer escalation, rather than through intentional control design.
Current guidance from NIST Cybersecurity Framework 2.0 supports stronger governance and access review, but the real challenge is operational: entitlement evidence is fragmented across IdP, SaaS admin, cloud IAM, CI/CD, and automation layers.
How It Works in Practice
Effective SoD in cloud and SaaS starts by treating identity, not the application, as the unit of analysis. A control is only meaningful if it can map a person, NHI, or service account to all the places that identity can act. That includes RBAC roles, group membership, OAuth grants, service principals, JIT elevation paths, and secrets stored in vaults or pipelines. Without cross-system mapping, teams can approve a role in one tool while an adjacent token or delegated permission silently preserves the same power elsewhere.
The practical workflow is usually three steps: first, inventory all entitlements and trust paths; second, build conflict rules that compare incompatible permissions across systems; third, evaluate those rules continuously, not just during quarterly access reviews. Mature programs also separate standing access from task-based access by using ZSP, JIT issuance, and short-lived credentials. That matters because cloud and SaaS conflicts often appear as combinations, not single entitlements.
- Link human admin roles, NHI permissions, and automation accounts in one entitlement graph.
- Flag conflicts where request, approve, deploy, and audit capabilities overlap.
- Prefer ephemeral access over long-lived static secrets for privileged operations.
- Use policy-as-code so checks run at request time, not after a control failure.
For NHI-heavy environments, the lesson is reinforced by cases like the Azure Key Vault privilege escalation exposure and the BeyondTrust API key breach, where privileged access and secrets handling became the real control boundary. NIST Cybersecurity Framework 2.0 is useful here because it pushes teams toward asset visibility, access control, and continuous improvement. These controls tend to break down when SaaS applications expose opaque delegation chains and cloud administrators can grant indirect access through service roles and automation.
Common Variations and Edge Cases
Tighter SoD often increases operational overhead, requiring organisations to balance assurance against provisioning speed and support burden. That tradeoff is real, especially where engineering, security, and operations share the same platforms and need emergency break-glass access.
One common edge case is “approved by policy, unsafe in combination.” A finance approver may not be able to execute payments directly, yet still be able to grant a workflow exception or approve an integration that does. Another is the autonomous workflow that inherits human authority through an agent, bot, or pipeline runner. In those environments, static RBAC is too blunt because the actual risk depends on intent, context, and what the system is trying to do right now. Best practice is evolving toward real-time authorisation checks, JIT credentials, and workload identity for machines, but there is no universal standard for this yet.
That is especially important in SaaS sprawl, where one platform may look compliant while another holds the compensating privilege. The DeepSeek breach and the Codefinger AWS S3 ransomware attack show how quickly secrets exposure and over-permissioned automation can turn into cross-system abuse. Organisations should therefore review SoD not only for humans, but for service accounts, connectors, and AI-enabled workflows that can act autonomously under inherited authority.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | SoD fails when NHI credentials and roles overlap across systems. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be limited and reviewed across cloud and SaaS. |
| NIST AI RMF | Autonomous workflows need risk governance beyond static role design. |
Govern agentic and automated access with context-aware controls and accountable oversight.
Related resources from NHI Mgmt Group
- 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 govern workload identity across mixed cloud environments?
- How should security teams enforce segregation of duties in IAM workflows?
