Use the systems that drive your highest-risk access decisions as the test case. If SAP or Oracle carry the majority of segregation-of-duties exposure, ERP-depth may be justified. If your exposure is mostly SaaS sprawl, then broad discovery and low-friction policy updates usually matter more than deep entitlement customisation.
Why This Matters for Security Teams
Deciding whether ERP-depth segregation of duties is worth the complexity is really a question about where the highest-risk access decisions live. If SAP or Oracle is the system of record for financial posting, vendor creation, payment release, or audit-sensitive approvals, the control value of deeper entitlement modeling can be high. If the real exposure is spread across SaaS tools, service accounts, and API-driven workflows, teams often get more benefit from broad discovery, faster reviews, and cleaner policy updates than from highly customized ERP rules.
This tradeoff matters because many identity failures are not caused by a lack of policy intent, but by poor visibility into who or what can actually act. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which is why deep control design often starts from incomplete evidence. That gap can make ERP-specific SoD feel precise while still missing the larger risk surface. The control question should be framed against business materiality, not tooling preference, and mapped to guidance such as the NIST Cybersecurity Framework 2.0.
In practice, many security teams discover SoD gaps only after an access review, audit finding, or fraud investigation has already exposed the real process weakness.
How It Works in Practice
The practical decision starts with process mapping. Identify which transactions create the most loss, compliance, or fraud exposure, then trace the identities and entitlements that can trigger those transactions. ERP-depth SoD is most defensible when the system supports tightly coupled financial and operational controls, and when those controls must be enforced inside the application rather than by surrounding workflow steps.
A useful implementation pattern is to separate the decision into three layers:
Risk concentration: determine whether a small set of ERP functions drives most of the material exposure.
Control feasibility: assess whether SoD rules can be modeled cleanly without creating unmanageable exception sprawl.
Operational cost: estimate the review, remediation, and role-maintenance workload created by deeper entitlements.
Where ERP-depth is justified, teams usually need tighter role engineering, periodic toxic-access analysis, and explicit exception governance. Where it is not justified, current guidance suggests prioritizing discovery, entitlement normalization, and lightweight policy enforcement across the broader identity estate. That approach aligns with the reality that NHI and service-account risks often sit outside the ERP core, including the kinds of exposure highlighted in the Ultimate Guide to NHIs and incident-driven research such as JetBrains GitHub plugin token exposure.
Teams should also check whether SoD controls are being used to compensate for weak privileged access management, because that can turn a policy design problem into a perpetual role-maintenance problem. These controls tend to break down when ERP roles are reused across too many business units because exception handling becomes the real access model.
Common Variations and Edge Cases
Tighter ERP SoD often increases review burden and role-maintenance cost, so organisations have to balance stronger transaction control against the speed of change. That tradeoff is especially visible in mixed estates where one ERP instance is heavily regulated while the rest of the environment is dominated by SaaS, scripts, and integration accounts.
There is no universal standard for this yet, but current guidance suggests a few common edge cases. First, if the ERP is heavily outsourced or maintained by a third party, the SoD design must include supplier access, break-glass accounts, and offboarding paths. Second, if business units operate differently across regions, a single global role model may create more exceptions than it removes. Third, if the primary risk comes from non-human identities rather than end-user roles, ERP-depth may deliver less value than stronger secrets governance, lifecycle control, and access telemetry.
The best decision rule is to pursue ERP-depth when the ERP is the control plane for high-impact financial action and the role model can be maintained with disciplined ownership. Otherwise, broader visibility and simpler policy enforcement usually produce better risk reduction per hour of analyst effort.
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 |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and access governance inform where deeper SoD is justified. |
| OWASP Non-Human Identity Top 10 | NHI-03 | SoD complexity often rises when NHI entitlements and service accounts are poorly governed. |
| NIST AI RMF | Risk framing helps decide whether deeper ERP controls are worth the operational burden. |
Inventory NHI privileges tied to ERP workflows and remove standing access that creates toxic combinations.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
