Teams often treat SoD as an audit-time checklist instead of an operational control. In practice, the dangerous combination is when conflicting privileges are allowed to exist even briefly. The better question is whether the request process blocks incompatible access before it is granted.
Why This Matters for Security Teams
segregation of duties in ERP is meant to prevent one identity from initiating, approving, and completing the same financially sensitive action. The common mistake is treating SoD as an annual review artifact instead of a live access decision. When access is granted first and reviewed later, ERP controls become reactive, especially in environments where service accounts, integrations, and shared roles quietly accumulate privilege.
This matters because SoD failures rarely look like a single obvious breach. They appear as overlapping role assignments, emergency access that never expires, or workflow exceptions that are never revalidated. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which is a strong signal that excessive access is not an edge case but a recurring operational pattern in modern estates, as reflected in the Ultimate Guide to NHIs. The control objective is not just separation on paper, but preventing incompatible powers from coexisting in the same identity path.
Practitioners often miss that ERP SoD must account for human users, delegated admins, bots, and integrations together, not as separate governance silos. In practice, many security teams encounter SoD conflicts only after an audit finding or fraud review, rather than through intentional pre-grant control design.
How It Works in Practice
Operationally, ERP SoD should be enforced at the request, approval, and provisioning stages. That means defining toxic combinations, mapping them to business processes, and blocking access before entitlement activation. A mature model uses role engineering plus rule-based prevention: for example, no user should be able to create a vendor, approve that vendor, and release payment. The same logic applies to NHIs that submit invoices, move journal entries, or call ERP APIs.
Current guidance suggests treating SoD as a policy decision, not just a reporting control. Teams can use NIST Cybersecurity Framework 2.0 to anchor governance, then extend it with workflow controls that check role conflicts before provisioning. The Ultimate Guide to NHIs is a useful reminder that excessive privilege and poor offboarding are common failure points, which is why SoD must include credential lifecycle and not only application entitlements.
- Define prohibited role combinations by business process, not just by job title.
- Check conflicts at request time, before approval or auto-provisioning.
- Apply temporary access with expiry when exception handling is unavoidable.
- Revoke stale entitlements quickly when role changes or projects end.
- Include service accounts, bots, and API integrations in the same SoD model.
For control design, this usually means combining ERP native SoD rules, IAM approvals, and periodic attestation so the system rejects incompatible access paths rather than documenting them after the fact. These controls tend to break down when custom integrations bypass standard provisioning flows because the conflict logic is never evaluated at the point of use.
Common Variations and Edge Cases
Tighter SoD enforcement often increases request friction, so organisations must balance fraud prevention against operational speed. That tradeoff becomes visible in finance close periods, M&A activity, and emergency break-glass scenarios where business owners want rapid access and security wants hard separation.
There is no universal standard for every ERP implementation, because the right SoD model depends on process design, regulatory exposure, and how much work is done by humans versus automations. In some environments, the main issue is role creep across departments; in others, it is a privileged integration account that can trigger multiple downstream actions with no human review. Best practice is evolving toward continuous access checks instead of once-a-quarter recertification.
For teams that rely on automation, the key mistake is assuming bots are exempt from SoD because they are not people. They are not exempt. A bot that creates and approves the same transaction chain is still a control failure, even if the workflow is technically “working.” Stronger patterns include zero standing privilege, short-lived grants, and policy checks tied to each transaction, not just to the identity itself. NHI Mgmt Group’s Ultimate Guide to NHIs remains relevant here because the same privilege excess that affects service accounts also undermines ERP SoD.
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 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | SoD fails when non-human identities keep conflicting ERP privileges. |
| NIST CSF 2.0 | PR.AC-4 | Access control should prevent conflicting privileges before provisioning. |
| NIST AI RMF | GOVERN | Governance must define accountability for automated and exception-based access. |
Document SoD ownership, exception approval, and review cadence as accountable governance.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
