Cross-application identity governance becomes harder because migrations change entitlements, workflows, and approval paths at the same time. Security teams must preserve business continuity while preventing outdated access from following users, service accounts, or integrations into the new environment. Without coordinated governance, privilege sprawl and orphaned access become more likely.
Why This Matters for Security Teams
ERP migrations and continuity programmes force identity governance to operate across two realities at once: the legacy system still runs critical business processes while the target platform is already receiving users, service accounts, integrations, and approvals. That overlap is where access drift happens. Controls that worked in one application often fail when entitlements are renamed, re-scoped, or reissued under a different model, especially if joiner-mover-leaver processes were built for steady-state operations rather than dual-run cutovers.
This matters because cross-application governance is not just about who gets access, but about whether the right identity, with the right privilege, is still valid in both environments on the same day. NIST’s Cybersecurity Framework 2.0 and SP 800-53 Rev. 5 both reinforce the need for continuous access control, but migrations make that much harder to execute cleanly. NHIMG’s Ultimate Guide to NHIs shows why this becomes acute: NHIs outnumber human identities by 25x to 50x in modern enterprises, and many of those machine identities are embedded in workflows that business teams cannot easily pause.
In practice, many security teams discover orphaned access only after a cutover exception, failed interface, or emergency rollback has already widened the blast radius.
How It Works in Practice
During an ERP migration, identity governance has to reconcile three moving targets at once: user provisioning, application-to-application trust, and business process continuity. A user may need access to both systems while data is synchronised, but each system may represent that entitlement differently. Service accounts and API keys are even harder to manage because they are often hidden inside integrations, job schedulers, or middleware. Without a unified inventory, the governance team cannot tell whether the same function is being performed by one identity, three duplicated identities, or a retired account that still works.
The practical response is to treat migration governance as a temporary control plane, not a one-time IAM project. That means mapping the legacy role model to the target role model, reviewing every privileged entitlement used in production paths, and explicitly deciding whether access should be copied, remediated, or retired. For NHIs, the best practice is to pair inventory with lifecycle controls and rotation discipline, as described in the lifecycle guidance. This is especially important because migration windows tend to expose the weakest parts of identity operations, including stale secrets, over-privileged integrations, and incomplete offboarding.
- Establish a single entitlement map for both source and target applications before cutover.
- Classify identities by type: human user, admin, service account, workload, or third-party integration.
- Require approval for every exception, especially shared accounts and temporary bridge access.
- Rotate or reissue secrets that were copied during the transition, rather than assuming legacy credentials remain safe.
- Validate that deprovisioning in one system actually removes access in the other.
NHIMG’s 52 NHI Breaches Analysis and State of Non-Human Identity Security both underscore the operational risk of weak visibility during change programmes, including the fact that 85% of organisations lack full visibility into third-party OAuth connections. These controls tend to break down when the ERP migration includes custom integrations, outsourced support teams, and overlapping approval chains because identity ownership becomes ambiguous across platforms.
Common Variations and Edge Cases
Tighter governance during migration often increases operational overhead, requiring organisations to balance faster cutover against stricter entitlement review. That tradeoff becomes most visible when continuity teams insist on keeping emergency access open while security teams are trying to remove standing privilege.
There is no universal standard for every migration pattern, but current guidance suggests treating several cases differently. Human users can often be re-certified through role mapping and manager approval, while service accounts usually need a more technical review of authentication method, token scope, and dependency chain. In hybrid ERP environments, a role may look consistent in the business glossary but behave differently in the identity store, so entitlement equivalence must be tested rather than assumed. The risk is even higher when the old and new applications share downstream systems such as payroll, procurement, or reporting platforms.
One common edge case is disaster recovery or rollback planning. Security teams may preserve access on purpose so operations can fail back quickly, but that creates a time-limited exception that must be tracked and revoked after stabilisation. Another is third-party managed integration, where the external provider may control secrets or nested authorisations that the enterprise cannot fully inspect. Best practice is evolving here, especially for agentic automation and cross-system orchestration, so policy owners should document where manual approvals, JIT access, or workload identity checks are mandatory rather than relying on inherited roles alone.
For deeper context on hidden NHI risk and remediation gaps, NHIMG’s Top 10 NHI Issues is a useful reference. These situations usually go wrong when migration teams optimise for continuity first and only discover after go-live that the old entitlement model was still granting access somewhere else.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-02 | Migration governance needs continuous identity and access validation across changing systems. |
| NIST SP 800-63 | Identity proofing and lifecycle assurance matter when users and admins are re-established during migration. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Cross-application migrations often leave stale non-human credentials and orphaned service accounts behind. |
| OWASP Agentic AI Top 10 | A-04 | Automated migration and continuity workflows can expand privilege unpredictably if not constrained at runtime. |
| CSA MAESTRO | MCP-2 | Agentic orchestration and workload trust need explicit governance when systems and approvals are in flux. |
Reconcile entitlements continuously during cutover and verify access removal in both old and new ERP environments.
Related resources from NHI Mgmt Group
- How should security teams approach compliance-centric identity governance across ERP and business application environments?
- Why does identity governance become harder as enterprises scale their applications and identities?
- Why do healthcare identity programmes become harder to manage as organisations grow and modernise?
- Why does identity become harder to govern as organisations scale out their digital environment?