Why do AD migrations often increase identity risk instead of reducing it?

Because migration teams frequently optimise for continuity, not for privilege reduction. Coexistence, trust links, and bulk remapping can preserve access relationships that should have been retired, so attackers may inherit familiar paths into the target environment. The risk is highest when organisations assume a clean cutover equals a clean security posture.

Why This Matters for Security Teams

Active Directory migrations often fail as a security project because they are treated as an availability exercise. Teams preserve group membership, trusts, service accounts, and legacy exceptions so business services keep working, but those same shortcuts can carry forward stale privilege, lateral movement paths, and orphaned access into the target estate. NIST’s NIST Cybersecurity Framework 2.0 emphasises continuous risk management, which is exactly what migrations often lack in practice.

NHIMG research shows why this matters: the Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges and 71% are not rotated within recommended time frames. During AD migration, those weaknesses are easy to preserve if the programme only remaps identities instead of reducing exposure. In practice, many security teams encounter privilege inheritance only after the new domain is already live and attackers have discovered the same old paths.

How It Works in Practice

The safest migration models treat identity as something to re-authorise, not just re-create. That means inventorying users, service accounts, machine accounts, groups, trusts, and delegated admin paths before cutover, then deciding what should be retired, re-scoped, or rebuilt. A straight lift-and-shift of AD objects may complete faster, but it often reproduces the old trust topology in a new environment.

Good migration design usually combines three controls: minimise inherited trust, validate effective permissions, and reissue credentials where possible. Teams should test for over-privileged group nesting, cross-domain trusts, shadow admins, and stale Kerberos or service-account dependencies. Microsoft’s identity guidance and NIST’s identity guidance both support the same operational principle: access should be explicit, current, and justifiable at the time it is used, not simply carried forward because it existed in the source domain.

• Map every administrative path, including delegated OU rights and nested groups.
• Reclassify service accounts instead of bulk-migrating them unchanged.
• Replace long-lived secrets with time-bound credentials where the application can support it.
• Validate post-cutover access with effective-permission testing, not only account migration reports.

This is also where NHI hygiene matters. The Top 10 NHI Issues and the Ultimate Guide to NHIs – Key Challenges and Risks both reinforce that secrets sprawl and excessive privilege are common in mature environments, so migration is an opportunity to reduce them rather than preserve them. These controls tend to break down when coexistence periods are prolonged because trust links and fallback accounts become permanent instead of temporary.

Common Variations and Edge Cases

Tighter migration controls often increase project duration and service-owner involvement, so organisations must balance business continuity against real privilege reduction. That tradeoff is especially sharp in hybrid AD, where on-premises domains, Entra ID sync, and legacy applications all depend on different identity assumptions.

Best practice is evolving for environments with heavy service-account use, because some workloads cannot be modernised in the same migration window. In those cases, current guidance suggests isolating legacy dependencies, enforcing short-lived exceptions, and assigning explicit owners for every remaining trust. A clean cutover without cleanup can still leave the new estate exposed if old trusts, synced groups, or admin workstations remain reachable.

Another edge case is third-party integration. If vendors depend on AD-integrated identities, migration teams sometimes preserve broad access to avoid outages, but that decision should be temporary and reviewed on a set schedule. The migration should end with fewer standing privileges, fewer secrets, and fewer implicit trust paths than the source environment. If it does not, the organisation has changed directories, not risk.

Related resources from NHI Mgmt Group

• Why do cloud migrations often increase IAM risk instead of reducing it?
• Why do hybrid identity environments increase cyber resilience risk?
• Why do Salesforce integrations increase NHI risk?
• When does secret exposure become a broader identity risk?