These issues persist when access is granted for convenience, then left in place as roles, projects, and staff changes accumulate. In ERP systems, that creates hidden overlaps between request approval, payment, posting, and administration duties. Without periodic recertification and policy enforcement, organisations lose control over who can do what and why.
Why This Matters for Security Teams
ERP segregation of duties failures are rarely just policy problems. They are usually the result of access drift, role sprawl, and exceptions that never expire. Once approval, posting, vendor maintenance, and payment functions start overlapping, the control gap can enable fraud, concealment, or accidental self-approval. That is why guidance such as the NIST SP 800-53 Rev 5 Security and Privacy Controls treats access enforcement and review as ongoing controls rather than one-time setup.
NHI Management Group sees the same pattern in identity programs more broadly: only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges in the current research set published in the Ultimate Guide to NHIs. The ERP lesson is similar. If access reviewers cannot clearly see how a role maps to a business duty, the review becomes a rubber stamp instead of a control. In practice, many security teams discover SoD conflicts only after an audit finding or a payment incident, rather than through deliberate design.
How It Works in Practice
Effective ERP access review starts with a duty matrix, not a role list. Each sensitive business process should be decomposed into conflicting functions such as create supplier, approve supplier, enter invoice, release payment, post journal, and modify master data. Those functions are then mapped to ERP roles and technical entitlements. Current guidance suggests using policy-based review rules so that a reviewer is prompted by actual toxic combinations, not just by job title.
Operationally, the strongest programs combine recertification with preventive controls. That means:
- defining SoD rules at the process level and linking them to ERP roles
- flagging compensating controls where a conflict cannot be removed immediately
- requiring time-bound exception approval with an explicit owner
- removing inherited access when staff move teams, vendors change, or projects end
- tracking privileged and emergency access separately from standard business roles
This is consistent with broader identity hygiene principles in the NHI Lifecycle Management Guide, where permissions should expire when the business purpose ends. For ERP, that often means access reviewers need transaction evidence, role definitions, and approval path context, not just an exported entitlement list. It also helps to align review logic with OWASP Non-Human Identity Top 10 principles when service accounts or automation bots interact with ERP workflows, because machine access can silently widen the blast radius. These controls tend to break down in heavily customised ERP landscapes because bespoke roles, cross-functional super-user access, and manual overrides make toxic combinations hard to detect consistently.
Common Variations and Edge Cases
Tighter SoD enforcement often increases business friction, requiring organisations to balance fraud prevention against operational speed. That tradeoff becomes most visible in small finance teams, shared-service centres, and month-end close, where the same user may legitimately need multiple privileges to keep the business running.
There is no universal standard for handling every exception yet, but current guidance suggests three common approaches: compensate with stronger logging and second-person review, time-box the exception with a named approver, or redesign the process so the conflict disappears. Temporary access should be especially short-lived for contractors, break-glass users, and administrators. The Ultimate Guide to NHIs — Key Challenges and Risks highlights how excessive privilege accumulates when access is granted for convenience and never revisited, which is exactly how ERP conflicts persist.
Edge cases also arise when automated posting, reconciliation, or integration accounts operate inside ERP. Those accounts may not fit human SoD models cleanly, so the review should focus on what the account can do, what system triggered it, and whether a human approval step still exists. Where automation is involved, access governance should distinguish routine service execution from administrative control, because the risk profile changes sharply when an account can both initiate and approve the same transaction path.
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, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Excessive privileges and weak rotation are core NHI governance failures. |
| NIST CSF 2.0 | PR.AC-4 | SoD conflicts are access enforcement issues that map to least privilege. |
| NIST AI RMF | AI RMF governance supports accountable access decisions and exception handling. | |
| NIST Zero Trust (SP 800-207) | AC-6 | Zero Trust least privilege is directly relevant to preventing toxic ERP privilege combinations. |
Use role reviews and approval workflows to prevent one identity from controlling a full sensitive transaction path.
Related resources from NHI Mgmt Group
- How should enterprises automate segregation of duties reviews across SAP and connected business applications?
- What do security teams get wrong about access reviews in hybrid ERP and cloud environments?
- Who is accountable for segregation of duties governance when access controls span SAP and non-SAP systems?
- How should security teams extend segregation of duties controls across cloud procurement apps and ERP environments?
