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.
Editorial analysis by NHI Mgmt Group, based on content published by Delinea: “Include security and compliance from the start of ERP implementations”.
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.
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.
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.
Practitioner guidance
- Define the access governance framework before design freeze Set ownership, approval paths, provisioning rules, and role design principles before the ERP blueprint is locked.
- 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.
Bottom line: ERP modernization often reintroduces old access assumptions unless role design and governance are reset before go-live.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/06/2026 1:01 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: ERP modernization exposes access governance gaps in NHI controls