Cross-system segregation of duties is the hidden fraud risk

At a glance

What this is: This is an analysis of why segregation of duties controls can look effective inside individual systems while still leaving cross-system fraud pathways open.

Why it matters: It matters because IAM, IGA and audit teams need to understand authority as an enterprise-wide structure, not a set of isolated role checks, if they want SoD controls to reflect real business risk.

Context

Cross-system segregation of duties risk appears when separate systems each enforce their own access rules correctly, yet no control sees how those permissions combine across the enterprise. The primary identity security issue is not missing permissions, but fragmented governance over roles, groups, integrations and service accounts that collectively create end-to-end authority.

That matters to IAM and audit teams because a single identity can legitimately hold initiation rights in one application, approval rights in another and reconciliation rights in a third without any individual system recognising the conflict. In practice, the enterprise boundary, not the application boundary, is where SoD assurance breaks down.

Key questions

Q: What breaks when segregation of duties is the only control in place?

A: SoD blocks some toxic combinations, but it does not clean up stale, unused, or orphaned access. Users can change roles, projects can end, and temporary access can become permanent without any SoD alert. A programme built only on prevention still accumulates governance debt over time.

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

A: Access reviews usually validate entitlements in isolation, not how those entitlements combine across platforms. A user can therefore appear compliant in every system while still holding enough combined authority to execute a prohibited process. The risk comes from authority aggregation, not from a single obvious mispermission.

Q: What are the signs that Segregation of Duties is failing in an organisation?

A: Common signs include one user holding both initiation and approval rights, repeated exceptions to workflow rules, weak audit trails, and access that does not match job responsibilities. If transaction review is slow or inconsistent, conflicts can remain hidden. These symptoms usually point to poor access governance, incomplete role design, or reporting that does not reliably surface violations.

Q: How should IAM and audit teams govern SoD across connected platforms?

A: They should move from system-level rule checks to process-level authority mapping. That means reviewing the full workflow, the identities that can touch it, and the combinations of roles, groups and integrations that complete it. The question is not whether each system is clean, but whether any identity can finish a high-risk process end to end.

Technical breakdown

Why system-level SoD checks miss cross-platform control loops

Segregation of duties is usually enforced as a local rule set inside an ERP, procurement or finance application. Those rules work as designed, but they only evaluate conflicts within that application’s own entitlement model. Cross-system fraud risk appears when the workflow is distributed, so one system sees initiation, another sees approval and a third sees reconciliation. None of them can infer that the same identity is completing a full high-risk loop. The technical problem is not policy absence. It is policy fragmentation across disconnected authorization domains.

Practical implication: Map end-to-end business processes across systems and test whether any identity can complete the full control loop without tripping a conflict.

How roles, groups and integrations create hidden authority chains

Authority often accumulates gradually through role drift, inherited directory groups and integration accounts that bridge platforms. A reporting role in one application, an operational entitlement in another, and a service account linking both can together create a path that no designer intended. Because each access grant looks defensible on its own, the combined effect is easy to miss during periodic reviews. This is where cross-system SoD becomes a governance problem rather than a single-application configuration issue. The combined structure of access is what matters, not the isolated entitlement.

Practical implication: Inventory role inheritance, group membership and integrations together so reviewers can see compound authority rather than single-system permissions.

Why access reviews can certify risk instead of removing it

Traditional recertification processes focus on whether a user still needs a given entitlement, but they rarely test how that entitlement interacts with access elsewhere. That creates a blind spot: a user can pass every individual review and still retain a complete fraud pathway across applications. Service accounts and shared integrations make this worse because they can extend authority beyond the human role that originally justified access. The result is a control environment that measures access quantity, but not process completion capability.

Practical implication: Add process-level SoD tests to certification workflows so reviewers check whether a user can still execute a prohibited sequence end to end.

NHI Mgmt Group analysis

Cross-system SoD failure is an authority-structure problem, not an access-list problem. Enterprises often believe their controls are strong because each application can enforce separation locally. That view breaks down once identities, groups, integrations and workflows span multiple systems. Practitioners need to treat authority as a graph across the business, not as a set of discrete application permissions.

The governance blind spot is the assumption that system compliance equals enterprise compliance. This article shows that isolated reviews can certify a dangerous configuration as acceptable when the conflict only appears in combination. The result is a false negative that audit teams should expect in distributed environments, especially where ERP, procurement and reconciliation tools are loosely connected.

Cross-system control loops are the named risk to watch. That phrase captures the problem more precisely than generic SoD language because the danger is not one entitlement, but a sequence that crosses trust boundaries. NIST-CSF PR.AA-05 and CIS account management principles are relevant here, but the bigger lesson is that controls must reason over workflows, not just systems.

Service accounts and inherited group membership are the most underestimated amplifiers of SoD risk. Human role design is only one part of the picture. When a service account or directory group links otherwise separate applications, it can silently turn acceptable access into a complete fraud path. Practitioners should assume these bridges create governance debt until proven otherwise.

Auditability depends on being able to reconstruct who can finish the process, not just who touched it. That is the practical standard cross-system SoD should meet. If an organisation cannot show whether a single identity can complete initiation, approval and reconciliation together, the control is not describing real operating risk.

From our research library:

• Nearly 60% of companies reported that fraud losses were still increasing in 2025.

What this signals

Cross-system SoD is a governance gap that conventional IAM tooling does not close on its own. The reader’s programme needs a process view of authority, not just a catalogue of entitlements. If initiation, approval and reconciliation live in different applications, teams should assume the control boundary is already wider than the access review boundary.

Cross-system control loops should become a named risk category in audit and identity programmes. That framing is useful because it shifts attention from individual role conflicts to complete business pathways. NIST-CSF and IAM governance practices both support that shift, but the operational goal is simpler: prove that no identity can complete the prohibited sequence across systems.

For practitioners

• Map end-to-end process authority Trace initiation, approval, reconciliation and release across every system that participates in the workflow, then test whether one identity can complete the sequence.
• Review cross-application entitlements together Combine role, group, integration and service account data into one view so reviewers can detect compound access that no single system exposes.
• Add process-level SoD tests to certification Require recertification to answer whether the user can still execute a prohibited business sequence across systems, not just whether each entitlement is individually justified.
• Flag bridging identities and accounts Identify identities that connect finance, procurement and reconciliation systems, because those bridges often create the hidden control loop.
• Document compensating controls for structural gaps Where enterprise-wide SoD cannot be enforced automatically, record compensating detective and approval controls that specifically address cross-system combinations.

Key takeaways

• Cross-system SoD failures happen when individually valid permissions combine into an end-to-end workflow that no single application can see.
• The core evidence problem is structural, because isolated compliance checks can miss how authority accumulates across roles, groups, integrations and service accounts.
• Enterprises need process-level access review and workflow mapping if they want segregation of duties controls to reflect actual fraud risk.

Key terms

• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Cross-System SoD: Cross-system SoD is the enterprise-wide version of segregation of duties, where the conflict only appears when access from multiple applications is combined. It is a governance problem, not a single-application misconfiguration, because each system may be compliant on its own while the overall workflow remains unsafe.
• Authority graph: A relationship model that shows how people, service identities, roles, systems and credentials connect to create real authority. It helps teams see escalation paths, toxic combinations and hidden privilege concentration that account-level governance often misses.
• Bridging Identity: A bridging identity is a user, service account or integration that connects separate systems and can unintentionally extend authority between them. These identities matter because they often create the hidden path that turns isolated entitlements into end-to-end control over a process.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to connect governance, privilege and lifecycle control across modern identity programmes.