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.
Why This Matters for Security Teams
Copying legacy access into ERP is not a harmless migration shortcut. It hard-codes yesterday’s exceptions into tomorrow’s control model, so broad roles, stale service accounts, and unresolved segregation of duties issues survive the cutover. That creates a platform that appears live and functional while quietly carrying the same over-permissioned identity patterns that caused audit pain in the first place. NHI Mgmt Group’s Ultimate Guide to NHIs shows why this matters: 97% of NHIs carry excessive privileges, which is exactly the kind of privilege drift that gets imported when teams clone access instead of redesigning it.
For security leaders, the problem is not only privilege creep. It is also operational debt. Once the ERP goes live, every inherited exception has to be discovered, explained, and remediated under production pressure, often while finance, procurement, or supply chain teams are already depending on the system. The result is slower control validation, more compensating controls, and more disputes between application owners and auditors. OWASP’s OWASP Non-Human Identity Top 10 is relevant here because ERP integrations typically rely on service identities, API keys, and automated jobs that are easy to overgrant and difficult to review consistently. In practice, many security teams encounter the worst access defects only after go-live, rather than through an intentional redesign of the target state.
How It Works in Practice
The safe pattern is to treat ERP access design as a fresh authorization exercise, not a migration copy job. Start by identifying business functions, data domains, and transaction paths, then map those to RBAC only where roles are genuinely stable. Where access is temporary or task-specific, use JIT provisioning and short-lived secrets instead of standing entitlements. For non-human access, the identity primitive should be the workload itself, not a human proxy account. That means cryptographic workload identity, strong secret handling, and explicit owner accountability for every integration and automation.
Practitioners usually need to separate three layers:
- Human user access, governed by least privilege, approval workflows, and periodic review.
- Service and integration access, governed as NHI, with scoped credentials, rotation, and offboarding.
- Privileged ERP administration, governed through PAM and, where possible, JIT elevation rather than permanent admin rights.
When organisations redesign access this way, they can test segregation of duties before production, not after the first audit cycle. The Ultimate Guide to NHIs — Key Challenges and Risks is useful for understanding how excessive privileges, weak visibility, and poor rotation create persistent exposure. OWASP also notes that identity hygiene for non-human actors must be validated continuously, not assumed from the original deployment. A practical benchmark comes from the same NHIMG research set: only 5.7% of organisations have full visibility into their service accounts, which explains why cloned ERP access so often survives unnoticed. These controls tend to break down when the ERP is heavily customised and the organisation cannot trace which jobs, APIs, and batch processes actually use each entitlement.
Common Variations and Edge Cases
Tighter access redesign often increases migration effort, requiring organisations to balance launch speed against control quality. That tradeoff is real, especially when the ERP must support multiple business units, country entities, or legacy interfaces on day one. In those cases, current guidance suggests phasing the redesign: start with high-risk privileges, privileged integrations, and SoD conflicts, then retire inherited access in controlled waves rather than leaving it in place indefinitely.
There is no universal standard for this yet, but several patterns recur. Shared accounts are still common in manufacturing, logistics, and finance ERP estates, even though they make ownership and auditability weak. Batch jobs and middleware accounts are also frequent exception holders because they were created for uptime, not for lifecycle governance. The same problem appears in third-party connectors, where access is granted once and rarely revisited. NHI Mgmt Group research shows why this cannot be treated as a marginal issue: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 79% of organisations have experienced secrets leaks. For ERP programmes, that means access cloning does not merely preserve inefficiency; it preserves breach paths.
For practitioners comparing frameworks, 52 NHI Breaches Analysis is a helpful reference point for recurring failure modes, while the OWASP NHI guidance remains the clearest external benchmark for least privilege and rotation discipline. The practical lesson is simple: if the new ERP inherits the old exception model, the organisation has not modernised access, it has only rehosted the risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Cloned ERP access often creates excessive NHI privilege and weak ownership. |
| NIST CSF 2.0 | PR.AC-4 | Legacy access cloning undermines least privilege and access review discipline. |
| NIST AI RMF | GOVERN | Access redesign needs accountability, oversight, and documented decision-making. |
Establish governance for ERP identity decisions before migration and enforce ownership throughout.
