Modern ERP architecture often increases integration, automation, and role complexity, which can blur control boundaries and create hidden access paths. When security and compliance are not designed into the implementation, organisations may inherit risks that are hard to see in audits. The practical fix is continuous control design review, not one-time role cleanup after go-live.
Why ERP Modernisation Changes Segregation of Duties
Modern ERP architecture changes segregation of duties because the control no longer sits in one application layer with a small number of predictable roles. Cloud modules, workflow engines, API integrations, robotic automation, and shared service accounts can all create access paths that were not present in older deployments. That makes SoD less about a static permissions matrix and more about understanding how business transactions actually move across systems, approvals, and exceptions.
For security and compliance teams, the difficulty is not only privilege overlap. It is also the way modern ERP platforms distribute one business process across multiple technical controls, vendor-managed services, and delegated administration models. A role review can look clean while the real risk sits in an integration account, an emergency override, or a workflow exception that bypasses the intended approval chain. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces governance, access control, and monitoring as continuous functions rather than one-off implementation tasks. In practice, many organisations discover SoD drift only after a process exception, an audit finding, or an integration change has already exposed the control gap.
How Segregation of Duties Breaks Down in Practice
In an older ERP model, SoD was often governed by a relatively stable set of transaction roles. Modern ERP changes that pattern in several ways. First, automation can execute business steps without a human touching each control point. Second, cross-module processes can move between finance, procurement, HR, identity, and data platforms, so one user may indirectly influence multiple stages of the same transaction. Third, administrative privilege is often split between business configuration, technical integration, and cloud tenancy management, which makes ownership harder to pin down.
That means the real governance problem is not simply “who has access,” but “who can cause a prohibited outcome through a combination of standard roles, exceptions, and machine actions.” A useful SoD model therefore needs to account for:
- human user roles that initiate or approve transactions
- privileged admin roles that alter workflows, masters, or controls
- integration identities and service accounts that move data or trigger events
- emergency access paths that override normal approval
- customisations and extensions that introduce new control points outside the default role catalogue
Once those layers exist, simple role-based review can miss the effective ability to create, approve, post, and reconcile the same business event by different means. That is why modern ERP governance usually needs process mapping, entitlement analysis, and transaction testing together, not one artefact in isolation. External guidance on governance and access control is helpful, but the practical test is whether the organisation can trace a transaction from request to posting and prove that incompatible functions remain separated across every path, including automation and exception handling. Where that traceability cannot be demonstrated, SoD becomes a documentation exercise rather than an operating control.
Where the Edge Cases Usually Hide
Tighter SoD controls often increase implementation and maintenance overhead, so organisations must balance assurance against operational friction. The hardest cases are not the obvious conflicting roles; they are the boundary cases where legitimate business need creates hidden combinations of access.
Common edge cases include temporary elevation for month-end work, delegated approvals during leave cover, vendor support access, and low-code customisations that let business teams add fields, triggers, or approval logic without a full security review. Another common problem is that cloud ERP permissions may be technically separated while the business outcome is still not separated. For example, a user may not hold two named conflicting roles, yet still control the upstream data and the downstream approval path through workflow ownership or master-data rights.
There is no universal consensus on the best SoD operating model for heavily customised ERP estates. Some organisations favour strict preventive controls, while others accept more detective review because the business process is too dynamic for rigid role design alone. The right choice depends on how often the process changes, how much automation is involved, and whether exceptions are rare and well-governed or routine and poorly documented. The key test is whether the control design can survive ordinary change, not just a clean implementation.
Risk and Threat Considerations
Modern ERP SoD weakness creates governance and exposure risk because a control that looks separated on paper can still permit end-to-end transaction abuse through integrations, overrides, or privileged configuration. The material risk is loss of trustworthy accountability, especially where finance, procurement, payroll, or master data changes can be initiated and approved through different paths that are not consistently reviewed.
Failure mechanism: SoD breaks down when role design, automation, and exception handling are treated as separate problems. Attackers or insiders do not need one forbidden role if they can combine standard access, workflow manipulation, shared credentials, or admin changes to achieve the same prohibited outcome.
Impact: Organisations can face unauthorised postings, fraudulent approvals, weak audit evidence, and control reliance that collapses during implementation changes, emergency access, or custom workflow updates.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC — Organizational Context | ERP SoD governance depends on understanding business process ownership. |
| PR.AA — Identity Management, Authentication, and Access Control | SoD weakens when user, admin, and integration access paths overlap. | |
| Recommendation — Map critical ERP transactions to accountable owners and review control boundaries as processes change. Separate incompatible ERP entitlements and verify exceptions do not recreate conflicting access. | ||
| CIS Controls v8 | 6 — Access Control Management | ERP SoD is fundamentally an access-control design and review problem. |
| 5 — Account Management | Shared, emergency, and integration accounts often bypass intended SoD boundaries. | |
| 8 — Audit Log Management | Detective evidence is needed when automation and exceptions obscure SoD violations. | |
| Recommendation — Enforce least privilege and routinely remove conflicting ERP access combinations. Track every ERP account type and validate that privileged accounts cannot perform incompatible duties. Log ERP approvals, overrides, and configuration changes so conflicting activity can be reviewed. | ||
| ISO/IEC 42001:2023 | 6.1 — Actions to Address Risks and Opportunities | ERP automation and workflow design create governance risks that require formal treatment. |
| Recommendation — Treat ERP automation and workflow exceptions as governed risks with assigned owners and review cycles. | ||
Practitioner Guidance
What to prioritise: Review SoD at the transaction level first, not the role catalogue level. If you cannot map a business event from initiation to approval to posting, the control is already incomplete.
What to verify: Confirm that emergency access, integration identities, workflow ownership, and admin configuration rights are all included in the SoD model. A clean user-role report is not enough if a privileged path can still complete the same business action.
Common mistake: Treating post-go-live role cleanup as a one-time compliance fix. Modern ERP environments change continuously, so SoD must be revalidated whenever integrations, workflows, or business exceptions change.
Practitioner takeaway: The durable control is not a list of incompatible job titles; it is evidence that no combination of human, administrative, and automated access can complete the same prohibited transaction without independent oversight.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
