Microsoft’s decision to flip a long-standing encryption default in Active Directory — moving Kerberos away from RC4 and toward AES-SHA1 by default — is the most consequential security change for Windows authentication in years, and it arrives after more than two decades of compatibility-first choices that left many enterprise networks exposed to identity-based attacks.
Background
For enterprise Windows environments Active Directory is the backbone of identity and access. The Kerberos implementation that Active Directory uses negotiates encryption types (enctypes) during ticket requests; those enctypes determine how service tickets and session keys are protected. Historically, older Kerberos deployments and many legacy clients relied on
RC4-HMAC (commonly called RC4) because it was ubiquitous and interoperable. Microsoft added support for stronger algorithms (notably
AES in Windows Server 2008), but RC4 persisted as a default fallback for decades to preserve compatibility with legacy appliances and third‑party systems. This long tail of compatibility is now being closed: Microsoft has announced that,
by mid‑2026, domain controllers running Windows Server 2008 and later will update KDC defaults so the Kerberos Key Distribution Center issues AES‑SHA1 session keys by default and
RC4 will be disabled by default unless explicitly reenabled by a domain administrator. The move didn’t happen in a vacuum. Cryptanalysis over the past 25+ years has steadily eroded confidence in RC4 for many uses. The IETF formally prohibited RC4 cipher suites for TLS in 2015 (RFC 7465) after practical attacks exploited biases in the RC4 keystream. Modern protocol stacks moved on; but identity systems — where interoperability and legacy embedded devices matter — often lag behind. The new Microsoft change brings Kerberos defaults in line with modern cryptographic expectations.
Why this matters now: Kerberoasting, breaches, and political heat
Kerberoasting explained
Kerberoasting is an offline cracking technique that targets Kerberos service tickets (TGS). An attacker with any valid domain account can request a service ticket for a service principal name (SPN), extract the portion of the ticket encrypted with the service account’s key, and then crack it offline to recover the service account’s password. The technique does not require privileged network access and can be executed stealthily; it becomes dramatically easier when the ticket is protected with weak enctypes such as RC4. AES‑protected tickets use stronger key derivation and iterations that make offline cracking far more expensive. Microsoft specifically cites Kerberoasting as a primary reason for the change.
Real-world consequences: Ascension and congressional scrutiny
That theoretical risk translated into real-world impact during a high-profile incident involving Ascension, a major U.S. healthcare provider. Public reporting and congressional correspondence say the 2024 intrusion involved Kerberos abuse and that RC4‑related weaknesses contributed to the attackers’ ability to move through the environment. The breach affected hundreds of hospitals and the records of millions of patients — a high‑stakes example that helped propel political scrutiny. Senator Ron Wyden publicly urged the Federal Trade Commission to investigate Microsoft for what he called “gross cybersecurity negligence,” citing the continuing default support for RC4 as one of the systemic problems that enabled the attack. Microsoft has pushed back on some of Wyden’s characterizations while accelerating work to flip the default.
What Microsoft is changing — the technical specifics
Microsoft’s public guidance and product blog lay out a multi-part change:
- New default KDC behavior: domain controllers on Windows Server 2008 and later will default to issuing AES‑SHA1 session keys for Kerberos; RC4 will be disabled by default for ticket issuance. Administrators can still explicitly re-enable RC4 for specific accounts or KDCs, but that will be an opt‑in exception rather than the norm.
- Enhanced telemetry and auditing: KDC and Kerberos auditing (Event IDs such as 4768/4769) will include richer fields that show the encryption types advertised and used, and Microsoft has added the ability to surface which accounts and clients lack AES key material. This visibility is intended to make discovery and remediation practical at scale.
- Diagnostic and remediation tooling: Microsoft published PowerShell helper scripts and guidance (for example, Get‑KerbEncryptionUsage.ps1 and List‑AccountKeys.ps1) and documented Group Policy and Windows Admin Center workflows to enumerate and fix RC4 dependencies. These tools let administrators locate service accounts with SPNs that lack AES keys, find clients that advertise only RC4, and generate remediation plans.
- Phased timeline: Microsoft has signaled the change as a default flip with months of runway, not an immediate forced removal. The stated operational window aims for mid‑2026 so that organizations have time to inventory, remediate, and test before the default change becomes effective in production DCs.
These are tangible changes that make it operationally feasible for admins to find RC4 usage and fix it ahead of the deadline — but the devil is in the details.
The cryptography: why RC4 is a problem and why AES‑SHA1 is safer here
RC4 is a stream cipher whose keystream exhibits statistical biases; these biases were shown decades ago and culminated in increasingly practical attacks that made RC4 untenable for TLS and other protocols. RFC 7465 documents the IETF’s decision to prohibit RC4 cipher suites because RC4 no longer provides the needed security guarantees for TLS. While TLS and Kerberos are different protocols, the principle remains: a cipher that exhibits exploitable biases or weak key‑derivation in a given application domain materially weakens security. In the Kerberos context, the implementation detail that amplified risk was not RC4 alone but how the RC4 path derived keys: historically, the NTLM/RC4 path used MD4‑based key derivation with no salting and effectively a single round — which is
fast to guess. In contrast, the AES‑SHA1 approach used by modern Kerberos enforces slower, iterated constructions, and produces AES128/256 keys that impose several orders of magnitude more work for an offline cracker. Microsoft’s public explanation quantifies this: AES‑SHA1‑derived keys require far more computational work to crack than RC4‑derived keys, effectively raising the cost of Kerberoasting by ~1,000× in typical comparisons. That gap is why replacing RC4 as the default dramatically reduces the population risk from Kerberoasting-style attacks.
Practical impact and compatibility risks
Any vendor default flip that hardens security will break some legacy scenarios. The operational realities administrators must contend with include:
- Third‑party appliances and embedded devices. Many legacy network appliances, OT devices, and older software stacks only support RC4/NTLM‑style enctypes. Those devices may fail authentication if AES is enforced and RC4 is disabled. Remediating these requires vendor firmware updates, proxying, or isolation.
- Accounts missing AES keys. Active Directory stores derived key material when an account password is set. If an account was created long ago and never had its password reset after AES was introduced, AES keys might be absent; those accounts will need password resets (or rekeying) to generate AES key material. Microsoft’s remediation guidance and scripts identify those accounts.
- Operational complexity. Kerberos enctype negotiation depends on multiple components: the client’s advertised enctypes, the account’s msds‑SupportedEncryptionTypes attribute, and the KDC’s available keys and registry defaults (e.g., DefaultDomainSupportedEncTypes). Mistakes during policy changes can produce authentication failures that are hard to diagnose without the new audit fields and logging Microsoft is providing.
- Escape hatches and policy risks. Microsoft will leave RC4 available as an explicit opt‑in. That is necessary for compatibility in some environments, but it also creates a governance risk: organizations that re-enable RC4 as a short‑term workaround must treat that configuration as a high‑risk exception with strict monitoring and a documented sunset plan.
Community and operations teams have been preparing for this change: WindowsForum threads and IT community drafts emphasize testing, staged rollouts, and vendor coordination as critical to avoid business disruption while eliminating a systemic weakness. Administrators are being urged to
use the lead time to inventory, test, and remediate rather than defer until the change is forced upon production DCs.
Strengths of Microsoft’s approach — and open criticisms
Notable strengths
- Default hardening. Changing a vendor default matters because many enterprises never change defaults. Making AES the default reduces population‑level exposure across thousands of deployments instantly and is a high‑leverage defensive move.
- Operational telemetry and tooling. Adding log fields to Kerberos events and shipping scripts gives security teams the means to find the problem, not just be told it exists. Visibility has been a recurring blocker for large‑scale remediation—this step addresses that operational gap.
- Phased rollout. Microsoft is opting for a staged, well‑documented rollout with tooling and guidance instead of an abrupt removal. That reduces the risk of widespread authentication outages if administrators follow the recommended staging plan.
Criticisms and risks
- Too slow, for too long. Critics (and lawmakers) argue Microsoft should have removed weak defaults earlier; long‑standing compatibility choices prolonged exposure and arguably contributed to high‑impact incidents. Congressional scrutiny — including Senator Wyden’s public letter — highlights the political dimension of leaving insecure defaults in critical infrastructure software. The complaint is that compatibility‑first decisions carried an ongoing national‑security cost.
- Vendor coordination burden. Many organizations rely on dozens or hundreds of third‑party vendors for appliances, scanners, printers, and industrial controls; achieving a coordinated firmware/driver update cadence across that landscape is costly and time‑consuming. The default flip shifts the burden of compatibility remediation back onto enterprises and their suppliers.
- Residual artifacts. AD will likely continue to contain RC4/NTLM‑derived keys and legacy artifacts for the foreseeable future. That residual surface must be managed — otherwise re‑enabled RC4 paths, or misconfigured services, could reintroduce risk. Microsoft’s change lowers population risk but doesn’t automatically eliminate the legacy pieces.
WindowsForum community discussion documents these tensions in real operational terms: many shops welcome the move for the long‑term security gain but warn about the
short‑term engineering and vendor coordination burden required to migrate safely.
Action plan for administrators — step‑by‑step
The operational checklist below synthesizes Microsoft’s recommendations, community best practices, and defensive priorities. Treat this as an actionable playbook to prepare for the mid‑2026 default flip.
- Inventory and discovery
- Run Microsoft’s Get‑KerbEncryptionUsage.ps1 and List‑AccountKeys.ps1 to enumerate accounts and endpoints that still request or accept RC4 tickets. Collect results in a central SIEM.
- Prioritize high‑risk accounts
- Focus on service accounts with SPNs and privileged service accounts first. These accounts are the most valuable targets for Kerberoasting. Use gMSAs where possible to remove manual password handling.
- Ensure AES keys are present
- For accounts that lack AES key material, perform a controlled password reset (or rekey) to generate AES128/256 keys. Document and validate each change in a test OU before rolling into production.
- Update Group Policy and registry only in test domains first
- Use the “Network security: Configure encryption types allowed for Kerberos” GPO in non‑production OUs. Validate authentication flows for critical services before making domain‑wide changes.
- Coordinate with vendors and isolate non‑fixable devices
- Request firmware/driver updates from appliance vendors. Where fixing is impossible, isolate devices on segmented networks or proxy authentication through a hardened, supported gateway.
- Harden service account practices
- Enforce long, randomly generated passwords for any remaining manual service accounts, rotate them frequently, and adopt just‑in‑time and least‑privilege practices for privileged workflows.
- Monitoring and tabletop exercises
- Integrate Kerberos‑specific alerts into EDR/SIEM (watch for unusual TGS/AS‑REQ patterns and RC4 usage flags). Run tabletop exercises for ticket‑forging and Kerberoasting detection and response.
- Document exceptions and sunset plans
- Any explicit re‑enablement of RC4 must be logged as a temporary exception with an assigned owner, a rollback plan, and a strict sunset date. Treat exceptions as high‑risk operational debt.
These steps are operationally simple in concept but can be time‑consuming at scale; large enterprises should budget weeks to months for full remediation and validation. Community playbooks and automated scripts shared on forums can accelerate discovery, but vendor testing remains the gating factor for many environments.
Verification, caveats, and claims that still need confirmation
- Microsoft’s timeline is explicit about a mid‑2026 default change for domain controllers on Windows Server 2008 and later; that commitment appears in Microsoft’s official blog and Microsoft Learn guidance. Administrators should validate the exact date and the roll‑out scope against the Windows Server release notes and the Microsoft Security Update Guide as the deadline approaches.
- Public reporting links RC4 and Kerberoasting to several investigations and at least one high‑profile breach (Ascension). While RC4‑related weaknesses materially increase the effectiveness of Kerberoasting, breaches are multi‑vector and attribution to a single technical cause can oversimplify incident narratives. Congressional letters and press coverage cite RC4 as an enabling factor, but forensic reports should be consulted for case‑specific technical timelines. Treat broad claims about causality with cautious nuance.
- The new Kerberos audit fields and diagnostic scripts materially improve operational visibility, but they are not a silver bullet. Detection is necessary but not sufficient; long‑running legacy credentials and misconfigured services will still require deliberate remediation actions. Community test cases show a diversity of edge cases where manual intervention or vendor coordination is unavoidable.
Final analysis: a necessary, overdue fix — but not a cure‑all
Microsoft’s deprecation of RC4 as the default Kerberos enctype is both long overdue and strategically important. Making AES the default flips the default posture for millions of Windows installations away from a known weakness and reduces population‑level exposure to Kerberoasting and similar offline credential cracking attacks. The change is technically sound: it aligns Kerberos encryption defaults with modern cryptographic practice, leverages improved audit telemetry, and provides administrators with the tools to discover and remediate lingering dependencies. However, the policy flip does not erase the operational realities that caused the delay: tens of thousands of third‑party devices and legacy apps, decades of accumulated account artifacts, and the practical difficulties of orchestrating firmware and software updates across a heterogeneous estate. Those are management problems more than cryptographic ones. The security gain from changing a default will only be realized if organizations use the runway to inventory, remediate, and adopt safer identity practices—stronger service account management, rotation, segmentation, and robust detection.
Congressional attention and the public fallout from high‑impact breaches have moved the needle. Microsoft’s change demonstrates how regulatory, commercial, and reputational pressure can accelerate technical fixes that were long resisted for compatibility reasons. For administrators, the time to act is now: use Microsoft’s tools, prioritize SPNs and privileged service accounts, coordinate with vendors, and treat any RC4 re‑enablement as a strictly controlled exception with a defined sunset.
Microsoft’s move closes a glaring gap between cryptographic hygiene and legacy interoperability. It is a welcome and powerful nudge toward safer defaults — but it will deliver real protection only when organizations pair vendor defaults with disciplined operational cleanup and a commitment to modern identity hygiene.
Source: Ars Technica
Microsoft will finally kill obsolete cipher that has wreaked decades of havoc