Notifications
Clear all
Topic starter
24/07/2026 4:08 pm
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.
NHIMG editorial — based on content published by Saviynt: Why Traditional SoD Controls Miss Modern Access Risk
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.
Questions worth separating out
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.
Q: Why do application-level access reviews miss SoD risk in connected systems?
A: Because they only validate what is visible inside one platform.
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.
Practitioner guidance
- 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.
- Correlate entitlements across connected applications Build SoD rules around the combined access pattern, not around one application at a time.
- 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.
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.
👉 Read Saviynt's analysis of cross-application separation of duties and access risk →
Cross-application SoD: what it means for IAM and NHI teams?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
24/07/2026 4:14 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Cross-application SoD exposes a governance gap in modern IAM
