ERP modernization exposes access governance gaps in NHI controls

At a glance

What this is: This is a Delinea analysis arguing that ERP modernization exposes access governance gaps when security, compliance, and role design are deferred until late in the implementation.

Why it matters: It matters because ERP programmes that miss early access governance often inherit broad roles, SoD conflicts, and weak privileged access controls into production.

Context

ERP modernization is the point at which access governance often becomes visible, because legacy roles and permissions get copied into a new operating model before teams have validated who should have access to what. When that happens, the implementation inherits old control weaknesses instead of resetting them.

In this article, Delinea argues that security and compliance belong in the blueprint phase of ERP delivery, not after functional testing. The governance problem is not just technical misconfiguration, but the way access design, SoD policy, and privileged access decisions are deferred until the project is already under go-live pressure.

Key questions

Q: What breaks when security teams wait until after go-live to fix ERP access issues?

A: Waiting until after go-live usually means access problems are discovered too late to avoid disruption. Teams may need to redesign security, rerun testing, update mappings, and validate compensating controls. If risks existed during the exposure window, they may also need a lookback to show that fraudulent activity did not occur. That creates delay, cost, and audit complexity.

Q: Why do broad ERP roles create compliance and audit risk?

A: Broad roles increase risk because they concentrate incompatible permissions in a small number of profiles, which can let one identity perform conflicting business actions. That weakens SoD, reduces accountability, and makes audit evidence harder to defend when the role design was never risk-based.

Q: How can teams tell whether ERP access controls are actually working?

A: Measure whether high-privilege accounts are forced through the IdP, whether sensitive actions are logged at a granular level, and whether masking prevents unnecessary data exposure. If investigators cannot reconstruct who viewed, queried, or exported records, the control stack is not delivering usable assurance. Telemetry depth is a governance signal, not just a logging metric.

Q: What should teams do when batch jobs create ERP segregation of duties issues?

A: Treat batch jobs and other non-human identities as governed actors, not technical exceptions. They need the same review discipline as user accounts because automated execution can trigger indirect SoD violations, especially when privileged actions occur outside normal user workflows.

Technical breakdown

Why ERP role design breaks when teams copy legacy access

ERP implementations often begin with standard or lightly modified roles, but that approach preserves old access assumptions rather than re-validating business need. In practice, broad roles can embed Segregation of Duties conflicts, especially when configuration, operations, and monitoring permissions are not separated. The risk increases when project teams treat access as a cleanup task instead of part of the design model. Once roles are inherited from the old system, the new ERP environment starts with hidden privilege accumulation instead of controlled authorisation boundaries.

Practical implication: reassess role structures before migration, not after go-live.

How SoD conflicts survive into go-live

Segregation of Duties is meant to prevent one identity from holding incompatible capabilities across a business process, such as approving, posting, and reconciling the same transaction chain. In ERP programmes, those conflicts often survive because out-of-the-box roles are trusted too much, compensating controls are used as a stopgap, and cross-module testing is incomplete. The result is a control design that looks workable on paper but fails under operational pressure. If those conflicts are not resolved before production, audit findings and rework become part of the implementation itself.

Practical implication: test end-to-end process conflicts before production approval.

What least privilege means in ERP implementation, not theory

Least privilege in ERP is not just a policy statement. It requires role design that limits access to the minimum needed for a job function, with elevated access tightly governed and emergency access monitored. The article also points to non-human identities such as batch jobs as a missed control area, which matters because machine-driven activity can create indirect SoD violations just as easily as human users can. That makes privileged and non-human access part of the same governance conversation, not separate workstreams.

Practical implication: include privileged access and batch jobs in the same governance review.

Threat narrative

Attacker objective: The operational objective is to retain excessive access that enables conflicting business actions, weak oversight, and avoidable audit exposure in the ERP environment.

1. Entry occurs through legacy ERP role migration, where existing access is copied into the new environment before governance is redesigned.
2. Credential and privilege exposure follows when broad roles, super-user access, and unreviewed configuration permissions remain active at go-live.
3. Impact appears as SoD conflicts, audit findings, and expensive remediation once the system is live and business processes are dependent on it.

NHI Mgmt Group analysis

ERP modernization creates an access governance reset point, not a cosmetic upgrade. When organisations treat implementation as a functionality project first and a control-design exercise second, they carry legacy access assumptions into a new system. The problem is not merely that roles are messy; it is that governance decisions arrive after the architecture has already hardened. Practitioners should treat ERP go-live as the moment when access design must be re-earned, not inherited.

Segregation of Duties failures are usually designed in long before they are discovered. Broad roles, copied permissions, and undocumented compensating controls do not create control assurance, they defer failure into production. The article’s central lesson is that the control surface needs to be validated against actual business process flows, not against implementation convenience. Security leaders should push for role design that reflects transaction-level risk, not just organisational charts.

Batch jobs and non-human identities belong in the same ERP governance conversation as human users. The article correctly surfaces NHI exposure as a blind spot because indirect SoD violations often come from automated execution paths, not just employee accounts. That widens ERP governance beyond user provisioning into workload identity, privileged automation, and control ownership. Programmes that ignore NHIs in ERP miss a material part of the access model.

Security is a design decision, not a testing activity. That position matters because UAT can confirm whether a control behaves as intended, but it cannot compensate for a poor access architecture already embedded in the build. The article shows that durable compliance depends on defining the access governance framework, RACM, and security design principles before go-live pressure starts. Practitioners should move control definition upstream, where it can shape the implementation rather than merely inspect it.

Role-based access control only works when role ownership and approval paths are explicit. The article shows that compliant go-live depends on defined ownership, approved role design, tested provisioning, and monitored emergency access. Without those accountabilities, RBAC becomes a label applied to an unmanaged role stack. Teams should align operational ownership with governance ownership before production cutover.

What this signals

Access governance has to move upstream: ERP programmes that wait until testing or go-live to define roles will keep inheriting the same privilege problems they were meant to replace. The governance question is not whether access can be reviewed later, but whether the design still allows meaningful review before the control window closes.

Non-human identities are part of ERP risk architecture: batch jobs, service accounts, and elevated automation can create SoD exposure without a human user ever touching the transaction. That means ERP governance teams need to treat workload identity, privileged access, and business process ownership as one operating model, not separate tracks.

For practitioners

• Define the access governance framework before design freeze Set ownership, approval paths, provisioning rules, and role design principles before the ERP blueprint is locked. This keeps security decisions inside the implementation architecture instead of pushing them into remediation.
• Map SoD risk to the business process flow Build the risk and control matrix around actual transactions, cross-module dependencies, and configuration boundaries so that SoD conflicts are tested where they occur, not where roles are easiest to document.
• Review elevated access and emergency access together Treat privileged roles, firefighter access, configuration rights, and monitoring permissions as one control problem, because separate reviews leave gaps between day-to-day operation and exception handling.
• Validate non-human identities in ERP governance Include batch jobs, service accounts, and other non-human identities in role reviews and SoD analysis, because automated execution can create the same governance exposure as direct user access.
• Test access controls during user acceptance testing Use UAT to verify role behaviour, approval workflows, and compensating controls before go-live so that control failures surface while the implementation is still changeable.

Key takeaways

• ERP modernization often reintroduces old access assumptions unless role design and governance are reset before go-live.
• The main evidence of failure is predictable: broad roles, unresolved SoD conflicts, and remediation that becomes expensive once production is live.
• The control that matters most is early access governance, including explicit ownership, mapped controls, and tested privileged access paths.

Key terms

• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Access Governance Framework: An access governance framework defines how identities are approved, provisioned, reviewed, and revoked across a system lifecycle. In ERP programmes, it links role ownership, approval paths, exception handling, and audit evidence so security is designed into the implementation rather than added later.
• Risk And Control Matrix: A risk and control matrix maps specific business or security risks to the controls intended to reduce them. For identity teams, it is the bridge between policy and enforcement, because it clarifies which role, workflow, or monitoring control is meant to address each access-related risk.
• Emergency Access: Emergency access is elevated access granted for urgent operational or recovery needs, often under tighter monitoring and time limits. In ERP systems, it must be attributed, approved, and reviewed because it can bypass normal role boundaries and create hidden privilege concentration.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.