Cross-system conflicts survive because each application may appear compliant on its own while the combined access path creates excessive privilege or segregation-of-duties failure. The graph matters because it evaluates the whole entitlement chain, not just isolated application records.
Why per-application checks miss the real SoD problem
Checking toxic role combination inside one application treats segregation of duties as a local permission issue. That misses the cross-system path: a user can hold one entitlement in one app and the conflicting entitlement in another, and the combined effect still creates an unsafe business capability. The failure is not in any single record, it is in the entitlement chain.
In practice, this means the control can certify two separate views as acceptable while the joined path still enables purchase, approve, reconcile, export, or change actions that should never sit with the same person. The graph view is what exposes the conflict because it follows how access accumulates across applications, platforms, and shared identities.
When organisations only test locally, they also lose context about inherited access, nested groups, linked service accounts, and shared admin pathways. A role may look clean in isolation but become toxic once downstream permissions, delegated access, or federation are included in the effective access picture.
Where the control breaks down operationally
The operational failure is usually a visibility gap rather than a policy gap. Application owners often know their own role model, but they do not know how their roles interact with other systems, so exceptions survive as long as each app passes its own review. That is why isolated certification tends to produce false confidence.
Per-application checking also struggles when business processes span finance, procurement, HR, ticketing, or cloud administration. The toxic combination may only become obvious when you model the end-to-end process, not when you compare two role names in separate repositories. Segregation of Duties (SoD) Guide covers how toxic combinations, mitigations, and compensating controls need to extend beyond one application boundary.
For teams that rely on periodic access reviews, the failure is often stale evidence. A point-in-time review can pass while the true risk appears only after a later role grant, new integration, or added privilege path. The control has to be evaluated on the combined entitlement state, not the historical state of one system.
What the graph reveals that records do not
A graph-based entitlement model shows whether access paths converge on the same sensitive action even when the source roles differ. That is the key distinction: the question is not whether two roles have the same label, but whether they ultimately enable incompatible actions in sequence. Without that join, cross-system SoD violations remain hidden.
This is also where compensating controls become easier to judge. If a conflict is unavoidable, the graph helps you test whether the mitigation actually reduces the effective path, or merely documents the exception. That distinction matters when the environment includes shared accounts, service identities, or delegated administration, because the real authority may sit outside the original application owner’s review scope.
Risk and Threat Considerations
Per-application SoD checks can leave a materially dangerous gap: the organisation may believe duties are separated when the combined access path still supports fraud, self-approval, unauthorized change, or data exfiltration. The larger the shared identity or cross-system workflow footprint, the more likely the local check understates exposure.
Failure mechanism: Conflicting entitlements are approved in separate systems, then combine into an end-to-end path that grants excessive privilege or breaks segregation of duties at the business-process level.
Impact: Fraud opportunities, control bypass, audit findings, and undetected privilege accumulation can persist until the effective access path is modelled across systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | Directly addresses conflicting duties across systems and workflows. |
| AC-6 — Least Privilege | Excess privilege often accumulates when isolated app checks miss combined access. | |
| Recommendation — Enforce separation of duties across the effective access path, not per application. Remove any entitlement that contributes to cross-system excessive privilege. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control must govern the effective permissions chain, not only local app roles. |
| Recommendation — Define access control rules that account for cross-system entitlement combinations. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Access reviews need to validate effective access and toxic combinations across applications. |
| Recommendation — Review and revoke access based on combined entitlement risk, not isolated system reports. | ||
| SOC 2 (AICPA) | CC6.1 — Logical and Physical Access Controls | Logical access controls must prevent conflicting access from surviving separate reviews. |
| Recommendation — Design logical access controls to detect and block toxic role combinations end to end. | ||
Practitioner Guidance
What to verify: Validate SoD against effective access, not role names, by tracing how permissions compose across applications, federated access, shared admin paths, and any downstream workflow tools.
Common mistake: Treating a clean application-by-application report as proof that the business process is segregated. If the review cannot answer “can this person complete the incompatible sequence end to end?”, it is incomplete.
Practitioner takeaway: A SoD control that does not model the entitlement chain is a documentation control, not an enforcement control.