Identity migration is now a security redesign problem, not a lift-and-shift

At a glance

What this is: This is an analysis of identity migration that argues the move itself is a security redesign problem, with legacy authentication, standing privilege, policy sprawl, and AI-agent access all needing reassessment together.

Why it matters: It matters because IAM teams are being asked to modernise platforms without importing old access debt, and that decision now affects human, NHI, and emerging AI-agent governance at the same time.

Context

Identity migration is not just a platform swap. When identity providers sit underneath employees, contractors, partners, cloud resources, machine identities, and AI agents, the migration changes authentication, authorisation, lifecycle control, and operational risk all at once. The governance problem is that many teams still treat migration as an implementation project rather than a redesign of the identity control plane.

The article’s core point is that copying the old environment into the new one preserves the same security debt. That means standing privilege, fragmented policy, and legacy authentication all survive the move unless the transition is used to re-evaluate access scope, trust assumptions, and validation steps before production cutover.

Key questions

Q: What breaks when identity migration simply copies the old access model?

A: The organisation preserves the same authentication weaknesses, standing privilege, and policy fragmentation that made the old platform risky. Migration then becomes a replication exercise, where the new system inherits the same blast radius and governance blind spots. The fix is to redesign access scope and retirement rules before cutover, not after users are already depending on the new stack.

Q: When should organisations prioritise migration over access cleanup, and when should they not?

A: Migration should not outrun access cleanup when the platform contains excess privilege, unclear ownership, or legacy authentication that will be hard to unwind later. The highest-value sequence is to clean up the identity model first where possible, then move only the dependencies that have been validated. Otherwise, the move simply rehouses unresolved risk.

Q: What are the signs that an identity migration is failing governance reviews?

A: Common warning signs are duplicated policies, unresolved access exceptions, uncertain ownership for privileged accounts, and a plan that depends on keeping weak authentication in parallel. If teams cannot explain what will be removed, they are likely carrying identity debt forward. A successful programme can show which controls are being retired, not just which system is being replaced.

Q: How should teams govern AI-agent access during an identity platform move?

A: Treat AI agents as governed identities with named owners, explicit permission scope, and lifecycle checks before they are used in discovery, testing, or rollout. Their access should be validated like any other non-human identity, with clear boundaries for what they can inspect or change. If that governance is missing, the migration toolchain itself becomes part of the risk.

Technical breakdown

Why identity migration fails when old authentication is carried forward

Identity migration often fails at the authentication layer because teams preserve the same factor set, the same recovery assumptions, and the same user journey that existed before the move. If the destination platform inherits password-first access patterns, the organisation has modernised the wrapper, not the control. The real issue is that migration is one of the few moments when authenticators, policies, and access flows are already under review, which makes weak methods easier to retire than during business-as-usual operations. Phishing-resistant authentication changes the trust model, but only if the old methods are explicitly removed rather than left in parallel.

Practical implication: treat migration as the point to decommission legacy authentication, not to duplicate it.

Access creep becomes harder to hide during platform consolidation

Over time, identity platforms accumulate standing privilege, overlapping roles, and access that was granted for one project and never withdrawn. Migration exposes that sprawl because every permission and dependency has to be mapped before cutover. The technical risk is not only excess access, but also unclear rightsizing logic, where teams copy entitlements because they cannot prove what is necessary. Just-in-time access and least privilege only become effective if the migration process forces a clean inventory of access relationships and validates which privileges are truly operationally required. Otherwise, the new platform simply reproduces the old blast radius.

Practical implication: use migration inventory to remove standing privilege and rightsize entitlements before the new platform goes live.

AI agents change the identity model because they act inside the migration path

AI agents are not just another application account type in this context. The article treats them as participants in the identity model that may help validate policies, highlight gaps, and operate on behalf of people. That creates a new governance requirement: ownership, permissions, and lifecycle controls must be explicit enough for machine-speed activity, not just human-paced administration. This does not make every AI-enabled workflow autonomous, but it does mean identity migration can no longer assume a human operator is always behind every action. The control model has to account for non-human execution paths during discovery, pre-flight testing, and activation.

Practical implication: extend ownership, approval, and lifecycle rules to AI-agent access before using them in migration workflows.

Breaches seen in the wild

• Taiwan autonomous AI agent cyberattack 2026: Up to eight autonomous AI agents cracked 85 Taiwanese government accounts, pivoted through SSO and exfiltrated 2,564+ personnel records.
• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity migration is now an access-model redesign, not a lift-and-shift project. The old assumption was that identity platforms mainly handled authentication for people. That assumption breaks once the platform also governs contractors, cloud resources, machine identities, and AI agents, because the migration is really a redesign of who can act, under what conditions, and with what oversight. Practitioners should treat the cutover as a control reset, not a data move.

Access creep is the hidden liability most migrations preserve. Standing privilege rarely disappears just because the platform changes. In practice, teams import years of accumulated entitlements, fragmented policies, and exception handling unless they force a rightsizing exercise during discovery and pre-flight. The implication is simple: the new platform inherits the same blast radius unless privilege scope is actively reduced.

Phishing-resistant authentication is a migration decision, not a future-state aspiration. If password-based and other weaker methods remain available during transition, they become the default that survives operational pressure. That is why migration windows are the best time to remove legacy authentication rather than coexist with it indefinitely. Practitioners should use the move to reset the baseline, not to preserve backwards compatibility for weak trust paths.

AI-agent identity governance has to be built into migration design before production cutover. The article is right to place AI agents inside the identity model, because they can operate, validate, and potentially influence the transition itself. What changes for the field is that lifecycle management, continuous evaluation, and permission scoping now need to cover machine-paced actors alongside human users. Teams that ignore that shift will modernise the platform while leaving the governance gap intact.

Identity platform consolidation is becoming a security architecture choice, not just an IT simplification exercise. Fragmented providers and overlapping admin tools create policy drift, inconsistent enforcement, and gaps in accountability. The market signal here is that organisations need stronger transition architecture, not just cleaner tooling. Practitioners should evaluate whether their identity programme can prove what changes, what stays, and what is retired before they move control planes.

What this signals

Identity programmes that approach migration as a technical cutover usually miss the governance reset that the move makes possible. The important question is not just whether the new platform works, but whether it eliminates the access debt, authentication shortcuts, and fragmented policy inheritance that existed before the move.

Identity migration redesign: the value of a migration is measured by what control assumptions it retires, not by how closely it reproduces the old environment. That is especially true when AI agents and machine identities are in scope, because their access patterns can outpace human review cycles and expose gaps in lifecycle governance.

For practitioners

• Map every identity dependency before cutover Inventory identity providers, authentication methods, policies, groups, access relationships, and business-critical dependencies so the migration sequence is based on evidence rather than assumption.
• Retire legacy authentication during transition Use the migration window to remove password-first and other weaker sign-in methods, then make phishing-resistant access the new default for users and sensitive workflows.
• Rightsize standing privilege before activation Review excess entitlements, remove unused administrative access, and convert sensitive operations to just-in-time access so the new platform does not inherit old access creep.
• Define ownership for AI-agent access Assign accountable owners, approved scopes, and lifecycle rules for AI agents that participate in validation or operational workflows, then validate those controls before production rollout.

Key takeaways

• Identity migration should be treated as a redesign of the access model, because copying the old environment preserves the same security weaknesses in a new wrapper.
• Standing privilege, fragmented policy, and weak authentication are the main forms of identity debt that get carried forward when teams prioritise speed over governance.
• The strongest migration plans use discovery, rightsizing, and controlled activation to change the trust model before users and AI agents rely on the new platform.

Key terms

• Identity Migration: The planned movement of identity data, configuration, and control logic from one operating model to another. For cloud identity security, the hard part is usually preserving governance outcomes after the platform, release cadence, and support model change.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
• Identity Debt: Identity debt is the accumulation of unowned, over-permissioned, or poorly governed non-human identities that security teams cannot cleanly inventory or retire. It usually grows when experimentation outruns access governance, leaving service accounts and tokens active long after their original purpose has passed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.