What breaks when access controls are not redesigned during an ERP migration?

Why This Matters for Security Teams

ERP migrations are not just system replacements. They change how finance, procurement, HR, supply chain, and IT actually transact, which means access that made sense in the legacy system can become dangerous in the new one. If roles, approvals, and entitlement boundaries are copied forward unchanged, organisations often preserve excessive access, stale exceptions, and SoD conflicts that auditors will surface later. NIST guidance on least privilege and access control is clear that permissions should be purpose-built for the target environment, not inherited by default from the old one, as reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls.

That matters because ERP systems concentrate high-value business workflows in one place. A mis-scoped role can now create vendors, approve payments, change master data, and post journal entries with minimal friction. NHIMG research shows that Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges, which is a useful reminder that over-permissioning is the default failure mode when governance is rushed. In practice, many security teams discover the access problem only after UAT sign-off or audit escalation, rather than through intentional redesign.

How It Works in Practice

Access control redesign during ERP migration should start with business process mapping, not with cloning legacy roles. The goal is to align privileges to the new operating model, then verify that each role supports a discrete job function without creating toxic combinations. Current guidance suggests treating migration as an opportunity to rebuild entitlement architecture around least privilege, segregation of duties, and evidence-based approvals, rather than as a lift-and-shift exercise. That includes reviewing privileged administrative access, service accounts, and integration credentials with the same rigor as human user roles.

Practitioners usually need to combine several controls:

• Role mining and entitlement review to identify inherited access that no longer matches the new ERP process flow.
• SoD analysis to block conflicting functions such as vendor creation and payment approval within the same identity path.
• JIT elevation for temporary access during cutover, testing, and hypercare.
• Strong joiner-mover-leaver workflows so migrated accounts are revalidated, not merely reactivated.
• Logging and attestation to prove who approved what, and why, during the migration window.

For background on the control failures that follow weak lifecycle governance, the patterns in 52 NHI Breaches Analysis are instructive, especially where long-lived credentials and unclear ownership outlast the original system design. Standards such as PCI DSS v4.0 and ISO/IEC 27001:2022 Information Security Management reinforce the need for least privilege, access review, and documented control ownership. These controls tend to break down when legacy role definitions are reused across a heavily customised ERP instance because the inherited structure no longer matches the actual transaction paths.

Common Variations and Edge Cases

Tighter access redesign often increases cutover effort, so organisations have to balance delivery speed against control accuracy. That tradeoff is especially visible in ERP programmes with multiple business units, custom workflows, or regional exception handling. In those environments, a single global role model can be too blunt, but fully localised roles can become ungovernable. Best practice is evolving here: there is no universal standard for the exact role design method, but there is broad agreement that access should be validated against the new process, not copied from the old one.

Two edge cases create recurring problems. First, emergency access during go-live can become permanent if it is not time-boxed and reviewed. Second, integrations and background jobs are often ignored because teams focus on named users, yet these machine identities can carry high-risk privileges into the new ERP. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks highlights how visibility gaps and excessive privileges compound quickly when service accounts are not governed as first-class identities. The practical rule is simple: if a role, account, or approval path cannot be explained in the language of the new business process, it is probably still carrying legacy risk.

Related resources from NHI Mgmt Group

• How should organisations govern access to SAP workloads in RISE with SAP S/4HANA Cloud without weakening identity controls during migration?
• How should organisations replace legacy ERP access controls without creating audit gaps during migration?
• What breaks when third-party access controls on social platforms are immature?
• What breaks when secure access controls do not support common administrator workflows?