Start by testing whether the platform can detect one toxic combination split across different applications and still surface it as a single violation. If the tool needs manual cross-referencing to spot the conflict, it is not giving you true SoD coverage. Use real ERP, finance, and SaaS examples from your own environment.
Why This Matters for Security Teams
Segregation of duties controls fail when they are designed for a single application, then assumed to hold across ERP, finance, procurement, and SaaS workflows. A toxic combination may be harmless inside one system but dangerous when a user can create a vendor in one app, approve invoices in another, and trigger payment in a third. That is why SoD tooling must evaluate entitlements, workflows, and effective access together, not in isolation.
This is especially important in environments with many non-human identities and integration accounts. NHI Management Group notes that Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges, which makes cross-application SoD conflicts easier to miss when service accounts, API keys, and automation roles are included in business processes. The control objective is not only to find duplicate entitlements, but to detect whether combined access creates an unacceptable ability to initiate, approve, and reconcile the same business event. Current guidance in the NIST Cybersecurity Framework 2.0 supports this kind of risk-based access review, but the exact implementation is still organisation-specific. In practice, many security teams discover cross-application SoD conflicts only after a finance workflow audit or a fraud investigation exposes the overlap.
How It Works in Practice
Effective evaluation starts by normalising identities across systems so the tool can link one person, one role, and one machine identity to all of their effective privileges. That means importing ERP roles, IAM groups, SaaS app permissions, privileged access assignments, and service-account usage into a single SoD model. The platform should then map business functions, not just technical entitlements, so it can recognise that a user who can maintain suppliers in one application and approve journal entries in another has a conflict even if no single app defines it that way.
Practitioners should test the product with real scenarios from the environment:
- One account creates vendors in procurement, another approves payments in finance, and a third reconciles ledgers.
- A delegated admin in SaaS can assign access that bypasses a downstream approval rule.
- A service account or integration bot can submit transactions in one app and trigger approvals through an API in another.
To prove depth, ask whether the tool evaluates toxic combinations at runtime or only after batch reconciliation. Stronger platforms can ingest entitlement graphs, application connectors, and policy rules, then surface a single violation even when the access is split across three systems. This is consistent with the broader NHI governance emphasis in Ultimate Guide to NHIs, which highlights how over-privileged identities multiply risk when visibility is fragmented. Tools should also support evidence trails, since auditors will want to see why the conflict was flagged, which access path created it, and whether compensating controls exist. These controls tend to break down when identity data is stale, connectors cover only part of the application estate, or business role definitions do not match actual transaction paths.
Common Variations and Edge Cases
Tighter SoD coverage often increases integration effort and review workload, so organisations must balance broader conflict detection against connector quality and false-positive noise. There is no universal standard for this yet, especially when teams try to extend SoD into custom workflows, low-code platforms, or agent-driven automation.
One common edge case is indirect access. A user may not hold the conflicting role directly, but can still perform the action through group membership, delegated admin rights, shared service accounts, or a privileged workflow queue. Another is compensating control logic: some organisations allow limited conflicts if approvals are time-bound, independently monitored, and separately logged. That can be acceptable, but current guidance suggests these exceptions should be explicit and reviewable, not buried in policy exceptions.
For cross-application SoD, the key question is whether the product can reason over effective access rather than raw entitlements. If it cannot combine identity, role, privilege, and workflow context across ERP and SaaS systems, it will miss the real risk. In practice, that failure shows up first in audit remediation, then in fraud response, when teams realise the conflict existed all along but was never visible in one place.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, CSA MAESTRO and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Cross-app SoD depends on consistent access review and enforcement. |
| OWASP Non-Human Identity Top 10 | NHI-04 | NHI and service-account privilege can create hidden SoD conflicts. |
| CSA MAESTRO | Agent and workload access graphs help expose cross-system conflict paths. | |
| NIST AI RMF | Risk-based evaluation supports context-aware conflict decisions. | |
| OWASP Agentic AI Top 10 | Autonomous workflows can chain actions across apps and bypass simple SoD checks. |
Inventory non-human identities and test whether automation accounts can complete conflicting business steps.
