Conflicts migrate into the surrounding applications where approvals, reporting, and remediation actions happen outside the ERP boundary. Users can still assemble incompatible capabilities across connected systems, which leaves the control technically present but operationally incomplete. The result is hidden risk and weak assurance.
Why This Matters for Security Teams
segregation of duties only inside the ERP gives a false sense of control when the real business process spans workflow tools, ticketing platforms, reporting layers, and admin consoles. The conflict may never appear in the core ledger, yet the same person can still initiate, approve, reconcile, and remediate across adjacent systems. That is why identity governance has to follow the process, not just the application boundary, as reflected in the NIST Cybersecurity Framework 2.0.
NHI Management Group has also documented how weak visibility into service accounts and secrets compounds this problem: only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges. When SoD is enforced narrowly, those privileged non-human paths become the easiest place for control bypass. In practice, many security teams discover the conflict only after an audit finding, a fraud review, or an incident has already exposed the gap.
How It Works in Practice
Effective SoD design starts with the end-to-end business process. Map every step where a person or system can create, approve, modify, post, reverse, or certify a transaction, then identify where those actions occur outside the ERP. In many environments, the conflict is assembled across an ITSM approval, an integration service, a reporting export, and a downstream correction job. The ERP may be clean, but the operating model is not.
The practical control objective is to prevent one identity from holding a conflicting combination of capabilities anywhere in the chain. That usually means extending role analysis to connected applications, API tokens, service accounts, and automation identities. The NHI lifecycle has to be governed alongside human access, because secrets and privileged service accounts are often what bridge the gap between systems. NHI Management Group’s Ultimate Guide to Non-Human Identities is useful here because it frames governance as lifecycle control, not just credential storage.
- Inventory all approval, posting, exception, and remediation paths outside the ERP.
- Classify human and non-human identities that can trigger or complete those steps.
- Apply SoD rules across the workflow, not just within the core finance or procurement app.
- Review privileged integrations for compensating controls, logging, and independent approval.
- Re-test after every new connector, automation, or process redesign.
Where cross-system access is unavoidable, best practice is evolving toward policy-based approvals, explicit compensating controls, and stronger monitoring of break-glass activity. NHI Mgmt Group’s research on the ASP.NET machine keys RCE attack illustrates how a credential or trust flaw in an adjacent component can turn into system-wide impact. These controls tend to break down when business teams own adjacent tools independently and no one has a complete map of cross-application authority.
Common Variations and Edge Cases
Tighter SoD often increases process friction, requiring organisations to balance fraud prevention against operational speed. That tradeoff is especially visible in shared-services environments, emergency remediation, and month-end close, where teams want rapid recovery without losing control integrity. Current guidance suggests these exceptions should be time-bound, logged, and independently reviewed rather than treated as standing access.
There is also no universal standard for how far SoD must extend into adjacent platforms. Some organisations can enforce it through centralized IAM and workflow orchestration, while others need compensating controls because legacy ERP integrations cannot express fine-grained policy. The key is to avoid calling a control effective when the real conflict has merely moved into reporting tools, middleware, or privileged support functions. In practice, the weakest point is often the service account used by automation, not the named employee who appears in the audit trail.
For broader governance context, NHI Mgmt Group research shows how quickly hidden privilege accumulates when secrets and service accounts are left outside lifecycle oversight. That makes cross-system SoD reviews a recurring control, not a one-time design exercise.
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 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | SoD depends on controlling access rights across connected systems. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Hidden service accounts and secrets often carry the cross-system privilege that breaks ERP-only SoD. |
| CSA MAESTRO | GOV-01 | Governance must cover workflows and identities beyond a single core platform. |
Map conflicting duties across all applications and revoke any cross-system access that bypasses least privilege.
