RC4-to-AES migration risk is surfacing in active directory cutovers

At a glance

What this is: This is a migration risk analysis showing how RC4-dependent accounts can fail when Active Directory identities move into AES-default domains.

Why it matters: It matters because identity teams need to scope Kerberos, service-account, and trust dependencies before cutover, or application failures will surface after migration when ownership and telemetry are already strained.

👉 Read Semperis's analysis of RC4-to-AES migration failure risks in Active Directory

Context

RC4-to-AES migration risk is a Kerberos and Active Directory governance problem, not just a crypto setting change. When an identity is moved into a stricter domain, the account can keep its old behaviour while the target environment assumes newer encryption material exists, and that mismatch is what breaks authentication at cutover.

The article focuses on a narrow but operationally painful failure mode: accounts that authenticate successfully in the source domain but fail once they land in the target. For IAM and AD migration teams, that means encryption policy, password history, service-account ownership, and trust configuration all need to be validated together before the move.

Key questions

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. The directory may still suggest AES support, yet the account only has RC4-derived keys, so fresh ticket requests fail at cutover. This is why migration teams need evidence from Kerberos events, not just attribute checks.

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. They remain stable until migration forces new authentication behaviour, then the hidden dependency surfaces as intermittent or total application failure. In practice, age and infrequent rotation are strong indicators of break risk.

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. If AD says an account supports AES but the logs show RC4 tickets or the application fails after the move, that is a real dependency, not a theoretical one. A discovery programme that combines telemetry and ownership is the reliable way to confirm exposure.

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.

Technical breakdown

Why RC4-only Kerberos keys break at migration cutover

Kerberos authentication depends on the key material tied to an account password. In the scenario described, standard migration tooling copies the NTLM hash but does not regenerate AES keys, so an account can appear ready while still holding RC4-only material. Once the target domain expects AES, the KDC tries to issue AES tickets, finds no matching key, and authentication fails. This is why the problem often stays invisible in steady state and only appears when the migration forces fresh ticket requests.

Practical implication: Validate that migrated accounts have regenerated AES keys before cutover, not just copied credentials.

How msDS-SupportedEncryptionTypes can mislead migration teams

The msDS-SupportedEncryptionTypes attribute can signal AES support even when the target-side key material has never been created. That creates a false sense of readiness because the directory metadata and the actual cryptographic state no longer match. The article’s key point is that attribute-based discovery alone is insufficient. You need both configuration and event evidence to identify accounts where AD says AES is available but Kerberos still falls back toward RC4 behaviour or simply fails.

Practical implication: Correlate directory attributes with Kerberos event data before trusting any RC4-to-AES migration assessment.

Why trust settings and dual-running domains amplify kerberos failure risk

Migration projects are not only moving accounts, they are also moving trust paths. That means a trust pinned to RC4, a lower functional level in the target, or dual-running authentication across source and target can all create break points that do not appear in steady-state account review. The article frames these as migration-mechanism risks because the failure is caused by the way identity moves between realms, not by a single bad account alone.

Practical implication: Inventory trust encryption, domain functional level, and coexistence paths as part of the cutover plan.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.

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

NHI Mgmt Group analysis

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.

Standing encryption assumptions break when identity crosses a stricter domain boundary. The common assumption is that if an account authenticates in source, it will authenticate in target after migration. That assumption fails when the source domain tolerates RC4 and the target requires AES, because the account's usable key material may not exist in the new realm. The implication is that cutover planning has to treat encryption state as part of identity lifecycle, not as a static domain setting.

RC4-dependent service accounts create identity blast radius that only appears under coexistence pressure. The article shows that dormant or infrequently used accounts can run for years without visible symptoms and then fail when migration forces fresh authentication across many systems at once. That pattern is especially dangerous in M&A and long-lived AD estates, where ownership and dependency knowledge decays over time. Practitioners should treat every migrated service account as a potential dependency cluster, not a single object.

RC4-to-AES cutover risk is really a governance discovery problem, not a patching problem. The breakage described here is about discovering which accounts depend on encryption behaviour that will no longer be honoured after enforcement. That is an IAM and migration governance issue, because remediation depends on scoping owners, dependencies, trusts, and application paths before the deadline. The practical conclusion is that discovery, not emergency response, decides whether the migration succeeds.

Kerberos migration failures reward evidence-led governance over attribute-led hygiene. Configuration checks are necessary, but the article makes clear that event logs and application context are what confirm break scenarios. That means teams relying only on inventory queries will miss the accounts that matter most. The practitioner takeaway is to build a discovery process that joins directory state, ticket telemetry, and application ownership before the cutover window opens.

From our research:

• 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.
• For a broader view of how these failure patterns show up in practice, see 52 NHI Breaches Analysis for the recurring control gaps behind real incidents.

What this signals

Identity teams should treat migration as a detection exercise, not just a cutover checklist. If the programme cannot correlate ticketing events, domain attributes, and workload ownership, it will miss the exact accounts that fail after the move. The operational lesson is that discovery quality becomes a release criterion for identity change.

RC4-to-AES migration work also exposes where lifecycle governance is thin. Old service accounts, stale trusts, and long-lived appliance credentials often outlast the people who created them, which means ownership and offboarding discipline matter as much as encryption policy. Teams that already use the NHI Lifecycle Management Guide can anchor migration readiness in a lifecycle view instead of a one-time audit.

For teams mapping this into control language, NIST Cybersecurity Framework 2.0 is the right external reference point because the issue sits across identify, protect, detect, and recover. The programme question is whether your change process can prove that identity dependencies will still function after enforcement moves.

For practitioners

• 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. Prioritise service accounts, trusts, and long-lived identities that may have never regenerated AES keys.
• Correlate Kerberos events with directory attributes Use event logs to confirm whether accounts that appear AES-ready are still requesting RC4 tickets in practice. This closes the gap between what AD says and what the authentication layer is actually doing.
• 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.
• Document trust and functional-level asymmetry Record the source and target domain functional levels, DC patch states, and trust encryption settings together so you can see where RC4 behaviour is still embedded in the migration path.

Key takeaways

• RC4-to-AES migration failures are usually hidden until cutover forces fresh Kerberos authentication across accounts that never regenerated AES keys.
• The scale of NHI compromise is already material, with 72% of organisations reporting or suspecting a breach, which means migration-related identity failure is not a corner case.
• Teams that correlate directory state, Kerberos telemetry, and workload ownership before migration are far less likely to discover breakage through user tickets after enforcement.

Key terms

• RC4-dependent account: An account whose Kerberos authentication still relies on RC4-derived key material. In migration contexts, that dependency can stay hidden until the account is moved into a domain that expects AES keys, at which point authentication may fail even though the account looked valid before cutover.
• AES key regeneration: The process that creates fresh AES Kerberos keys when an account password is reset in a compatible domain. For migrated identities, this is often the difference between an account that appears configured correctly and one that can actually authenticate in the target environment.
• Migration-mechanism risk: A failure mode created by the way identities move between domains rather than by a single misconfigured account. It includes trust mismatches, dual-running behavior, and lost encryption state, all of which can surface only when the migration reaches cutover.

Deepen your knowledge

RC4-to-AES migration discovery and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are preparing identity cutovers across legacy and modern domains, it is worth exploring.

This post draws on content published by Semperis: Why are migration projects uniquely exposed to RC4 changes? Read the original.