A common mistake is treating ERP controls as sufficient when business processes now span multiple applications and identities. That leaves cross application conflicts, entitlement drift, and lifecycle gaps outside review. Effective SoD management must look across the full application ecosystem and include role changes, not just initial provisioning or financial workflows.
Why This Matters for Security Teams
ERP-layer controls matter, but they rarely represent the full access surface. Modern enterprises move data and decisions across HR systems, procurement tools, data platforms, automation services, and API-driven workflows, so a SoD review that stops at the ERP misses cross-application entitlement drift and toxic combinations outside finance. That gap is especially dangerous when non-human identities are involved, because service accounts and tokens often outlive the business role that created them. NHIMG notes that 97% of NHIs carry excessive privileges in many environments, which is exactly the kind of latent risk ERP-only reviews tend to overlook.
Security teams also get trapped by the assumption that provisioning is the control. In practice, role changes, delegated admin, integrations, and emergency access create a moving target that a quarterly ERP review cannot reliably capture. NHI Mgmt Group’s Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 both reflect the same operational reality: access risk is distributed, not confined to one ERP control plane. In practice, many security teams discover SoD failures only after an integration, report feed, or service account has already bridged systems that were never reviewed together.
How It Works in Practice
Effective access risk management starts by mapping business-critical duties across the entire application ecosystem, not by asking whether the ERP role matrix is clean. The core question is whether a user, service account, API key, or automation can combine permissions across systems to complete a restricted action. That requires joining identity data from ERP, IAM, PAM, SaaS platforms, and workflow tools, then evaluating conflicts at the business-process level rather than the application level.
Practically, teams should define SoD rules around end-to-end transaction paths. For example, one identity may create a vendor in ERP, approve a purchase in procurement, and trigger payment via an integration platform. A clean ERP role review does not catch that conflict unless the other systems are included. Current guidance also suggests tracking role changes continuously, because entitlement drift often happens after initial provisioning and during exception handling.
- Correlate human and non-human identities to the processes they can influence.
- Review privileged integrations, scheduled jobs, and API-driven approvals as part of SoD.
- Reassess access after transfers, automation changes, mergers, and control exceptions.
- Use lifecycle controls from Ultimate Guide to NHIs alongside policy baselines in NIST SP 800-53 Rev 5 Security and Privacy Controls.
NIST CSF 2.0 is also useful as a governance wrapper because it forces organisations to treat identity risk as an enterprise capability, not a finance-system checkbox. Where this guidance breaks down is in highly federated environments with weak app inventory, because conflict analysis becomes incomplete when the organisation cannot reliably see every account, token, and integration that can execute a business action.
Common Variations and Edge Cases
Tighter SoD controls often increase review effort and exception handling, requiring organisations to balance stronger conflict detection against business agility. That tradeoff is real, especially when legacy ERP roles were never designed for today’s API-first architecture. Best practice is evolving, but there is no universal standard for how to express cross-application SoD rules across SaaS, cloud services, and automation platforms.
One common edge case is delegated administration. A help desk role may look harmless in ERP, yet still reset credentials, reassign ownership, or modify entitlements in connected systems. Another is machine-to-machine access, where an NHI can silently bypass human approval paths and keep working long after a business role change. The NHIMG Key Challenges and Risks section and the Top 10 NHI Issues highlight why lifecycle gaps and over-privilege often persist outside standard ERP review cycles.
For organisations with shared service centres, outsourced operations, or heavy automation, the right answer is usually not more ERP rigor alone. It is broader access governance that combines business-process SoD, identity lifecycle controls, and periodic revalidation across all systems that can affect money, data, or approvals.
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 SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Cross-app identity sprawl is the core risk when ERP is treated as the only control plane. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access reviews must cover connected systems, not just ERP roles. |
| NIST SP 800-63 | Identity proofing and lifecycle assurance matter when users change roles across systems. | |
| NIST Zero Trust (SP 800-207) | PA-6 | Cross-system SoD needs continuous verification, not trust in a single ERP boundary. |
| NIST AI RMF | Risk governance must account for dynamic access paths and changing system interactions. |
Evaluate each access request in context rather than assuming ERP controls are sufficient.
Related resources from NHI Mgmt Group
- What do security teams get wrong about role design and access governance in ERP cloud projects?
- What do organisations get wrong about protecting personal data inside ERP systems?
- What do organisations get wrong about IT risk assessments for access control?
- What do organisations get wrong about managing privileged access in DaaS?
