Static role models fail because they assume conflicts are visible inside one role or one system, while modern access risk is often assembled across multiple applications and delegated workflows. A user can hold individually acceptable entitlements that still combine into a high-risk transaction path. SoD has to be evaluated as an identity and process problem, not a role-list problem.
Why Static Roles Miss Segregation of Duties Risk
Static role design works only when access paths are stable, visible, and contained inside a single system boundary. ERP environments rarely stay that clean. Users accumulate entitlements through job changes, temporary approvals, delegated administration, and cross-application integrations, so the real risk is often the combination of rights rather than any one role. That is why a role catalog can look compliant while the business process still allows an improper payment, vendor change, or journal entry path. NIST Cybersecurity Framework 2.0 emphasises governance and access control as continuous functions, not one-time assignments, and that matters here because SoD risk is operational, not just structural.
NHIMG research on Top 10 NHI Issues shows how quickly hidden access combinations become governance gaps when identities, secrets, and approvals are not managed as a system. In practice, many security teams discover SoD violations only after a finance close, audit finding, or fraud review has already exposed the path.
How SoD Risk Emerges Across ERP and Connected Workflows
SoD failures usually appear at the process layer. A user may have one role for purchase requests, another for vendor maintenance, and a third through a shared service account or integration path. Individually, each entitlement can appear reasonable. Together, they can enable a complete attack or abuse chain. That is why role mining alone is not enough. The control question is not just “Who has this role?” but “What transaction path becomes possible when multiple permissions, workflows, and exception grants are combined?”
Current guidance suggests evaluating access at runtime across the full business process. That means mapping toxic combinations across modules, delegated tasks, emergency access, and system-to-system identities. It also means treating non-human identities as part of the SoD model, because machine accounts often bridge the very steps that human roles are supposed to separate. The OWASP NHI Top 10 and the NIST Cybersecurity Framework 2.0 both reinforce the need for least privilege, continuous monitoring, and governance over access pathways, not just named roles.
- Model entitlements by transaction path, not by role title.
- Include temporary, delegated, and emergency access in SoD analysis.
- Review non-human identities, service accounts, and APIs alongside user roles.
- Re-evaluate access after process changes, not only during annual recertification.
These controls tend to break down in heavily customised ERP estates with frequent exceptions, because the effective access model lives in workflow logic and integration code rather than in the role matrix.
Where Static Role Models Break Down in Practice
Tighter role control often increases operational overhead, so organisations have to balance cleaner access models against business continuity and close-cycle speed. That tradeoff is real, especially where finance, procurement, and shared services depend on fast approvals and temporary elevation. Best practice is evolving, but there is no universal standard for this yet: some teams pursue risk-based access reviews, while others implement compensating controls such as dual approval, maker-checker checks, and transaction monitoring.
The most important edge case is indirect privilege. A user may never hold both conflicting roles in the same application, yet still gain the same outcome through an integration account, workflow delegation, or a privileged support ticket. That is why NHIMG guidance in the Ultimate Guide to NHIs — Key Challenges and Risks matters for ERP governance: machine-mediated paths often bypass role logic entirely. For teams facing fragmented identity data, the safer approach is to combine SoD policy with process mining, exception tracking, and continuous entitlement review rather than relying on static role certification alone.
Where ERP customisations, third-party connectors, and service accounts are tightly coupled, static roles stop representing real authority and the control model loses predictive value.
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.AC-4 | SoD risk is an access governance problem across changing ERP pathways. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Non-human identities often create the hidden cross-system access SoD misses. |
| NIST AI RMF | Risk management should evaluate identity and process outcomes, not role lists alone. |
Continuously review ERP entitlements and toxic combinations, not just static role assignments.
