Microsoft says it will finally remove the decades-old RC4 cipher after a long, incremental deprecation effort that stretched over the past decade. Steve Syfuhs, who leads Microsoft’s Windows Authentication team, explained the technical and codebase complexity behind the delay and the series of surgical fixes required as flaws were discovered. Microsoft introduced measures that shifted traffic toward AES, and observed RC4 usage fall by orders of magnitude within a year, which helped make full removal feasible without widespread breakage. Security experts warn Windows administrators to audit for lingering RC4 and weak Kerberos password handling to reduce exposure to attack techniques such as Kerberoasting.
Key Takeaways
- RC4 has been present as a shipped option in operating systems for roughly 25 years, and its configuration rules accumulated across about 20 years of code changes.
- Microsoft’s Windows Authentication team repeatedly patched critical RC4 vulnerabilities with targeted fixes rather than an immediate cutoff, citing compatibility risk.
- Efforts to favor AES over RC4 produced “minor improvements” that drove RC4 usage down by orders of magnitude; within a year usage fell to virtually nil.
- Microsoft considered deprecating RC4 this year but postponed after discovering additional vulnerabilities that required further remediation.
- Kerberoasting attacks exploit Active Directory’s handling of service account hashes (unsalted, single-round MD4), making those hashes far easier to crack than iterated, salted schemes.
- Microsoft’s AES-SHA1 implementation uses salt and multiple iterations; combined measures increase cracking cost by roughly 1,000× versus unsalted MD4-based hashes.
- Windows administrators should audit domain controllers and service accounts for RC4 usage and weak hash configurations to reduce immediate risk.
Background
RC4 emerged in the 1990s as a fast stream cipher and was widely adopted because it was simple, performant, and embedded across client and server platforms. For much of the following 25 years it was the default or an available option in many networking and authentication stacks, so it accumulated deep integration into operating systems and third-party software. Over time researchers disclosed multiple exploitable weaknesses in RC4 that made it unsuitable for modern threat models; mitigating those issues often required careful, targeted code changes rather than wholesale removal to avoid breaking dependent systems.
The interplay between long-term defaults, backward-compatibility rules, and cross-component selection logic complicated deprecation. As Microsoft’s Windows Authentication team described, the challenge was not merely that RC4 existed in code, but how selection rules spanning two decades decided when it would be used. That history forced a phased approach—patch known weaknesses, nudge usage toward stronger algorithms, and only then eliminate the legacy option once telemetry showed negligible active use.
Main Event
Microsoft has been quietly reducing RC4 usage for years and recently announced a plan to remove the cipher outright now that telemetry and compatibility testing indicate the risk of breakage is low. Team lead Steve Syfuhs noted that the company repeatedly found new edge-case vulnerabilities that required more fixes, and that initial plans to deprecate earlier were delayed for that reason. Instead, Microsoft applied incremental changes that favored AES-based algorithms, which produced a rapid decline in RC4 negotiation across real-world deployments.
The decision to remove RC4 follows observation that, after Microsoft’s changes, RC4 negotiation dropped by orders of magnitude and fell to ‘basically nil’ within roughly a year. That telemetry gave engineers the confidence to proceed with an outright ban because it would not suddenly interrupt large numbers of customers. Microsoft’s approach combined compatibility testing, surgical vulnerability patches, and protocol preference changes to migrate traffic toward modern ciphers.
The company also highlighted related authentication risks that are distinct from RC4’s algorithmic weaknesses. In Active Directory’s Kerberos-related flows, service-ticket handling and certain legacy hash usages leave organizations vulnerable to Kerberoasting: attackers can request service tickets and attempt offline cracking because some service-account-derived keys use unsalted, single-round MD4-style hashing. Microsoft contrasts that with AES-SHA1-based protections that apply salt and multiple hash iterations to substantially increase cracking cost.
Analysis & Implications
Removing RC4 reduces the attack surface tied to a cipher with well-documented statistical weaknesses, but the practical security gain depends on endpoint and server configuration across the ecosystem. Many modern clients and servers already prefer AES, so the direct benefit to typical deployments may be incremental. The larger win is symbolic and technical: eliminating a legacy choice prevents regressions and removes a fallback that attackers could otherwise exploit in heterogeneous environments.
Kerberoasting illustrates why cipher deprecation alone is not a panacea. The primary weakness in that attack chain is the use of unsalted, low-iteration hash material (single-round MD4) for certain service-account keys in some AD configurations. Even after RC4 is removed, organizations that allow or retain weak service-account password handling remain vulnerable to offline cracking. Addressing Kerberoasting therefore demands both algorithm policy changes and better account hygiene: longer passwords, unique service account credentials, and iterated key derivation functions.
Operationally, Microsoft’s phased approach—telemetry-driven removal after usage fell to near zero—minimizes customer disruption but leaves a narrow window for system administrators to react. Enterprises with legacy appliances, embedded devices, or custom software stacks that still negotiate RC4 should prioritize configuration updates and vendor engagement. Regulators and auditors may start treating continued RC4 availability as a control weakness in security assessments.
Comparison & Data
| Hash / Cipher | Salt | Iterations | Relative cracking effort |
|---|---|---|---|
| MD4 (AD legacy/NT hash) | No | 1 | Baseline (1×) |
| AES-SHA1 (Microsoft iterated) | Yes | Many (iterated) | ~1,000× |
The table summarizes the crucial operational differences noted by Microsoft: MD4-style, unsalted single-round hashes require minimal resources to brute-force, while salted, iterated AES-SHA1-derived keys make cracking roughly 1,000 times more costly. That multiplicative gap can change an offline attack from feasible for commodity hardware to costly and time-consuming enough to deter opportunistic attackers.
Reactions & Quotes
“The problem though is that it’s hard to kill off a cryptographic algorithm that is present in every OS that’s shipped for the last 25 years and was the default algorithm for so long,”
Steve Syfuhs — Microsoft Windows Authentication team (Bluesky, as reported)
Security practitioners have welcomed the move as necessary but warned that removal of RC4 will not mitigate other legacy weaknesses unless administrators also remediate weak service-account hashes and update configuration across devices.
Independent security researcher (paraphrased reaction)
Unconfirmed
- Exact rollout timetable for RC4 removal across all supported Windows versions and cumulative updates has not been published publicly at the time of reporting.
- The degree to which third-party embedded devices and legacy enterprise appliances still negotiate RC4 in the wild has not been exhaustively measured; pockets of use may persist.
Bottom Line
Microsoft’s plan to remove RC4 is a long-overdue but sensible step backed by a cautious, telemetry-driven process. Because RC4 negotiation dropped to near-zero after Microsoft favored AES, the company judged that removal would not cause mass compatibility failures. For defenders, the action shrinks an avoidable attack surface, but it is not a substitute for addressing weak password hashing practices and legacy account configurations that enable Kerberoasting.
Administrators should treat this announcement as a prompt: inventory services and devices for RC4 and legacy Kerberos/NT hash behavior, rotate and harden service-account credentials, and apply Microsoft’s recommended configuration updates. Doing so will convert the theoretical reduction in risk from RC4 removal into a concrete, sustained security improvement.