Why do cross-system SoD violations create fraud risk even when access reviews pass?

Why This Matters for Security Teams

Cross-system segregation of duties fails when reviewers assess each application as if it were a closed island. Fraud rarely requires a single toxic entitlement in one platform; it often emerges when legitimate permissions across ERP, procurement, HR, payment, or admin tools combine into an unsafe end-to-end workflow. That is why control owners can sign off on access reviews and still leave a path for invoice creation, vendor setup, approval, and payment release to sit in one person’s effective control.

This is a governance problem as much as an access problem. The relevant question is not whether a user can justify each role individually, but whether the combined authority permits a prohibited business outcome. Current guidance from the NIST Cybersecurity Framework 2.0 supports this broader view by tying governance and risk management to operational controls, not isolated account checks. In practice, many security teams encounter SoD failures only after a payment exception, vendor dispute, or audit finding exposes how the workflow actually operated, rather than through intentional control design.

How It Works in Practice

Effective SoD analysis needs to move from entitlement review to process mapping. That means identifying the business steps that must never be controlled by the same person or same trusted identity chain, then tracing which systems and service accounts can satisfy each step. A person may have no obviously excessive access in any one platform, yet still be able to trigger a fraud path by combining request, approve, modify, export, and release privileges across platforms.

Teams usually need to model three layers at once:

• business workflow SoD, such as initiate, approve, and pay
• system-level entitlements, including roles, groups, and delegated admin rights
• identity linkage, including shared credentials, proxies, bots, and service accounts

That last layer matters because cross-system risk is often amplified by non-human identities and automation. If an AI agent, integration account, or script can move data between systems, then human access reviews may pass while machine-mediated authority still collapses the SoD boundary. The OWASP Non-Human Identity Top 10 is useful here because it highlights the governance gaps that appear when machine identities are not inventoried, bounded, and reviewed with the same rigor as human users.

Practical control design usually includes preventive policy rules, detective analytics, and compensating approvals. NIST control guidance in NIST SP 800-53 Rev. 5 Security and Privacy Controls is especially relevant for access enforcement, separation of duties, and account management. In mature environments, SoD should be tested against actual transaction paths, not just role lists, because role catalogs often lag behind the way work is really performed. These controls tend to break down when multiple systems use different role taxonomies and a shared service account can complete the full process without triggering a review exception.

Common Variations and Edge Cases

Tighter SoD controls often increase workflow friction, requiring organisations to balance fraud prevention against business speed and exception handling. That tradeoff becomes more visible in shared-service environments, emergency access scenarios, and high-volume finance operations where a single operator may need temporary cross-function authority.

Best practice is evolving for environments that rely on automation, AI assistants, or outsourced operations. There is no universal standard for this yet, but current guidance suggests treating machine-mediated access as part of the same SoD analysis, not as a separate technical detail. A bot that creates records, an AI agent that prepares approvals, or a privileged support script that can also submit changes may create effective control collapse even when each component looks acceptable on its own.

Edge cases also appear when organisations inherit merged identity stores, regional finance processes, or third-party platforms that do not expose enough workflow detail for direct policy enforcement. In those cases, detective controls matter more: transaction logging, exception review, privileged session monitoring, and periodic scenario testing against known fraud paths. The key is to evaluate whether one identity, human or non-human, can complete all required steps for a prohibited action. Cross-system SoD programs are weakest when control testing stops at provisioning records and never simulates the real transaction sequence.

Related resources from NHI Mgmt Group

• Why do AI fraud tools create risk even without frontier model access?
• Why do cross-application SoD conflicts create more risk than single-system conflicts?
• Why do SaaS integrations create NHI risk even when access is short lived?
• Why do OAuth applications create persistent access risk even after off-boarding?