Cross-system segregation of duties is the hidden fraud risk

At a glance

What this is: This analysis explains how segregation of duties controls can look effective inside individual systems while still failing across connected environments.

Why it matters: It matters to IAM, IGA, PAM, and audit teams because cross-system authority can create fraud pathways that access reviews, role checks, and system-level controls never see.

👉 Read Gathid's analysis of cross-system segregation of duties risk

Context

Segregation of duties is meant to stop one identity from completing a high-risk process end to end. The problem is that modern enterprises no longer live inside single applications, so access, approval, and reconciliation can be split across systems in ways that make each control look correct in isolation while leaving the overall process exposed. This is a governance problem as much as a fraud problem, because the risk is in how authority combines.

For identity teams, the key issue is that traditional IGA and PAM views are often system-centric, while real-world authority is process-centric. When a user, group, or service account can bridge multiple platforms, the enterprise needs a unified view of entitlements, workflow, and privileged pathways. That is where SoD stops being a checkbox and becomes an enterprise control objective.

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: How can security teams detect SoD gaps that span multiple applications?

A: They need process-aware analysis that traces the complete business transaction across systems, identities, and integrations. Look for combinations of roles, groups, service accounts, and workflow permissions that together enable an end-to-end action. If the path exists, the organisation has a control design problem even if each system passes its own rules.

Q: Who is accountable when a SoD conflict leads to fraud or compliance failure?

A: Accountability usually sits with the control owner, the approver, and the governance function that allowed the conflict to persist. Frameworks such as NIST Cybersecurity Framework 2.0 expect clear ownership of access risk, while audit programs expect documented review and remediation evidence.

Technical breakdown

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

Segregation of duties controls are usually enforced inside a single application or suite, where the engine can compare roles, approvals, and transactions against local rules. That works when initiation and approval stay in one boundary. It fails when an identity starts a process in one system, completes a different step elsewhere, and reconciles the outcome in a third. Each system sees only a legitimate local action, so the full control loop remains invisible unless authority is modelled across systems, not just within them.

Practical implication: build cross-application entitlement mapping so SoD is evaluated against end-to-end workflows, not isolated role assignments.

How inherited access and integrations create hidden SoD pathways

Cross-system SoD violations often emerge from ordinary changes, not from obvious policy failures. Directory group inheritance, shared service accounts, and integration accounts can extend authority across application boundaries even when each entitlement looks defensible on its own. The risk is cumulative: a reporting role plus an operational permission plus an integration bridge can amount to effective control over a process that should be separated. This is why the issue is structural authority accumulation, not a single bad role.

Practical implication: review group membership, service account scope, and system-to-system integrations together whenever you assess SoD exposure.

Why access reviews can certify the wrong thing

Access reviews typically validate whether a user holds a permission, not whether that permission combines with others to create a prohibited end-to-end process. That means an organisation can pass attestation and still leave a complete fraud pathway intact. The failure mode is a mismatch between what is being reviewed and what actually creates risk. In practice, effective SoD governance needs process-aware analysis that tests whether a single identity can execute an entire high-risk sequence across the environment.

Practical implication: supplement access certification with process-path analysis that tests whether a single identity can complete the full control chain.

Threat narrative

Attacker objective: The attacker objective is to complete and conceal a fraudulent or unauthorized business transaction by exploiting authority that spans multiple systems.

1. Entry occurs when an identity gains legitimate access in one system and a separate permission in another, often through normal role evolution rather than malicious compromise.
2. Escalation happens when inherited roles, service accounts, or integrations combine those permissions into a complete control loop spanning initiation, approval, and reconciliation.
3. Impact follows when a single identity can execute or conceal a high-risk transaction without triggering any one system’s local SoD checks.

NHI Mgmt Group analysis

Cross-system SoD failure is an authority-aggregation problem, not a role-design problem. Organisations often treat segregation of duties as a set of local checks inside ERP, finance, or procurement tools, but the real risk emerges when identity authority accumulates across those systems. The control gap is structural because each platform can be compliant while the enterprise remains exposed. For identity and audit teams, the practical conclusion is that SoD must be evaluated as a process property, not a system property.

Identity governance has to shift from entitlement review to control-loop review. Traditional certification tells you what access exists, but not whether those permissions combine into an end-to-end transaction path. That is where IAM, IGA, and PAM intersect with fraud governance. A useful concept here is cross-system authority leakage: legitimate access that becomes risky only when combined across tools, workflows, and integrations. Practitioners need to test for that leakage directly.

Service accounts and integration identities are common blind spots in SoD programmes. These identities are frequently exempted from the same review rigor applied to human users, yet they often connect the systems that make cross-platform control loops possible. When an integration account can move data, trigger workflows, or post reconciliations, it can also collapse separation boundaries. The practical conclusion is to govern non-human access as part of SoD design, not as an afterthought.

Compliance evidence is not the same as risk evidence. Passing a system-level SoD test shows that a rule engine worked as configured, not that fraud pathways are impossible. That distinction matters in regulated environments where audit teams may rely too heavily on local attestation. NIST CSF, NIST SP 800-53 Rev 5, and internal control frameworks all point toward effective control outcomes, which require evidence that authority cannot be recombined into prohibited actions. Practitioners should seek proof of process-level containment, not just policy presence.

What this signals

Cross-system authority leakage: enterprises should treat this as a distinct governance pattern, because the same identity can be harmless inside one platform and risky when its permissions are combined elsewhere. That means identity, audit, and control owners need a single view of business-critical pathways, not separate compliance reports from each application.

The practical programme signal is to make process-aware testing part of SoD governance. If the business cannot show that no identity can complete a prohibited workflow across systems, the control is only partial. That is a stronger bar than role attestation and it aligns better with NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 control expectations.

For practitioners

• Map end-to-end control loops Identify the full initiation, approval, execution, and reconciliation path for each high-risk process, then test whether any single identity can traverse all steps across different systems. Prioritise finance, procurement, and operations flows where authority is split across platforms. Use process mapping as the baseline for SoD validation, not just role matrices.
• Include service and integration accounts in SoD reviews Treat non-human identities that bridge applications as first-class participants in segregation analysis. Review their scopes, token permissions, and workflow triggers alongside human access, because they often connect the systems that create hidden authority accumulation. This is especially important where directory groups or automation accounts can post, approve, or reconcile actions.
• Augment access certification with pathway testing Keep access reviews, but add tests that answer a different question: can this identity complete the prohibited sequence even if no single entitlement looks abnormal? Use scenario-based reviews to uncover cross-system combinations that pass local policy but fail process separation. That gives audit teams evidence aligned to actual business risk.
• Separate governance for human and machine identities Create a control model that distinguishes between human users, service accounts, and application integrations, then apply SoD logic to each according to how they influence business processes. Many hidden violations sit in machine-to-machine links, so the governance model needs to see those links explicitly. This is where identity lifecycle controls and PAM discipline meet fraud prevention.

Key takeaways

• Cross-system SoD failures happen when separate legitimate actions combine into one prohibited control loop.
• System-level compliance can coexist with enterprise-level fraud risk because authority is distributed across applications, identities, and integrations.
• The most effective response is process-aware control testing that includes human and non-human identities in the same governance model.

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 authority: Cross-system authority is the effective power an identity gains when permissions from different applications, roles, groups, or integrations combine. A single entitlement may look harmless on its own, but the combined path can create a complete business process that bypasses intended separation.
• Control loop: The full cycle of observing, deciding, approving, and enforcing security controls. In dynamic AI environments, the control loop must be fast enough to see short-lived identities, generated code, and transient access before they disappear from the review window.
• Authority aggregation: Authority aggregation is the gradual accumulation of permissions that, taken together, create more access than any single role intended. It often happens through role creep, group inheritance, service accounts, and integrations, making it a common source of hidden governance risk.

What's in the full article

Gathid's full analysis covers the operational detail this post intentionally leaves for the source:

• How to map end-to-end SoD workflows across ERP, procurement, finance, and integration layers
• Examples of cross-system authority combinations that create hidden fraud pathways
• Why local access reviews can pass while process-level separation still fails
• Practical steps for turning SoD from a compliance exercise into a control-design test

👉 Gathid's full post covers how hidden authority pathways form across systems and how teams can test them

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity control design to the broader security programmes they support.