Notifications
Clear all
Topic starter
02/06/2026 12:59 pm
TL;DR: ERP implementations often copy legacy access, rely on broad roles, and defer compliance work until late-stage testing, which increases SoD conflicts and audit findings, according to Delinea. Treating security as a design input instead of a phase-two task is now the difference between controlled go-live and expensive remediation.
NHIMG editorial — based on content published by Delinea: Include security and compliance from the start of ERP implementations
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
That means the control priority is not just migration success, but how much inherited access is intentionally removed before launch?
👉 Read Delinea’s guidance on security and compliance in ERP implementations →
Explore further
02/06/2026 1:01 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: ERP modernization exposes access governance gaps in NHI controls
