TL;DR: Active Directory migration cutovers can expose RC4-dependent service accounts that looked healthy in source domains but fail in AES-default targets, because standard tooling copies NTLM hashes without regenerating AES keys, according to Semperis. The real risk is not universal breakage, but a predictable failure class that identity teams need to discover before July 2026 enforcement.
NHIMG editorial — based on content published by Semperis: Why are migration projects uniquely exposed to RC4 changes?
Questions worth separating out
Q: What breaks when RC4-only Kerberos accounts are migrated into AES-default Active Directory domains?
A: Accounts can authenticate in the source domain and then fail in the target when AES is expected but no AES key material exists.
Q: Why do service accounts with old Kerberos keys increase migration failure risk?
A: Old service accounts often have passwords that were set once and never rotated, which means they may never have generated AES keys.
Q: How do security teams know whether RC4 dependency is actually present before migration?
A: They need to correlate Kerberos ticket events with account configuration and target-domain behaviour.
Practitioner guidance
- Run dual-domain RC4 discovery before any cutover Assess both source and target domains for RC4 dependence, then compare the results rather than reviewing each estate in isolation.
- Correlate Kerberos events with directory attributes Use event logs to confirm whether accounts that appear AES-ready are still requesting RC4 tickets in practice.
- Inventory non-Windows Kerberos dependencies explicitly Walk Linux hosts, Java services, appliances, and other systems that rely on keytabs or cached credentials, because these often preserve old encryption assumptions after directory migration.
What's in the full article
Semperis's full blog post covers the operational detail this post intentionally leaves for the source:
- Phase-by-phase discovery methodology for tracing RC4-dependent accounts across source and target domains
- PowerShell and event-log approaches for validating where AES support exists in metadata but not in actual key material
- Application-layer walk-throughs for Linux, Java, appliance, and trust-based dependencies that can fail at cutover
- Remediation guidance for resetting passwords, validating trust settings, and sequencing migration waves
👉 Read Semperis's analysis of RC4-to-AES migration failure risks in Active Directory →
RC4-to-AES cutovers: what IAM teams need to catch before migration?
Explore further
Migration projects expose the gap between account metadata and actual Kerberos state. An account can look AES-capable in Active Directory while still lacking the keys needed to authenticate after cutover. That gap exists because directory attributes, password history, and migration tooling do not always move in lockstep. The practitioner conclusion is that migration readiness must be proven at the ticketing layer, not inferred from object properties alone.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which shows how identity failures compound once one account or secret is exposed.
A question worth separating out:
Q: Who is accountable when a migration cutover breaks authentication for service accounts?
A: Accountability usually spans the identity team, the application owner, and the migration programme because the failure sits at the boundary between directory state and workload dependency. The most effective governance model assigns a named owner to each high-risk account, trust, and application path before cutover, so no one is left tracing tickets after the fact.
👉 Read our full editorial: RC4-to-AES migration risk is surfacing in active directory cutovers