They break down because access governance is often built around one system at a time, while real users and service identities operate across several platforms. A role that looks harmless in one application can complete an incompatible workflow when combined with another entitlement elsewhere. SoD fails when the control model stops at the platform boundary.
Why This Matters for Security Teams
segregation of duties is meant to stop one identity from completing a sensitive workflow end to end, but that assumption weakens fast in hybrid estates. In one application, a role may be read-only; in another, the same person or service identity can approve, deploy, or release. When control design stops at the application boundary, the combined effect of several “safe” entitlements becomes a SoD violation.
This is especially visible in environments where service accounts, API keys, and human access all participate in the same business process. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which makes cross-platform entitlement review difficult even before SoD logic is applied. The problem is not just missing policy, but missing identity context across systems. The Ultimate Guide to NHIs — Standards and the NIST Cybersecurity Framework 2.0 both point toward governance that follows the identity and the risk, not just the application owner.
In practice, many security teams discover SoD failures only after a real workflow has already crossed system boundaries and produced an unauthorized business action.
How It Works in Practice
Hybrid SoD breaks down because modern workflows are rarely confined to a single platform. A user may request in one system, approve in another, and trigger execution through a third-party integration. The same issue appears with NHIs: a CI/CD service account can have build rights in one tool and deployment rights in another, creating an end-to-end path that no single application owner sees.
Effective control design starts by mapping the full business process, then identifying incompatible actions across applications, not just conflicting roles inside one app. Security teams usually need three layers of analysis:
- Identity linkage across systems, so human users and NHIs can be correlated reliably.
- Entitlement composition analysis, so individually acceptable permissions are evaluated as a combined workflow.
- Exception handling for compensating controls, including approvals, monitoring, or JIT elevation where strict SoD is not technically possible.
Current guidance suggests that this should be treated as a governance problem as much as a technical one. The Ultimate Guide to NHIs — Standards is useful for framing lifecycle, rotation, and visibility expectations, while the NIST Cybersecurity Framework 2.0 helps translate the issue into risk management, access control, and continuous monitoring requirements. In mixed environments, policy-as-code and centralized entitlement review are often the only practical way to detect toxic combinations before they are used.
These controls tend to break down when legacy systems, SaaS platforms, and automation pipelines each enforce their own local roles because no single control plane can see the full chain of access.
Common Variations and Edge Cases
Tighter SoD enforcement often increases operational overhead, requiring organisations to balance fraud prevention against delivery speed and support complexity. That tradeoff becomes sharper in multi-application environments where the same task may span ERP, ticketing, cloud infrastructure, and automation tooling. There is no universal standard for this yet, so best practice is evolving rather than settled.
One common edge case is “approval by proxy,” where a service account or workflow bot performs the technical action after a human approves it elsewhere. Another is vendor-managed integration, where an external platform has enough access to complete a restricted process if combined with internal credentials. These cases do not always look like classic SoD violations in a permissions report, but they create the same business risk. The Ultimate Guide to NHIs — Standards shows why secret sprawl and weak offboarding make these paths harder to govern at scale.
For programmes with heavy automation, current guidance suggests focusing on process-level controls: shorten credential lifetimes, separate request and execution identities, and log cross-system workflow completion in a way that supports review. SoD becomes much harder to sustain when one identity can inherit context from another through shared tokens, poorly scoped API access, or unmanaged exceptions.
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 failures worsen when NHI secrets and lifecycles are poorly controlled. |
| NIST CSF 2.0 | PR.AC-4 | SoD is an access control issue that spans multiple systems and identities. |
| NIST AI RMF | Automated decision and action chains need governance across the full process. |
Track NHI lifecycle controls and remove credentials that enable cross-system toxic combinations.
Related resources from NHI Mgmt Group
- Why do privileged access controls break down in hybrid environments?
- Why do SOX access controls break down as environments get more complex?
- Why do segregation of duties controls fail in cloud and SaaS environments?
- How should security teams implement segregation of duties automation in hybrid environments?
