TL;DR: Traditional separation of duties checks can miss toxic access combinations that span ERP, SaaS, cloud, API, automation, and AI-driven workflows, leaving organisations compliant in each system yet exposed across the full process, according to Saviynt. The real control problem is business-process-centric governance: access review, entitlement visibility, and remediation must follow the transaction, not stop at the application boundary.
At a glance
What this is: This is an analysis of how application-by-application SoD controls miss risky access combinations that emerge only when permissions are viewed across connected business processes.
Why it matters: It matters because IAM and IGA teams need to govern entitlements across human, NHI, and AI-assisted workflows as one process, not as isolated application reviews.
Context
Cross-application separation of duties is the problem that appears when no single application has the full picture of a business process. A user can be clean in SAP, Salesforce, Coupa, or Workday individually and still hold a risky combination when those permissions are considered together.
The governance gap is structural, not cosmetic. Finance, HR, procurement, cloud systems, APIs, automation, service accounts, and AI-driven workflows now participate in the same transaction chain, so entitlement review has to follow the process across boundaries instead of stopping at the application boundary.
Key questions
Q: What breaks when SoD is checked only inside one application?
A: 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.
Q: Why do cross-application access combinations create fraud risk?
A: Because two valid permissions can combine into one unsafe outcome. If one identity can create or modify a vendor in one system and approve payment in another, it can move a transaction from setup to release without another accountable checkpoint. The risk rises when ownership, approvals, and review evidence are split across platforms.
Q: What are the signs that cross-application SoD is failing?
A: Look for clean system-by-system reviews that still leave unresolved transaction risk, fragmented audit evidence, and identities that can influence multiple steps in the same process. Another warning sign is when service accounts or integrations are excluded from SoD scoping even though they move the data or trigger the approvals that complete the workflow.
Q: How should teams govern SoD across human and non-human identities?
A: Govern the workflow, not just the person. Every identity that can alter, approve, or route a sensitive transaction should be in scope, including service accounts, API integrations, bots, and AI agents. The review model needs one ownership chain, one entitlement picture, and one remediation path across all participating identities.
Technical breakdown
Why application-level SoD misses process-level risk
Traditional SoD logic evaluates whether one identity has conflicting rights inside a single system. That model works when the risky action is fully contained in one application, but it breaks when initiation, approval, modification, and payout are distributed across multiple platforms. The control can certify each system correctly and still miss the combined entitlement pattern that creates fraud or control risk. In modern environments, the real object of governance is the transaction path, not the individual application role.
Practical implication: Map SoD rules to end-to-end business processes, not to isolated application role sets.
How cross-application access becomes toxic
Cross-application SoD risk emerges when two reasonable permissions combine into one dangerous capability. A user who can create or modify a vendor in one system and approve payment in another can control the same transaction from setup to release. The same pattern appears in HR and payroll, or in customer data and bulk export workflows. The risk is not the existence of each permission on its own, but the lack of correlated visibility across the systems that jointly enable the outcome.
Practical implication: Correlate entitlements across connected systems before reviewers certify them.
Why NHI and automation expand the SoD boundary
Service accounts, API integrations, bots, and AI agents now participate in the same workflows as human users. That means SoD is no longer only about employee duties, because non-human identities can carry persistent, cross-system access that alters the business process just as much as a person can. If governance tools only model human users, they miss the identities that move data, trigger approvals, and keep the transaction chain running. Modern access governance has to treat these identities as part of the control surface.
Practical implication: Include service accounts, integrations, bots, and AI agents in the SoD scope and ownership model.
Threat narrative
Attacker objective: The objective is to control a sensitive transaction end to end while appearing compliant inside each individual system.
- Entry occurs when an identity receives legitimate access in more than one connected business system, often through normal provisioning or integration setup.
- Escalation happens when individually approved entitlements combine across systems to create a toxic path through vendor setup, approval, and payment release.
- Impact follows when the combined access enables fraud, audit failure, or concealment of activity across the full business process.
Breaches seen in the wild
- Zacks breach claim 2025: A hacker leaked 12 million Zacks accounts in 2025, claiming domain admin access in 2024; HIBP verified the data, Zacks has not confirmed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Cross-application SoD is a process-governance problem, not an application-governance problem: The dangerous condition is not excessive access inside one system, but a lawful combination of permissions spread across the systems that execute one business process. That means audit readiness depends on correlated visibility across the transaction path, not a checklist of system-level approvals. Practitioners need to judge entitlement risk in the workflow, not the application silo.
Phantom compliance is the core failure mode: A user can pass every individual access review and still retain a toxic combination that no single owner can see. The program looks healthy at the control-point level while the process itself remains exposed. That gap is why periodic certifications alone are not enough when entitlements move across ERP, SaaS, cloud, and API boundaries.
Cross-application SoD should be treated as identity governance across mixed actor types: Human users, service accounts, integrations, bots, and AI agents can all participate in the same conflicting process. If the governance model excludes non-human identities, it is only governing part of the risk. The practical conclusion is that ownership and review must span every identity that can touch the transaction.
Business-process-centric control design is now the baseline for modern IAM: Traditional role models still matter, but they no longer define the full control perimeter. Cross-application entitlement context, continuous analysis, and remediation workflows are now required to keep SoD aligned to how work actually happens. Teams should expect SoD to be judged by process coverage, not by application coverage.
Identity blast radius is the right lens for cross-application SoD: When one identity can influence multiple steps in a transaction, the governance concern is how far that identity can move before a control notices. That blast radius is widened by connected applications, delegated workflows, and machine identities that persist across systems. Practitioners should measure SoD by how much of the transaction an identity can touch, not by how many roles it holds.
From our research library:
- Over 70% of organisations lack automated access risk analysis, user access reviews and provisioning and deprovisioning, according to Pathlock's 2025 Digital Transformation and Access Risk Report.
What this signals
Cross-application SoD pushes IAM teams toward process-centric governance: The operational shift is from certifying isolated entitlements to evaluating how access behaves across a transaction chain. That matters because the control failure no longer sits inside one application, it emerges where workflows cross systems and ownership boundaries.
Entitlement visibility becomes more important than role naming: Once finance, HR, procurement, and automation are linked, the decisive question is what an identity can actually do across the workflow. Teams that cannot see those combined paths will keep approving access that looks safe in each system but unsafe in context.
For practitioners
- Map the full business process Identify the systems, roles, integrations, and approvals that make up one sensitive workflow before writing SoD rules.
- Correlate entitlements across systems Review vendor creation, payment approval, employee record changes, payroll access, and similar combined permissions as one access pattern.
- Bring non-human identities into scope Include service accounts, API integrations, bots, and AI agents in ownership, review, and remediation workflows.
- Tie violations to remediation owners Route each cross-application SoD violation to a named owner with the systems involved, the conflicting entitlements, and the business process affected.
- Evaluate continuously, not only at certification time Recheck access when roles change, integrations expand, or new workflows are introduced so the SoD model does not drift away from operations.
Key takeaways
- Cross-application SoD exposes a governance gap that single-system controls cannot close.
- The main risk is a toxic combination of permissions that only appears when access is evaluated across the full business process.
- Teams need process-level visibility, continuous review, and inclusion of non-human identities to keep SoD effective.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while CSA Cloud Controls Matrix, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cross-application SoD depends on cloud identity governance across connected systems and identities. |
| Recommendation — Map cross-system entitlement risk to IAM and enforce one governance view across cloud and SaaS workflows. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on entitlement visibility and authorization across connected business processes. |
| Recommendation — Apply PR.AA-05 to evaluate combined permissions across systems, not just inside each application. | ||
| CIS Controls v8 | CIS-5 — Account Management | Cross-application SoD relies on account ownership, provisioning, and deprovisioning discipline. |
| Recommendation — Use CIS-5 to keep account ownership, provisioning, and retirement aligned across all participating systems. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Cross-system identity abuse often manifests as movement across platforms after valid access is obtained. |
| Recommendation — Map cross-application abuse paths to TA0006 and TA0008 to detect how valid access moves between systems. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | APIs and integrations can create cross-process authorization paths that bypass single-application controls. |
| Recommendation — Audit API authorization paths for cross-application actions that let one identity complete an entire transaction. | ||
Key terms
- Cross-System Separation Of Duties: A governance control that prevents one identity from holding conflicting permissions across different systems. It only works when accounts are correlated back to a single person or owner, because fragmented identity records can hide toxic access combinations that would be obvious in one platform.
- Phantom compliance: A false sense of control where each individual system review passes, but no one has validated the full end-to-end access pattern. It is a common failure mode in distributed environments because the audit trail proves isolated checks, not transactional safety.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Business-process-centric governance: An access governance approach that follows how work actually moves across applications, integrations, and approvals. It treats the process as the control boundary, which is essential when a single business outcome depends on multiple systems and multiple identity types.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 24, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org