They were built for a single-application world where conflicts could be enforced inside one system boundary. In SaaS and cloud estates, the same identity can cross multiple platforms and trigger dependencies that single-app rules cannot see. That makes application-only SoD too narrow to capture actual business risk.
Why Legacy SoD Breaks in SaaS and Cloud
Legacy segregation of duties models were designed to stop a single user from approving and executing the same action inside one application. That logic weakens in SaaS and cloud estates, where one NHI or service account can span CRM, data warehouses, CI/CD, IAM, and ticketing systems. The risk is no longer just conflicting buttons inside one app; it is chained access across systems, APIs, and automation paths that the original SoD matrix never mapped.
This is why modern governance has to look beyond application boundaries and align with enterprise control models such as the NIST Cybersecurity Framework 2.0, which treats access, monitoring, and response as cross-domain functions rather than isolated app settings. NHIMG research on The 2024 Non-Human Identity Security Report found that 35.6% of organisations cite consistent access across hybrid and multi-cloud environments as their top NHI challenge, which is exactly where legacy SoD tends to lose visibility.
In practice, many security teams discover SoD gaps only after an API token, integration user, or workflow account has already connected systems that no one reviewed as a combined risk path.
How SoD Should Be Reframed for Distributed Workloads
In cloud and SaaS environments, SoD works best when it is treated as an identity and transaction control, not just an application rule. The practical question becomes: can this identity initiate, approve, move, or persist a sensitive action across multiple platforms? If the answer depends on combining privileges across systems, then the SoD model must be evaluated at the workflow level.
That shift usually involves three moves. First, map critical business processes end to end, including the human users, NHIs, service accounts, and APIs that participate. Second, define conflicting combinations across systems, such as an identity that can create an invoice in one SaaS platform and approve payment in another. Third, enforce compensating controls through least privilege, approval workflows, and monitoring where native SoD logic is too narrow.
- Use identity inventory to link human and non-human access across SaaS, cloud, and automation tools.
- Review API keys, OAuth grants, and service accounts as part of SoD analysis, not as separate hygiene tasks.
- Apply policy at runtime where possible, so access decisions reflect the current context of the request.
NHIMG’s Snowflake breach coverage and the Salesloft OAuth token breach both illustrate a familiar pattern: access that looked acceptable inside one platform became dangerous once the same identity or token was able to traverse adjacent services. These controls tend to break down when organisations rely on static role maps for dynamic SaaS integrations, because the real separation failure happens in the connections between tools.
Where Legacy SoD Models Need Compensating Controls
Tighter SoD enforcement often increases operational friction, so organisations must balance control depth against delivery speed and admin overhead. That tradeoff is real, especially where cloud teams use ephemeral infrastructure, delegated administration, and fast-moving automation. There is no universal standard for this yet, but current guidance suggests that SoD should be paired with continuous access review and transaction monitoring rather than used as a one-time design gate.
Two edge cases matter most. The first is automation-heavy environments, where an NHI may legitimately hold multiple permissions as part of a job flow. In those cases, rigid role separation can create alert fatigue without reducing risk, so the better control is short-lived access tied to task execution and strong audit trails. The second is SaaS tenant sprawl, where the same vendor identity may have different entitlements in multiple workspaces or subsidiaries. A legacy SoD model may appear compliant at the app level while hiding a combined conflict across tenants.
Best practice is evolving toward workflow-aware governance, runtime policy checks, and stronger management of secrets and tokens. NHIMG’s research on the State of Secrets in AppSec shows why this matters: fragmented secrets management and weak remediation practices make it easier for access to persist long after the original business need has passed.
SoD still has value, but in cloud estates it needs compensating controls that follow the identity across systems, not just the role inside one application.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Cross-system access review is central to modern SoD replacement. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Non-human identities often carry the cross-app permissions that break legacy SoD. |
| CSA MAESTRO | MAESTRO addresses trust and control for distributed cloud and agentic workloads. |
Inventory NHIs and service accounts, then trace their permissions across every SaaS and cloud workflow.
