Because the same identity layer that grants access also decides whether conflicting rights can coexist. In distributed ERP and SaaS estates, role creep, imports, and delegated administration can create toxic combinations that business users never see. SoD therefore depends on identity policy design as much as audit oversight.
Why SoD becomes an identity governance problem in ERP and SaaS
Separation of duties is often described as a business control, but in ERP and SaaS estates it is enforced through identity, role, and entitlement design. When access is federated across modules, tenants, and connectors, SoD is only as strong as the identity model underneath it. The control fails when governance lives in policy documents while effective permissions live in many administrative planes.
That is why SoD risk shows up as identity governance risk rather than just audit risk. A role may look clean in one system and still combine with inherited, delegated, or imported access to create a toxic combination elsewhere. In distributed environments, the question is not whether users can be approved individually, but whether their combined entitlements remain safe across systems and identity governance foundations need to account for that full picture.
ERP and SaaS also change the operating model. Business teams, integrators, and platform admins can all influence access, so SoD is rarely controlled by one team alone. The practical challenge is to align role engineering, provisioning, reviews, and exception handling so that the identity layer can actually prevent conflicting rights from coexisting, rather than simply documenting them after the fact.
Where toxic combinations emerge in distributed ERP and SaaS
The most common failure mode is role creep. Users accumulate access through job changes, temporary fixes, imported entitlements, or vendor-managed administration, and those permissions are rarely re-evaluated as one coherent set. In ERP, that can mean a person can both create and approve transactions; in SaaS, it can mean a user, app, and admin path together create a control bypass.
Another source of risk is delegated administration. SaaS platforms often allow tenant admins, workspace owners, or application admins to grant access locally, while ERP landscapes rely on business roles, technical roles, and connector-driven synchronization. If those administrative planes are not governed together, the SoD rule exists in theory but is easy to bypass in practice. A solid Segregation of Duties (SoD) Guide is useful here because it treats conflicts, mitigations, and access governance as an operational design problem, not a once-a-year audit exercise.
Imports and integrations make this worse because they can flatten nuance. A legacy ERP role model may be mapped into modern SaaS entitlements that do not preserve the original control intent. That is why SoD analysis has to inspect entitlement inheritance, connector behaviour, and role composition, not only the named roles visible to business approvers. When role design is weak, a role mining and role design discipline becomes part of SoD protection, because the structure of the role model determines whether conflicts can be seen and contained.
What good identity governance looks like for SoD
Good SoD governance starts with a conflict model that is explicit enough to test, automate, and audit. That means defining toxic combinations at the entitlement level, not just at the job-title level, and then checking those conflicts across the actual sources of truth that feed ERP and SaaS access. If the review process cannot see imported roles, delegated admin paths, and connector-synced permissions together, it cannot reliably prove SoD.
It also means treating recertification as remediation, not paperwork. Access reviews should surface whether a user’s effective access still respects the conflict matrix, whether exceptions are time-bound, and whether compensating controls are real or just historical approvals. A practical way to strengthen that loop is to use an access reviews and certification process that closes the loop on removal, because SoD depends on access actually being removed when it is no longer defensible.
Identity governance also has to cover lifecycle events. Joiners, movers, and leavers are the points where conflicting rights most often accumulate or persist, especially when roles are copied during promotions or when emergency access is left behind after a project closes. A JML process reduces SoD drift by forcing access changes to follow the person’s current function, not their historical one. In mature environments, that lifecycle discipline is paired with IGA platform capabilities that can test SoD rules, handle exceptions, and keep evidence consistent across systems.
Risk and Threat Considerations
SoD becomes risky when organisations assume that business approval equals control effectiveness. In ERP and SaaS estates, attackers and insiders do not need to break the control if they can exploit the control boundary itself, through overbroad roles, delayed deprovisioning, or privileged administration that sits outside the review process. The result is latent access that still looks legitimate in one system while creating an unauthorized end-to-end workflow in another.
Failure mechanism: Conflicting permissions are created across multiple identity planes, then preserved by role imports, delegated admin, and weak lifecycle cleanup. Because no single system sees the full entitlement chain, toxic combinations survive reviews and become available for misuse or fraud.
Impact: The organisation can lose the preventive value of SoD, increase fraud and error risk, and create audit findings that are hard to remediate quickly. In severe cases, the same identity can initiate, approve, and conceal a transaction path, which turns identity governance gaps into direct business-control exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | SoD conflicts in ERP and SaaS are governed by separation-of-duties controls. |
| AC-6 — Least Privilege | Excessive combined entitlements drive SoD risk across distributed roles. | |
| IA-5 — Authenticator Management | Credential and session governance supports control over access paths that feed SoD exposure. | |
| Recommendation — Define conflicting duties and enforce approval paths that prevent incompatible access from coexisting. Limit each role and entitlement to the minimum access needed for the business task. Manage credentials and related authenticators so access paths can be revoked and reissued cleanly. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SoD in ERP and SaaS depends on access control policy and enforcement across systems. |
| A.5.18 — Access rights | Review and removal of rights is central to controlling toxic entitlement combinations. | |
| Recommendation — Set access-control rules that prevent conflicting privileges from being granted together. Review, adjust, and revoke access rights when role changes create SoD conflicts. | ||
Practitioner Guidance
What to prioritise: Start with the highest-risk business processes, not the largest role catalogue. Procure-to-pay, financial close, vendor master maintenance, and privileged SaaS administration usually reveal the strongest SoD conflicts first, and they also expose whether exceptions are being used as a substitute for design.
What to verify: Confirm that your SoD checks evaluate effective access across ERP roles, SaaS entitlements, delegated admin rights, and connector-synced permissions. If a control only reviews requested access or a single application’s roles, it is not testing the real conflict surface.
What practitioners underestimate: The biggest gap is often not the SoD rule itself, but the drift between rule design and operational reality. If role imports, emergency access, and exception handling are not continuously reconciled, the control becomes an audit artifact rather than a live governance mechanism.
Practitioner takeaway: Treat SoD as a dynamic identity governance control, because in ERP and SaaS the real question is whether the full entitlement chain can ever create an unsafe combination, not whether each individual grant looked reasonable in isolation.