Mike Masciulli Managing Director, Migration Products & Services

Your AD migration didn’t make you more secure. In many environments, it does the opposite.

“How do you know?”

That’s the uncomfortable question I keep coming back to when I talk with organizations planning mergers, cloud transitions, and modernization projects.

Too often, companies spend millions on an Active Directory (AD) migration and consolidation project and treat it like a data move: lift the users, groups, and apps into a new forest, declare success, and assume the hard part is over.

But if you carry over the same delegation mistakes, group nesting, trust relationships, and overprivileged accounts, you can recreate the same attack paths in a new environment—and sometimes make them harder to detect. A clean cutover does not mean a clean security posture.

Here are eleven common risks I see in typical AD migrations. If you approach AD migration with a security-first mindset, you can reduce legacy exposure instead of carrying it forward.


1. Inherited administrative privilege

An AD migration can become a privilege-escalation engine when legacy Domain Admin or Enterprise Admin rights move into the target without review. What looks like continuity is really the transfer of old administrative mistakes into a new environment that should have been built around current security practices.

I’ve seen migrations preserve privilege structures that were decades old. If old privilege survives, old risk survives with it.


2. Legacy attack paths recreated

If you preserve group nesting, delegation, and coexistence shortcuts without analyzing privilege relationships before cutover, attackers can keep the same lateral movement routes they already had. The migration may be operationally seamless, but from a security perspective, the same attack path exists.

In some cases, the migration creates an even more dangerous outcome: a bridge from a compromised source environment into the target. What you fail to validate during migration often becomes someone else’s incident later.


3. Credential exposure during migration

Migration windows are volatile. Credentials are shared, trusts are added, synchronization expands, and legitimate change creates enough noise to hide malicious activity in plain sight.

In April 2026, Microsoft changed the Kerberos KDC default to prefer AES for accounts without explicit encryption settings, a shift that can break RC4-dependent service accounts during coexistence if teams have not identified those dependencies in advance. As my post RC4 and AD Migration: Uncover the Break Scenarios Hiding in Your Source Domain explains, migration projects are uniquely exposed because standard tooling can move an account while leaving its encryption assumptions behind.

Add the risk of attackers abusing trust relationships—or even standing up “ghost forests” to harvest access while teams are focused on cutover—and it becomes clear that the migration window is one of the highest-risk phases in the identity lifecycle.


4. SID-History abuse

The SID-History attribute is useful for continuity and dangerous without governance. Pen testers have used it months after migration to reach legacy resources through identities that should no longer matter.

In practical terms, an attacker can assign the SID-History of an administrative account to a lower-privileged account and regain effective access in the source environment. Worse, these legacy SIDs often linger for years because organizations never fully clean them up.


5. Broken or over-permissive ACLs

Access Control List (ACL) translation without validation is one of the fastest ways to create permission drift. Sensitive HR or finance data can become accessible to broad user groups—and organizations often don’t discover it until an audit fails or a user sees data they should never have seen.

In large, messy environments with huge numbers of groups, that drift is easy to introduce unless you rationalize what truly needs to come forward.


6. Service account failures and hidden privilege

Service identity dependencies are often poorly documented, which is why line-of-business applications can fail days after a migration. But service account problems are not just availability issues. They often expose stale passwords, excessive rights, undocumented dependencies, and authentication paths nobody intended to preserve.

If you do not map service accounts correctly, update ACLs on services and COM objects, and account for system-managed identities, you can shut down the source and discover too late that critical applications in the target still depend on it. At that point, “migration complete” becomes “business disruption underway”—and old privilege may still be embedded in the service tier.


7. Identity collisions and mis-mapping

Weak matching logic can create dangerous identity collisions. A simple example is linking the CEO from an acquired company to someone with a similar name in the target environment. The wrong person can inherit the wrong alias, email, or group memberships.

This is more than directory hygiene. Bad object mapping creates inappropriate access, data exposure, and hard-to-trace authentication problems that undermine trust in the whole migration.


8. Coexistence that expands breach impact

Migration-era connectivity can enlarge the impact of a breach. If the source and target are not sufficiently isolated during coexistence, the migration infrastructure itself can become the bridge that attackers use to extend compromise from the legacy forest into the new one.

Coexistence is operationally useful, but dangerous if you treat it as trusted by default. A rebuilt forest is not automatically a hardened forest.


9. Compliance and audit gaps

When auditors ask who had access during migration, why permissions changed, or when SID-History was added, “we’re not sure” is not an acceptable answer.

If the migration lacks auditable workflows and understandable reporting, security teams cannot prove control over identity changes. That becomes an especially hard conversation with auditors, legal teams, and cyber insurers who want evidence, not assumptions.


10. Forensic blind spots after cutover

Logging isn’t optional during migration. If suspicious activity appears weeks later and logs are incomplete, cryptic, or missing, you lose the ability to reconstruct what happened and how the attacker got in.

If you can’t quantify the attack path with confidence, you also can’t prove you closed it. That is a hard position to defend after an incident.


11. A new forest with old backdoors

These broader risks all stem from the same mistake: carrying forward defects because nobody wants to break anything now.

Dormant accounts, orphaned SIDs, and questionable configurations survive the move. The security debt stays hidden until a later audit, cloud initiative, or breach forces the issue.

And that is the most dangerous assumption of all: believing a rebuilt forest is secure simply because it is new. The real test of an AD migration is not whether users can sign in on Monday. It is whether the new environment is materially harder to compromise than the one it replaced.


Turn your AD migration into a security transformation

AD migrations are some of the best opportunities an organization will ever have to reduce attack paths, remove legacy exposure, and modernize identity security. But that only happens if security is built into the migration plan from the beginning, not treated as cleanup work after the cutover.

If your organization is planning an AD migration, M&A integration, or forest modernization project, this is the moment to decide whether you’re just moving infrastructure or materially improving your security posture.

At Semperis, we treat migration as a security event, not a lift-and-shift exercise. We help organizations reduce legacy risk during the move instead of carrying it forward and paying for it later. Learn more about our AD migration services.


Learn more about successful AD migration