Custom roles create more combinations of access, exceptions, and compensating controls, so static rule sets produce either gaps or false positives. The more tailored the role design, the more important it is to evaluate risk against actual business transactions instead of relying on generic policy templates.
Why This Matters for Security Teams
SoD becomes harder in customised ERP role models because the access design stops looking like a small set of clean job functions and starts resembling a web of exceptions, overlays, and temporary business rules. That makes it difficult to prove that one person, process, or service cannot both request and approve the same transaction path. In practice, this is where static RBAC reviews miss the real risk, especially when teams treat the role catalogue as the control instead of the business activity it enables.
The issue is not unique to ERP, but ERP customisation amplifies it because finance, procurement, warehouse, and master-data flows often share privileges across modules. Current guidance suggests that effective governance depends on transaction-level understanding, continuous monitoring, and policy tied to actual usage, not just names on a role matrix. The NIST Cybersecurity Framework 2.0 reinforces the need for access governance that is measurable and auditable, while the Ultimate Guide to NHIs shows how quickly unmanaged identity sprawl turns into excessive privilege and weak visibility. In practice, many security teams encounter SoD violations only after a fraud review, audit finding, or production incident has already exposed the flawed role model.
How It Works in Practice
In a customised ERP environment, SoD should be evaluated across the full path of a business transaction: who can create, change, approve, post, and reverse, plus which service accounts, integrations, or batch jobs can trigger those steps. That means the control design needs to account for both human and non-human identities, because NHI-driven automations often hold the exact privileges that bypass manual review. The strongest programmes connect RBAC to transaction monitoring, compensating controls, and periodic recertification based on real use, not assumed use.
Practitioners usually start by mapping critical workflows, then identifying toxic combinations across standard roles, custom roles, and emergency access. From there, they decide whether a conflict is prevented, detected, or accepted with compensation. The better pattern is to pair access review with telemetry from ERP logs, PAM, and identity governance so that a role assignment can be validated against actual business activity. This is consistent with NIST Cybersecurity Framework 2.0 principles for controlled access and monitoring, and with the visibility and lifecycle guidance discussed in the Ultimate Guide to NHIs.
- Define SoD at the transaction level, not only at the role-name level.
- Review custom roles, derived roles, and temporary overrides together.
- Include service accounts, API keys, and job schedulers in the same conflict analysis.
- Use compensating controls only when prevention is not feasible, and document the rationale.
- Re-test after each ERP customisation, patch, or process redesign.
These controls tend to break down when custom ERP workflows are built faster than entitlement governance can be updated, because the security model no longer matches the live process design.
Common Variations and Edge Cases
Tighter SoD often increases administrative overhead, requiring organisations to balance control strength against business speed and exception handling. That tradeoff becomes sharper in heavily customised ERP estates where one approval path may support multiple legal entities, regions, or product lines. There is no universal standard for this yet, but current guidance suggests treating high-risk conflicts differently from low-risk overlaps instead of forcing every exception into the same rule.
One common edge case is emergency access. A break-glass role may be justified, but it should be time-bound, heavily logged, and reviewed after use. Another is shared infrastructure accounts, which may be technically necessary but still create SoD exposure if they can post transactions or alter master data. NHI governance becomes relevant here because a scheduled integration or bot can function like a privileged operator, and Ultimate Guide to NHIs makes clear that excessive privilege and weak offboarding are common failure points.
For teams aligning to broader governance, NIST Cybersecurity Framework 2.0 is useful for framing access control as an ongoing operational function rather than a one-time design exercise. The practical rule is simple: the more customised the ERP landscape, the more SoD must be validated against actual business behaviour, because role templates rarely survive real-world exceptions intact.
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 depends on managing access rights against real business need. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Custom ERP roles often include non-human identities with excessive privilege. |
| NIST AI RMF | Customised workflows need accountable, risk-based governance of autonomous actions. |
Inventory service accounts and automation identities, then constrain them to least privilege.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
