Common signs include approved-looking transactions that still produce fraud exposure, conflicting roles spread across multiple applications, and audit evidence that describes access without showing transaction context. If a workflow can be completed end to end by one identity, the SoD model is likely too static.
How to tell SoD has become too static for modern ERP risk
Static SoD usually shows up when controls still look compliant on paper but no longer reflect how work actually moves through integrated ERP, finance, procurement, and workflow systems. The warning sign is not just a broken rule, it is a control design that separates roles while missing the transaction path, exception path, or temporary privilege that makes the risky action possible.
When that happens, the control can still report “no conflict” even though the same person can assemble the full business outcome across multiple applications or approve it through delegated access.
Modern ERP risk is therefore less about whether a role name exists and more about whether the control model can still see end-to-end authority. If the control evidence cannot follow a transaction from initiation through approval, posting, and override, the SoD model is probably lagging the operating model.
What the weak-control pattern looks like in practice
One common sign is approved-looking transactions that still create fraud exposure. In mature ERP environments, the risky path may be split across systems, but the user experience remains seamless enough that the control boundary disappears. A role matrix that only checks individual permissions can miss combinations that become dangerous only when the workflow is assembled.
Another sign is conflicting roles spread across multiple applications, especially when the SoD logic is scoped too narrowly to a single ERP instance. That is a strong indicator that identity governance, finance controls, and application owners are not describing the same business process from the same risk model. The result is usually shadow remediation, where teams add compensating controls instead of fixing the underlying entitlement design.
A third sign is audit evidence that lists access but not transaction context. If reviewers can prove who had a role but cannot show what that role allowed them to do in a live business process, the control is measuring assignment, not risk. That gap is especially visible when temporary access, firefighter use, or emergency elevation is not tied back to the transactions it enabled.
Why end-to-end workflow visibility matters more than role names
The control failure usually comes from treating SoD as a static matrix rather than a dynamic business-process control. In modern ERP, one identity may never hold both “bad” roles at the same time, yet still complete the full chain through a combination of scheduled jobs, delegated approvals, cross-application entitlements, or short-lived elevated access. That is why workflow context matters as much as entitlement context.
This is also where modern control reviews should look beyond the role catalog and test the actual path to completion. The question is whether a user, bot, or service account can make the same business outcome happen without a meaningful second check. If yes, the SoD rule set is likely describing organizational structure rather than operational risk.
That distinction is important because ERP controls often fail by being accurate in the abstract and incomplete in the transaction trail. Strong controls do not merely say access is separate, they show that segregation still exists at the point where value moves, records are posted, or vendor payment risk is created.
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 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Transaction-context evidence and traceability are central to SoD effectiveness. |
| AC-6 — Least Privilege | Static SoD weakens when users can assemble risky outcomes from excessive or overlapping access. | |
| Recommendation — Review audit trails for transaction context, not just access assignment, to expose SoD gaps. Reduce access paths that let one identity complete conflicting business actions. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SoD is an access-control design issue when privileges no longer match business-process risk. |
| Recommendation — Align access rules with current process risk, not just historical role definitions. | ||
| CIS Controls v8 | CIS-5 — Account Management | Role drift and conflicting entitlements are often symptoms of weak account governance. |
| Recommendation — Continuously review accounts and remove overlapping entitlements that bypass SoD. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | ERP automation and non-human accounts can bypass static SoD when privileges are too broad. |
| Recommendation — Constrain non-human accounts so they cannot assemble conflicting ERP actions. | ||
Practitioner Guidance
What to verify: Test the control against a real transaction, not a role catalogue. If the review cannot trace initiation, approval, posting, and override across systems, the SoD model is too coarse for the environment it is meant to govern.
Decision rule: If one identity can still complete the business outcome by combining ordinary access, delegated approvals, or temporary elevation, treat that as a control-design issue first, not just an exception to document.
What good looks like: Mature SoD programs tie entitlement checks to transaction paths, exception handling, and compensating controls, so reviewers can see not only who has access, but whether that access can actually produce the risky outcome.
Practitioner takeaway: Static SoD fails when it is built around roles instead of reachable outcomes; the strongest test is whether a reviewer can reconstruct the real transaction path that creates fraud or misuse exposure.
Related resources from NHI Mgmt Group
- What are the signs that insider risk controls are not keeping up with modern work patterns?
- What are the signs that an organisation’s digital identity controls are not keeping up with modern public service delivery?
- What are the signs that browser security controls are not keeping up with modern phishing tactics?
- What are the signs that money movement controls are not keeping up with fraud risk?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org