Manual reviews miss risk because they focus on static access lists and isolated systems instead of actual transactions and cross application behavior. In environments that span SAP, procurement, and HR platforms, hidden entitlements and inconsistent role design can leave toxic combinations undetected until an audit or incident exposes them.
Why This Matters for Security Teams
Manual segregation of duties reviews often look complete on paper while missing the real issue: risk emerges when one identity can chain access across applications, process steps, and exceptions. That is especially true in SAP, procurement, and HR estates where a user may not hold a single toxic role in any one system, yet still be able to create, approve, receive, and release value across the workflow. Current guidance in the NIST Cybersecurity Framework 2.0 points teams toward governance and continuous risk management, not occasional checkbox review.
NHIMG research on the Ultimate Guide to NHIs shows why this matters: 97% of NHIs carry excessive privileges, and 71% are not rotated within recommended time frames. Even though SoD is often discussed in human-access terms, the same weakness appears when service accounts, integrations, and workflow users are allowed to accumulate privileges that no reviewer sees end to end.
In practice, many security teams encounter SoD failure only after an audit exception, a fraud case, or a cross-system incident has already connected the dots.
How It Works in Practice
Manual SoD review breaks down because it tends to examine role catalogs, not actual transaction paths. A reviewer may confirm that a buyer role and an approver role are separated in one platform, yet miss that an interface account can create the request in one system, a workflow account can approve it in another, and a reporting user can export the results for manipulation elsewhere. The control objective is not simply “different roles,” but preventing one actor or one identity chain from completing a sensitive business outcome.
That is why a practical approach starts with entitlement mining across applications, then maps identities to business actions rather than titles. Teams should identify hidden entitlements, inherited permissions, fallback accounts, batch jobs, and integration users, then correlate them against actual transactions. Top 10 NHI Issues is a useful reminder that excessive privilege and poor visibility are structural problems, not edge cases. For governance, NIST Cybersecurity Framework 2.0 supports a continuous control model, which aligns better with cross-application SoD than annual attestation.
- Review end-to-end business events, not only system-specific roles.
- Model toxic combinations across ERP, procurement, HR, and integration layers.
- Include privileged service accounts, API users, and batch processes in scope.
- Validate access against real transactions, not just access snapshots.
Where this guidance breaks down is in highly customised multi-tenant environments with weak logging, because inconsistent event data makes transaction-level SoD correlation unreliable.
Common Variations and Edge Cases
Tighter SoD controls often increase operational overhead, requiring organisations to balance fraud prevention against workflow speed and exception handling. That tradeoff becomes sharper in environments with shared services, outsourced finance, or global ERP instances where local process variations are unavoidable. Current guidance suggests the answer is not to relax SoD, but to distinguish between approved compensating controls and unmanaged exceptions.
There is no universal standard for this yet, but best practice is evolving toward continuous controls monitoring, exception expiry, and risk scoring by business process. In complex estates, a user may legitimately need access to create and approve different items across different applications, but only if the workflow includes strong compensating checks such as independent review, step-up approval, and tamper-evident logs. The challenge is to make those exceptions visible and time-bound.
For broader identity governance patterns, the Ultimate Guide to NHIs — Why NHI Security Matters Now shows how excessive privileges and poor revocation discipline persist across environments. That same pattern applies to SoD: if revocation, logging, and entitlement cleanup are inconsistent, manual review will always lag behind actual risk.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM | SoD risk is a governance and continuous risk management problem. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Excessive and hidden privileges often sit behind cross-app SoD failures. |
| NIST AI RMF | GOVERN | Cross-application identity risk needs accountable governance and oversight. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Least privilege and continuous verification fit multi-application access paths. |
| CSA MAESTRO | GOV-02 | Agentic workflow control maps to orchestration and policy enforcement across apps. |
Enforce policy across workflow steps so no identity can complete the whole chain unchecked.
Related resources from NHI Mgmt Group
- Why do application-level access reviews miss SoD risk in connected systems?
- How should organisations extend access governance across complex application environments without losing control of compliance risk?
- Why do manual internal controls increase compliance and security risk in regulated environments?
- Why does manual user access provisioning create control risk in cloud and mobile ERP environments?
