ERP modernization exposes access governance gaps in NHI controls

At a glance

What this is: This is a Delinea blog post arguing that ERP security and compliance must be designed from the start, with access governance, segregation of duties, and privileged access controls built into implementation rather than added later.

Why it matters: For IAM and NHI practitioners, the article matters because ERP rollouts create new service accounts, roles, and elevated access paths that can harden into long-lived governance debt if they are not controlled early.

By the numbers:

• The organization was able to reduce SoD conflicts at go-live by about 85% compared to the initial design baseline.
• The organization also saved an estimated 60-70% in post-go-live remediation efforts.

👉 Read Delinea’s guidance on security and compliance in ERP implementations

Context

ERP modernization is not just a systems upgrade. It is a governance event that resets who and what can access critical business processes, and that includes human users as well as non-human identities such as batch jobs, service accounts, and emergency access paths. When access design is deferred, organisations inherit the old control model into a new environment, which defeats the point of the migration.

The article argues that security, compliance, and role design must be settled in the blueprint phase, not patched in after implementation pressure rises. That is a familiar failure mode in ERP and a common one in broader IAM programmes: the business wants speed, while access governance gets treated as a cleanup task. For NHI management, the lesson is that hidden automation and indirect privileges can become part of the control gap if they are not mapped early.

Key questions

Q: How should security teams implement ERP access governance before go-live?

A: Start with a defined access governance framework that assigns ownership, approval paths, and provisioning rules before implementation is complete. Map roles to business processes, test them in UAT, and require documentation for exceptions and compensating controls. If governance starts after cutover, organisations inherit avoidable SoD conflicts and expensive rework.

Q: Why do ERP projects create hidden NHI risk?

A: ERP projects create hidden NHI risk because batch jobs, integration accounts, and emergency access often receive broad or poorly attributed permissions. Those identities can execute sensitive steps without the same review applied to users, which weakens segregation of duties and makes control failures harder to detect.

Q: What breaks when organisations copy legacy access into a new ERP system?

A: Copying legacy access preserves old privilege patterns, including broad roles and unresolved segregation of duties conflicts. The new platform then goes live with inherited exceptions instead of a redesigned control model, which increases audit findings, operational confusion, and the cost of later remediation.

Q: When should organisations treat privileged access as a release gate in ERP programmes?

A: Privileged access should be treated as a release gate before production cutover, not as a post-launch cleanup item. Teams need evidence that emergency access is monitored, approvals are documented, and roles are aligned to risk tolerance before they allow go-live.

Technical breakdown

Why ERP role design fails when access governance starts too late

ERP implementations often begin with standard roles, then adjust them just enough to keep the project moving. That approach leaves segregation of duties conflicts embedded in the role model, especially when teams copy access from the legacy system or add broad emergency privileges to avoid delays. The technical problem is not only excessive permissions. It is also the absence of a governing model for approvals, ownership, control testing, and exception handling. When custom transactions, extensions, and cross-module workflows are introduced, the role matrix can no longer be validated by simple template reuse.

Practical implication: Treat role engineering as an architecture workstream and validate it before go-live, not after users are already operating in production.

How batch jobs and non-human identities create hidden SoD risk

Batch jobs, scheduled tasks, and other non-human identities often act inside ERP environments with credentials that are persistent, shared, or poorly attributed. That creates indirect segregation of duties problems because automation can execute sensitive steps without the same review applied to human access. If a service account can both initiate and approve a process path, or if its permissions mirror an overbroad user role, the control failure is operational rather than theoretical. These identities should be mapped to business functions, ownership, and approval boundaries just like human roles.

Practical implication: Inventory every ERP automation identity and bind it to a named owner, a defined purpose, and a least-privilege permission set.

What a controlled ERP go-live looks like from an identity perspective

A controlled ERP go-live is not risk-free. It is a release where roles have been designed, tested, and approved, unresolved SoD conflicts are either remediated or formally accepted, and emergency access is monitored rather than left opaque. The access model should align to the system design, include documented control ownership, and be verified during user acceptance testing. In practice, that means access provisioning, privileged access, and compensating controls are all part of the same operating model instead of separate teams working in parallel.

Practical implication: Require audit-ready evidence for roles, approvals, and emergency access before production cutover.

Threat narrative

Attacker objective: The attacker or negligent insider gains unauthorized ability to move through ERP business processes without detection or meaningful control separation.

1. Entry occurs through legacy role copying, excessive default permissions, or poorly controlled emergency access during ERP migration.
2. Escalation follows when broad roles or automation identities can perform multiple steps in the same business process without effective SoD separation.
3. Impact is audit findings, fraud exposure, and expensive post-go-live remediation when the inherited access model proves unsafe.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• BeyondTrust API key breach — compromised BeyondTrust API key led to unauthorized SaaS access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Security is a design decision, not a testing activity. ERP programmes that defer access governance simply move risk downstream. By the time UAT reveals role conflicts, the organisation has already built technical debt into the control model. Practitioners should treat identity design as part of the architecture, not a post-build cleanup.

ERP migration is an NHI event as much as an application event. Batch jobs, integration accounts, firefighter access, and scripted automations all become part of the access graph. If those identities are not inventoried alongside human roles, the organisation will miss the actual control surface. The practical conclusion is that NHI governance must be built into ERP programme governance from day one.

Least privilege only works when role design is tied to business process boundaries. Broad super roles and copied legacy permissions undermine both compliance and operational clarity. A meaningful access model maps privileges to process steps, ownership, and exception handling. That means IAM teams must work from the process model, not just the application menu tree.

Named concept: ERP access inheritance debt. This is the control debt created when legacy permissions, emergency access patterns, and automation identities are carried into a new ERP environment without redesign. The longer teams delay remediation, the more likely the migration becomes a permanent exception state. Practitioners should measure how much old access survives the transformation and reduce that inheritance before go-live.

GRC has to be embedded in implementation governance, not invited in after design is fixed. When control ownership, RACM mapping, and SoD policy are established early, compliance becomes testable and sustainable. That is the point where the programme moves from reactive remediation to controlled release. Practitioners should make access governance a release gate, not a follow-up task.

From our research:

• The organization was able to reduce SoD conflicts at go-live by about 85% compared to the initial design baseline, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
• For lifecycle controls, see NHI Lifecycle Management Guide for the operational steps that reduce inherited access risk before production cutover.

What this signals

ERP access inheritance debt: organisations should expect modernization to preserve more old privilege than project plans admit. When legacy roles, emergency access, and automation identities are carried forward intact, the new ERP stack becomes a better-documented version of the same risk. That means the control priority is not just migration success, but how much inherited access is intentionally removed before launch.

With 72% of organisations reporting or suspecting an NHI breach in our referenced research, hidden service accounts and batch identities cannot be treated as implementation detail. ERP programmes need a named owner for every non-human credential, plus release gates that prove those identities are least privilege before cutover.

The practical signal for IAM and GRC teams is simple: if access reviews only begin after the functional build is finished, the programme is already behind. Early control mapping, documented SoD ownership, and emergency access monitoring should be visible in the project plan, because that is what separates controlled transformation from permanent exception handling.

For practitioners

• Map every ERP identity type before design freezes Inventory human roles, service accounts, batch jobs, emergency access, and integration credentials, then assign an owner and business purpose to each identity.
• Design roles from process boundaries, not from legacy templates Build RBAC around end-to-end business processes and separate configuration, operations, and monitoring duties so copied access does not reintroduce SoD conflicts.
• Test access controls during UAT and sprint reviews Validate provisioning flows, privileged access, and compensating controls before cutover so role defects are found while remediation is still cheap.
• Require audit-ready evidence at go-live Confirm that roles, risks, controls, approvals, and exception records are documented before production cutover, including emergency access monitoring.

Key takeaways

• ERP modernisation becomes an access governance problem the moment teams copy legacy roles into a new control model.
• Non-human identities such as batch jobs and integration accounts can carry hidden SoD risk if they are not inventoried and owned early.
• The strongest ERP implementations treat role design, privileged access, and audit evidence as release criteria, not follow-up tasks.

Key terms

• Segregation Of Duties: Segregation of duties is the practice of preventing one identity from completing conflicting steps in a business process. In ERP environments, it reduces fraud and error risk by separating initiation, approval, configuration, and monitoring across different roles or controlled exceptions.
• 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.
• 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.
• Non-Human Identity: A non-human identity is any credentialed digital actor that authenticates without a person at the keyboard. It includes service accounts, batch jobs, API keys, tokens, certificates, and autonomous agents, all of which need ownership, scope, rotation, and review to stay within control boundaries.

Deepen your knowledge

ERP access governance and segregation of duties are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is embedding access controls into ERP transformation, the course can help you formalise the model before go-live.

This post draws on content published by Delinea: Include security and compliance from the start of ERP implementations. Read the original.