When access controls are carried over unchanged, organisations often inherit excessive permissions, weak visibility, and unresolved segregation of duties conflicts. That creates audit findings, approval bottlenecks, and higher exposure if a compromised account can reach too much of the business. Migration then becomes a control failure, not just a platform change.
Why ERP migrations expose old access rules so quickly
ERP migrations are not just data and process projects. They also change roles, approvals, reporting lines, and system boundaries, which means the old access model may no longer match how the business actually runs. If permissions are copied forward unchanged, organisations can preserve legacy access that once made sense but now creates excess privilege, segregation of duties conflicts, and audit ambiguity. The result is not only operational friction, but a control environment that no longer reflects the new system design. CIS Controls v8 is useful here because it treats access management and account governance as operational safeguards, not paperwork.
In practice, many security teams discover the access problem only after users start asking for exceptions and auditors start asking why the migrated system still behaves like the old one.
How access control failures show up during the cutover
When access controls are not redesigned, the first break is usually model mismatch. The source ERP may have grown around outdated job roles, informal approvals, or compensating controls that were never documented. In the new ERP, those assumptions can fail because the new role structure, workflow engine, or object model enforces privilege differently. A user who needed broad access for a manual workaround in the legacy environment may no longer need it, yet still receives it by default.
That creates several practical failure modes. First, excessive access spreads because migration teams prioritise continuity over least privilege. Second, segregation of duties conflicts appear when one role now combines tasks that were previously separated across systems or teams. Third, monitoring becomes harder because the new ERP may log access differently, leaving security and audit teams without a clean before-and-after view of who can do what. Where sensitive financial or procurement functions are involved, the risk becomes a governance issue as much as a technical one, because the organisation can no longer prove that approvals, postings, vendor changes, and payments are properly separated.
A useful way to test the migration is to ask whether each role is designed from the target process model, not whether it is merely inherited from the source system. If the answer is “inherited,” then the access design is probably preserving defects rather than eliminating them. This is also where identity and access governance intersects with ERP design: role cleanup, entitlement mapping, privileged account review, and exception handling must be aligned to the migrated operating model, not bolted on afterwards.
Where this guidance breaks down is in highly customised ERP estates with undocumented local exceptions, because the target state can only be trusted after those exceptions are inventoried and rationalised.
Where the usual advice fails: legacy roles, exceptions, and business trade-offs
Tighter access redesign often increases change effort, so organisations must balance speed of cutover against control integrity. That trade-off is especially sharp when the business wants “day-one parity” with the old environment, because parity can preserve access risk even while the platform is modernised.
One common exception is when a temporary migration role is created to keep operations moving. That can be acceptable, but only if it is time-bound, reviewed, and visibly separate from steady-state access. Another edge case is where the new ERP embeds approvals differently from the legacy system, so direct access removal is not enough. In those cases, the organisation must redesign approval paths, not just revoke accounts. Guidance varies here, but the consensus is clear: compensating controls are not a substitute for an access model that reflects the new business process.
Another overlooked issue is that reporting and reconciliation can mask access defects. A user may appear compliant in a static entitlement review while still holding combinations of permissions that create a live SoD conflict across modules. The control must therefore be validated against actual process combinations, not only against role names. NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant because it frames access enforcement, account review, and separation of duties as control outcomes that need verification, not assumptions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | ERP access redesign centers on least privilege and entitlement governance. |
| Recommendation — Apply Control 6 to recertify roles and remove inherited excess access during migration. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations Managed | The question is about whether access rights remain valid in the target ERP. |
| PR.AC-5 — Network Integrity and Segregation | ERP cutovers often change trust boundaries and administrative reach. | |
| DE.CM-8 — Vulnerability and Control Monitoring | Unchanged access controls become visible only when monitoring and reviews catch conflicts. | |
| Recommendation — Manage migrated permissions so only approved users retain the access they need. Separate administrative and business access paths to prevent privilege bleed across the new ERP. Monitor entitlement drift and investigate access anomalies after cutover. | ||
Practitioner Guidance
What to prioritise: Rebuild the role model around the target ERP processes first, then map legacy access into it. If the team starts from old user lists, it usually preserves exceptions that the migration was supposed to remove.
What to verify: Check that privileged access, approval authority, and transaction rights are being tested together, not in isolation. The most dangerous cases are combinations that look harmless per module but create a SoD conflict across end-to-end business flows.
Decision rule: Treat any temporary access bridge as a controlled exception only if there is an expiry date, an owner, and a plan to remove it. If those three things are missing, it is not temporary in practice.
Practitioner takeaway: The real migration failure is not “too much access” in the abstract; it is leaving old trust assumptions in place after the business process has changed.
Related resources from NHI Mgmt Group
- How should organisations replace legacy ERP access controls without creating audit gaps during migration?
- When should organizations review access controls?
- Why do fragmented access governance and GRC processes create more risk during ERP modernisation and cloud migration?
- What breaks when emergency access controls are not extended beyond ERP?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
