Cross-system conflicts remain invisible. A user can be clean inside SAP while still holding directory, HR, contractor, or workflow access that creates the real risk. Manufacturing compliance fails when the control boundary is narrower than the business process boundary, because auditors test the full access path, not just the ERP rule set.
Why One-App SoD Fails at the Business Boundary
Segregation of duties only works when the control boundary matches the real business process. If SoD is enforced only inside SAP, it can miss the conflicting access that lives in directory groups, HR workflows, contractor systems, or approvals outside the ERP. That creates a false sense of compliance because the user appears clean in one system while still being able to initiate, approve, or conceal the same transaction path elsewhere.
This is why auditors and control owners care about end-to-end access paths, not application-local rules alone. A narrow SoD model can satisfy a screen-level or role-level check and still fail at the process level, especially where provisioning, exceptions, and approvals are distributed across several platforms. NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the broader expectation that access enforcement, accountability, and review must be aligned to the system boundary and the business impact boundary.
In practice, teams usually discover the gap after an audit finding or an incident review, not during the original role design exercise.
How It Breaks in Practice
One-app SoD breaks because enterprise access is rarely contained in a single control plane. SAP may prevent a user from holding incompatible ERP roles, but the real workflow may also depend on directory membership, ticketing permissions, HR status, supplier onboarding rights, or a workflow engine that can approve exceptions. If those adjacent systems are outside the SoD model, the control can be bypassed without any violation inside SAP itself.
The common failure pattern is boundary mismatch. The business process may span:
- role assignment in SAP
- identity groups in the directory
- joiner, mover, leaver actions in HR
- contractor or vendor onboarding
- approval routing in workflow tools
When SoD logic is isolated to one application, the organisation can no longer prove that the same person cannot request, approve, and execute a sensitive action across the whole path. That weakens preventive control, detective review, and audit evidence at the same time. It also makes remediation slower, because a clean SAP role review does not tell you whether the conflicting access sits elsewhere.
The issue becomes more severe when exceptions are handled manually. A temporary access grant in one system, a delegated approval in another, or a stale directory group can reintroduce the conflict after the SAP role review has already passed. A one-app model also struggles with inherited entitlements, where a single group membership unlocks multiple downstream privileges that the ERP role catalog never sees. This is the reason control owners often need enterprise-wide entitlement reviews rather than application-local certification alone.
These controls tend to break down when business decisions are split across multiple platforms because the SoD rule engine cannot see the full chain of authority.
Where the Edge Cases Hurt Most
Tighter SoD often increases operational overhead, so organisations have to balance control precision against the cost of modelling the full process. The hardest cases are shared service centres, outsourced operations, emergency access, and exception-heavy environments where a single user may need different privileges in different systems at different times.
There is no universal standard for making every SoD check cross-platform in the same way, but the practical rule is simple: if one person can complete both halves of a conflicting transaction across systems, the control is incomplete. That is especially true where the ERP is only the posting system and the real decision, approval, or creation step happens elsewhere.
Two other edge cases matter. First, federated identity can hide the real owner of access if governance is split between the application team and a central IAM team. Second, role mining can overstate compliance when it only analyses entitlements inside SAP and ignores the surrounding process. In both cases, the organisation may pass internal review while still failing the business control objective.
In practice, the most common mistake is treating SAP role design as proof of SoD compliance when the real evidence should be transaction-path evidence across all participating systems.
Risk and Threat Considerations
The main risk is control leakage across system boundaries. If conflicting access exists outside SAP, a user can still create, approve, or conceal a sensitive action even while the ERP role set appears compliant. That creates compliance exposure, audit failure risk, and in some cases fraud or abuse risk because the control no longer blocks the full transaction path.
Failure mechanism: A narrow SoD rule set checks only one application, while identity, workflow, and provisioning systems continue to grant the missing half of the conflict. Attackers or insiders do not need to defeat SAP controls if they can use adjacent systems to complete the same business action.
Impact: Organisations lose reliable segregation evidence, exceptions become harder to govern, and reviewers may approve access that still enables the prohibited end-to-end outcome. The result is a control that looks effective in review but fails under audit or misuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | SoD depends on enforcing access boundaries across systems, not one app. |
| ID.GV-1 — Organizational Context | SoD scope must match the real business process boundary and accountability. | |
| Recommendation — Review and constrain cross-system access paths that can bypass SAP-local segregation. Define SoD scope around the end-to-end business process, not the ERP screen boundary. | ||
| CIS Controls v8 | 6.3 — Require MFA for Externally-Exposed Applications | Identity controls around adjacent systems affect whether SoD conflicts can be abused. |
| 6.4 — Automated Audit Log Review | Cross-system SoD failures are often visible only in combined access and activity logs. | |
| Recommendation — Harden access to connected systems that participate in approval or execution paths. Correlate logs across SAP, directory, and workflow systems to spot hidden SoD conflicts. | ||
Practitioner Guidance
What to prioritise: Model SoD around the business process first, then map every system that can initiate, approve, modify, or override that process. If SAP is only one step in the chain, treat SAP role review as one input, not the control objective.
What to verify: Confirm that conflict testing includes directory groups, HR-driven provisioning, workflow approvals, and any delegated or emergency access path. A clean SAP certification is not enough unless the same user cannot complete the same conflicting transaction through another route.
Practitioner takeaway: The test is not whether the user is separate inside one application, it is whether the organisation can prove separation across the full business path that actually matters.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
