Microsoft moves to shut down RC4 after decades of security fallout

Key Takeaways

  • Microsoft will disable RC4 by default in Windows domain controllers by mid-2026
  • The cipher’s legacy support has enabled major attacks, including the Ascension breach
  • Enterprises now need to identify lingering RC4 dependencies before the cutoff arrives

Microsoft is finally retiring RC4 from Windows authentication, ending a 26‑year default that has plagued enterprise defenders and fueled some of the most damaging breaches in recent memory. The company’s decision comes after years of industry pressure, a high‑profile hospital attack, and recent criticism from US Senator Ron Wyden, who labeled RC4’s continued default support “gross cybersecurity negligence.”

It’s a long time coming. When Microsoft introduced Active Directory in 2000, RC4 was the only encryption method the system used for administrative authentication. And although the RC4 algorithm was already showing cracks—its design leaked in 1994 and a researcher broke its expected security within days—it still became embedded everywhere from SSL to TLS. That momentum is tough to unwind. Anyone who has maintained large Windows estates knows how sticky legacy defaults can be.

Even after AES became available in Windows Server 2008, Microsoft kept RC4 active as a fallback. That backward compatibility turned into a hacker favorite. Attackers have exploited RC4 weaknesses repeatedly, culminating in the breach of Ascension, a health giant whose disruption affected 140 hospitals and exposed the medical records of 5.6 million patients. While the initial entry often varies, investigators found that the attackers leveraged Kerberoasting—an attack technique known since 2014 that RC4 makes dramatically easier—to escalate privileges and move across the network.

Microsoft now plans to disable RC4 by default across domain controllers running Windows Server 2008 and later. Matthew Palko, a principal program manager at the company, noted that administrators will still be able to re-enable it manually, but only through explicit configuration. That’s a subtle move, but it matters; defaults often shape enterprise behavior more than policy documents do. And here’s the quiet truth: many organizations don’t actually know where RC4 is still lingering.

That’s where the transition gets tricky. Some legacy third‑party systems still rely exclusively on RC4 for authenticating to Windows networks. They aren’t common, but they aren’t always visible either. In many enterprises, those older systems quietly support critical internal workflows. It’s the sort of detail that often sits undisturbed until a change like this forces teams to dig.

To help, Microsoft is releasing new tools, including updated Kerberos Key Distribution Center (KDC) logs that flag both RC4 requests and RC4 responses. The company is also publishing PowerShell scripts that comb through existing security logs to pinpoint where RC4 remains active. It’s not glamorous work, but it’s the kind of operational help admins need. If you’ve ever tried to trace an unexpected authentication path across dozens of systems, you know how tedious that process gets.

Microsoft says it has been chipping away at RC4 usage for more than a decade. Steven Syfuhs, who leads the Windows Authentication team, shared an unusually candid reflection on Bluesky, describing how RC4’s influence reached through more than 20 years of code paths. Killing the cipher wasn’t just about removing it; it required dissecting the logic that determined when it was chosen. A micro‑tangent here: that kind of technical debt is exactly the sort of thing outsiders rarely see, yet it’s what slows down even the best‑resourced engineering teams.

Syfuhs noted that, despite a long list of vulnerabilities requiring what he called “surgical” fixes, RC4 persisted because it had been the default for so long. Deprecating it earlier would have broken too much. Only after Microsoft introduced improvements that heavily favored AES did RC4 usage drop by “orders of magnitude.” Within a year, Syfuhs said, it had fallen to nearly zero—giving the company the confidence to kill it without risking widespread outages.

But the underlying problem wasn’t just the cipher. Kerberoasting leverages how Active Directory implemented authentication using RC4: no cryptographic salt and only a single MD4 hash iteration. That combination is a gift to attackers. MD4 is extremely fast to compute, and without salt, hashes are predictable. Microsoft’s AES‑SHA1 implementation, by contrast, iterates the hashing process and adds enough computational cost to slow cracking by roughly a factor of 1,000. It doesn’t make passwords unbreakable—nothing does—but it changes the economics considerably.

For enterprises, the next phase is largely administrative. Teams need to audit their environments for lingering RC4 usage and map any dependencies. Some organizations have already started this work following the Ascension incident or after reading Wyden’s letter to the Federal Trade Commission, which is referenced in coverage from outlets like Ars and aligns with the pressure Microsoft has been under. Others haven’t. And honestly, some won’t realize RC4 is still active until logs start warning about unsupported requests.

There is a real question here: what happens to those older systems that can’t move off RC4? Some businesses will choose to isolate or upgrade them. Others will flip the switch to keep RC4 alive for a little longer, assuming the risk is manageable. That may be practical, though not ideal. Even so, RC4 authentication will no longer work by default after mid‑2026, and that line in the sand forces a conversation many organizations have avoided.

The bigger takeaway isn’t just that RC4 is retiring. It’s that long‑standing defaults can quietly shape enterprise risk for decades. Microsoft’s move doesn’t magically erase the cipher from the world, but it does shift the burden back to administrators: if RC4 remains in your environment going forward, it’s because you chose to keep it, not because Windows did.