Cross-application duty conflicts stay invisible. A user can look compliant in SAP or in a business app on its own, yet still hold a toxic combination when procurement, payment, finance, or HR entitlements are considered together.
Why application-local SoD checks miss the real control problem
Segregation of Duties only works when you evaluate the full business process, not a single system slice. A person can be clean in one application and still create a fraud path or approval bypass when their combined access across procurement, finance, payments, or HR is considered together. The control failure is the boundary, not the rule set itself.
That is why a local check often gives false comfort. It verifies whether a role pair is allowed inside one application, but it does not reveal whether the same user can start, approve, receive, pay, and reconcile across systems. When duties are split across platforms, the toxic combination is often assembled by the process, not by any one application owner.
Cross-application SoD also depends on how entitlements are modelled. If identity records are fragmented, business roles are inconsistent, or integration accounts are excluded from review, the organisation may miss the actual end-to-end conflict. A narrow application report can therefore look compliant while the joined access path still enables abuse or control override.
Where the hidden conflict usually appears
Most missed conflicts sit in workflows that cross functional systems: procure-to-pay, order-to-cash, payroll, vendor master management, journal posting, and exception handling. The user does not need broad access in any one tool; they only need enough reach across tools to complete an improper sequence without independent review.
That is why cross-system analysis must focus on process steps, not just technical entitlements. A procurement approver in one system may not appear toxic until you add payment release in another, or until HR and finance access are joined to expose a single person’s ability to create, approve, and conceal an exception. The risk is cumulative.
Segregation of Duties (SoD) Guide is useful here because it treats SoD as a ruleset, a mitigation problem, and a cross-process governance issue rather than a single-application checkbox.
PCI DSS v4.0 document library is a practical external reference when payment-related duties or system accounts are part of the same control conversation, because access restriction and account-use rules become materially more sensitive in payment flows.
How to test SoD across applications instead of inside one silo
The right test is to map duties to the business transaction, then join entitlements across all relevant systems that can initiate, approve, change, post, release, or reconcile that transaction. If the conflict only appears after accounts are correlated across SAP, a business app, and a downstream finance or HR platform, that is still a real SoD violation.
OWASP ASVS is a useful external anchor when application-level access checks are part of the control design, but the practitioner lesson is that app-local authorization is only one layer of assurance. It does not replace cross-application entitlement correlation.
NIST SP 800-53 Rev 5 Security and Privacy Controls supports this same view where AC, IA, AU, and CM controls must be read together to govern access, identity, logging, and change in a way that catches end-to-end conflicts.
NIST Cybersecurity Framework 2.0 also fits because SoD is not just an access question, it is a governance, protection, detection, and recovery issue once toxic combinations can span multiple systems.
Risk and Threat Considerations
When SoD is checked only inside one application, the main risk is invisible cumulative privilege. A user may remain within policy in each system separately while still being able to create, approve, and conceal a harmful transaction end to end. That weakens fraud prevention, audit assurance, and the reliability of compensating controls.
Failure mechanism: the organisation enforces rules at the system boundary, but the attacker or insider uses multiple legitimate accounts or roles across applications to assemble the prohibited workflow.
Impact: toxic combinations stay undetected, exceptions become harder to justify, and a control that appears effective in reports can fail at the business-process level.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Cross-application SoD depends on limiting combined access paths that enable toxic workflows. |
| AC-2 — Account Management | SoD reviews rely on accurate account inventory and lifecycle control across applications. | |
| AU-6 — Audit Review, Analysis, and Reporting | Detecting hidden SoD conflicts requires correlating logs and entitlement evidence across systems. | |
| Recommendation — Limit entitlements so no single user can assemble a prohibited end-to-end process across systems. Maintain complete account inventories and review cross-system access together. Correlate audit evidence across applications to spot end-to-end duty conflicts. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SoD is an access-control governance problem spanning multiple systems and business steps. |
| A.5.18 — Access rights | Cross-application SoD depends on reviewing and correcting access rights as a joined set. | |
| Recommendation — Define and enforce access rules that prevent conflicting duties across applications. Review access rights across linked systems for toxic combinations, not in isolation. | ||
Practitioner Guidance
What to prioritise: review the highest-risk business processes first, especially procure-to-pay, payroll, vendor maintenance, and payment release. Those are the places where a cross-system SoD gap usually has the largest operational and fraud impact.
What to verify: make sure the SoD model is built from joined entitlements and workflow paths, not from one application’s role matrix. If your review cannot correlate identities across systems, it cannot prove that the conflict is absent.
Common mistake: treating a clean application report as evidence of compliance. That is only useful if the application is the entire process boundary, which is uncommon in enterprise finance and operations.
Practitioner takeaway: SoD is only meaningful when the control follows the transaction across systems, because that is where toxic combinations usually emerge.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org