Cross-application SoD exposes a governance gap in modern IAM

At a glance

What this is: This is an analysis of why application-level SoD no longer captures cross-system access risk and how modern business processes create toxic combinations across connected systems.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes increasingly govern identities whose risk only appears when permissions are evaluated across applications, integrations, and workflows together.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Saviynt's analysis of cross-application separation of duties and access risk

Context

Cross-application separation of duties is the practice of checking whether one identity can create risk by combining permissions across multiple systems in the same business process. Traditional SoD programmes were built for a single application boundary, but finance, procurement, HR, SaaS, cloud, APIs, automation, and AI-driven workflows now span several control points. That shift creates a governance gap that application-by-application review cannot see, especially when the same identity appears compliant inside each system but unsafe in aggregate.

For IAM and IGA teams, the issue is not whether SoD still matters. It is whether the control model follows the full transaction path, including human users, service accounts, API integrations, and AI agents where they participate in the process. The first-order problem is visibility across connected entitlements, because risk emerges at the seams between systems, not inside any one platform alone.

Key questions

Q: How should security teams implement cross-application SoD in modern enterprise workflows?

A: Start by mapping the full business process, then define SoD rules around the combined permissions needed to execute it. Correlate entitlements across ERP, SaaS, cloud, APIs, and non-human identities, and route violations into the access review workflow where owners can act on them.

Q: Why do application-level access reviews miss SoD risk in connected systems?

A: Because they only validate what is visible inside one platform. A user can be compliant in each system separately and still hold a toxic combination across the process, which is why cross-system correlation is required to prove the transaction is actually safe.

Q: What do security teams get wrong about SoD when service accounts and automation are involved?

A: They often scope SoD to human users and leave non-human identities outside the model. That creates blind spots, because service accounts, integrations, and AI-driven workflows can move data or trigger approvals across systems with the same business impact as a person.

Q: Who is accountable when cross-application SoD violations are discovered?

A: Accountability should sit with the business owner of the process, supported by the application and identity teams that can explain the entitlement chain. If no one owns the end-to-end workflow, no one can confidently prove that segregation of duties is operating as intended.

Technical breakdown

Why single-application SoD misses cross-system toxic combinations

Single-application SoD only evaluates the permissions visible inside one platform. That works when the highest-risk action lives in a single ERP, but it breaks once a process is split across SAP, Coupa, Salesforce, Workday, cloud services, and APIs. A user can hold one harmless entitlement in each system and still create a toxic combination across the full process, such as vendor maintenance on one platform and payment approval on another. The technical failure is not weak rule logic. It is incomplete observation across the business process.

Practical implication: map SoD rules to end-to-end workflows, not isolated application roles.

How non-human identities change the SoD problem

Service accounts, API integrations, bots, and AI agents can participate in the same transaction chain as human users, but they often sit outside the ownership and review discipline applied to employee access. That matters because these identities can hold persistent, cross-system privilege that moves data or triggers actions between applications without the same certification visibility. In practice, this turns NHI governance into a SoD dependency, because the risky combination may be distributed across human and non-human actors rather than concentrated in one user account.

Practical implication: include NHI ownership, purpose, and retirement controls in every cross-application SoD review.

Why certification alone cannot prove the process is safe

Access certification is point-in-time, while cross-application SoD risk is dynamic. New integrations, emergency access, role changes, reorganisations, and added workflows can create a toxic combination after the last review closed. If reviewers only see partial entitlement context, they certify what each application knows, not what the business process actually enables. That is why continuous analysis across connected systems matters more than a quarterly attestation when access risk is distributed across multiple control points.

Practical implication: pair certification with continuous entitlement correlation and remediation routing.

Threat narrative

Attacker objective: The objective is to exploit legitimate access combinations across systems to move money, alter records, or conceal activity without triggering single-application controls.

1. Entry occurs when a user, service account, or integration receives valid access in two or more connected systems that individually appear permissible. Escalation begins when those permissions combine across the business process to create a toxic path, such as create in one platform and approve in another. Impact follows when the combined access enables fraud, audit failure, or concealed misuse that single-system controls never flagged.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cross-application SoD exposes an application-boundary illusion: many governance programmes still assume that if each system is compliant, the business process is compliant. That assumption fails when access is distributed across ERP, SaaS, cloud, API, and automation layers, because the toxic combination only appears in aggregate. The practical conclusion is that SoD must be evaluated as a process control, not a system control.

Non-human identities are now part of the SoD control plane: service accounts, integrations, bots, and AI agents can create or move risk across systems even when no human user looks over-privileged. That changes the governance question from who approved the access in one system to which identities can jointly execute the transaction end to end. Practitioners need to treat NHI visibility as a prerequisite for reliable SoD analysis.

Phantom compliance is the hidden failure mode: organisations can pass every individual access review and still hold a dangerous combination across systems. This is why periodic certification alone does not establish control effectiveness in modern environments. The practitioner conclusion is that review evidence must be paired with cross-system entitlement correlation before leadership treats SoD as operating effectively.

Identity blast radius: the real risk is not just excessive privilege, but the breadth of outcomes one identity can influence once its access is combined across processes. That concept spans human IAM, NHI governance, and workflow automation, which is why access governance teams need one model for all three actor types. The implication is a shift from application-centric entitlement management to business-process-centric risk containment.

Cross-application SoD is becoming a governance test for the wider identity stack: if IAM, IGA, PAM, and NHI programmes cannot correlate access across systems, they cannot prove segregation of duties in a modern enterprise. This is where governance, not just tooling, becomes decisive. Practitioners should expect audit questions to move from application evidence to process evidence.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to 2024 ESG Report: Managing Non-Human Identities.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, including 46% confirmed and 26% suspected.
• See Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the governance controls that close the ownership and retirement gap.

What this signals

Identity blast radius: cross-application SoD shows that governance failures now emerge from the combination of entitlements, not from any one role or system. If your access model cannot explain the end-to-end transaction path, your control evidence will always lag the way work actually happens.

With 72% of organisations already experiencing or suspecting an NHI breach, per our 2024 ESG Report: Managing Non-Human Identities, the challenge is no longer whether non-human actors matter but whether your governance model can see them inside shared business processes.

Teams should expect audit and fraud questions to shift toward process evidence, not just system evidence. The practical next step is to align regulatory and audit perspectives with entitlement correlation so certification output reflects real control coverage.

For practitioners

• Map critical business processes end to end Start with finance, procurement, HR, payroll, and vendor management, then document every system, integration, and approval step that can influence the transaction. Include cloud services, APIs, service accounts, bots, and AI agents where they participate in the path.
• Correlate entitlements across connected applications Build SoD rules around the combined access pattern, not around one application at a time. Review whether a single identity can create, modify, approve, or conceal a transaction across multiple systems even when each individual entitlement looks reasonable.
• Bring non-human identities into certification workflows Assign ownership for service accounts, integrations, bots, and AI agents, then make their access reviewable inside the same certification process used for employee access. Include purpose, business process mapping, and retirement criteria so reviewers can see how the identity changes the control picture.
• Convert SoD findings into remediation decisions Route violations to named owners with full process context, including the systems involved, the conflicting entitlements, and the business risk created. Use the finding to remove access, document an exception with compensating controls, or redesign responsibility splits where the process requires it.

Key takeaways

• Cross-application SoD fails when organisations treat each application as a complete control boundary instead of evaluating the full business process.
• Non-human identities are now part of the SoD problem because service accounts, integrations, bots, and AI agents can create toxic access combinations across systems.
• Continuous cross-system entitlement correlation is what turns SoD from point-in-time compliance evidence into a control that can actually reduce fraud and audit risk.

Key terms

• Cross-App Segregation Of Duties: A SoD approach that evaluates whether a single identity can perform conflicting actions across multiple systems, not just within one application. It is essential in SaaS and cloud environments where business processes span tools and where conflicts often emerge only when permissions are considered together.
• Toxic Access Combination: A toxic access combination is a set of permissions that becomes dangerous when granted together, even if each entitlement looks acceptable on its own. In identity governance, these combinations matter because they can enable misuse, separation-of-duties failures, or broader compromise.
• 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.
• 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.

What's in the full article

Saviynt's full blog post covers the operational detail this post intentionally leaves for the source:

• How to map cross-application SoD rules across SAP, Oracle, Workday, Salesforce, and connected workflow systems.
• Examples of toxic access combinations that combine vendor maintenance, payment approval, employee records, and payroll actions.
• How to route SoD findings into certifications, remediation workflows, and audit-ready evidence packs.
• Why service accounts, APIs, bots, and AI agents need to sit inside the same governance model as employee access.

👉 The full Saviynt post covers cross-system SoD examples, governance gaps, and remediation guidance.

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.