Microsoft is finally ripping out one of the weakest links in its identity stack, cutting off a legacy cipher that attackers have abused for years to walk straight into corporate networks. The move caps decades of damage from outdated cryptography and signals a broader shift in Windows security, as the company forces customers toward stronger authentication and encryption by design.
Instead of quietly deprecating a single algorithm, Microsoft is using this moment to reset how Windows handles trust, from domain controllers and file shares to Microsoft 365 services and legacy protocols that should have died long ago. I see it as a rare inflection point where a vendor’s crypto housekeeping has direct, immediate consequences for ransomware risk, regulatory scrutiny, and the daily work of IT and security teams.
RC4’s long, messy reign over Windows authentication
At the center of this shift is RC4, short for Rivest Cipher 4, a stream cipher that once powered much of the internet’s “secure” traffic and is now considered dangerously weak. Training material for CompTIA Security+ still introduces RC4 as the first symmetric algorithm to study, spelling out that RC4 stands for Rivest Cipher and noting that some people expand the acronym differently, a reminder of how deeply it is woven into the history of modern cryptography. In Windows, RC4 ended up protecting some of the most sensitive secrets in an enterprise, including administrative credentials used to run entire domains.
Microsoft itself now describes the cipher as obsolete, and its own Windows Server team has framed the deprecation of RC4 for Windows authentication as a necessary response to an evolving threat landscape. In that guidance, the company explicitly calls out RC4 (Rivest Cipher 4) by name and stresses that it is crucial to discontinue using RC4 in favor of stronger algorithms such as AES, especially for domain controllers and other core identity services. The message is blunt: what once passed for acceptable cryptography is now a liability that attackers can and do exploit at scale.
How RC4 and Kerberoasting helped attackers for decades
The damage from keeping RC4 around is not theoretical. In one of the most high profile recent incidents, attackers who broke into Ascension’s systems were able to gain access by using a technique called Kerberoasting, which targets weaknesses in how service tickets are encrypted in Microsoft environments. The method, described in detail in a letter from Sen. Ron Wyden, relies on requesting Kerberos service tickets and then cracking the underlying keys offline, a process made far easier when those tickets are protected with weak ciphers like RC4. In practice, that means a patient attacker can turn a single foothold into domain-wide control without ever triggering obvious alarms.
Security researchers and incident responders have warned for years that RC4 based Kerberos encryption leaves networks open to exactly this kind of Kerberoasting abuse, and Microsoft’s own documentation now acknowledges that the cipher has wreaked decades of havoc in administrative authentication. Reporting on Microsoft’s latest move notes that the company will finally kill the obsolete RC4 option for admin logons after sustained pressure from a prominent US senator, with US Senator Ron Wyden (D) explicitly tying the cipher’s survival to real world breaches. When a single configuration choice can turn Kerberos into an attacker’s best friend, ripping out that choice is not just hygiene, it is incident prevention.
Microsoft finally pulls the plug on the obsolete cipher
After years of half measures and optional hardening, Microsoft is now committing to remove RC4 from its administrative authentication paths altogether. The company has signaled that RC4 based Kerberos encryption will be disabled by default and eventually unsupported, forcing organizations to rely on stronger algorithms such as AES 256 for domain controllers and service accounts. That shift is not just a best practice recommendation, it is a product decision that will break old configurations rather than continue to tolerate them.
Coverage of the change makes clear that this is not happening in a vacuum, but in response to sustained criticism that Microsoft left RC4 enabled long after its weaknesses were widely known. One detailed report notes that Microsoft will finally kill obsolete RC4 for administrative authentication after direct pressure from a prominent US senator who argued that the company’s inaction left networks open to Kerberoasting. In effect, Microsoft is acknowledging that leaving a broken cipher wired into core identity flows is no longer defensible, even if some legacy systems still depend on it.
NTLMv1 and the slow death of legacy authentication
RC4 is not the only relic on the chopping block. Microsoft is also tightening the screws on NTLMv1, the older version of its NTLM authentication protocol that has been abused in relay attacks, credential forwarding, and pass the hash campaigns for years. In support documentation for Windows 11, version 24H2 and Windows Server 2025, the company explains that upcoming changes will remove the NTLMv1 protocol entirely, referencing the Background section that notes NTLMv1 has already been listed under Removed features and functionality. For organizations that still rely on NTLMv1 for legacy applications or devices, that means authentication flows will simply stop working unless they are upgraded.
Security researchers have been blunt about why this is necessary. A detailed analysis of current attack patterns notes that NTLM is dead, but that weaknesses in the protocol and misconfigurations in hybrid infrastructures keep it alive as a target. Ever since that distant 2001, the weaknesses of the NTLM authentication protocol have been clearly exposed, and in the years since attackers have refined ways to capture and replay NTLM handshakes during this process to impersonate users. When Microsoft removes NTLMv1 from modern Windows, it is finally aligning the product with what defenders have known for two decades.
Windows 10’s end of support and the crypto clean break
The timing of these deprecations is not accidental. Windows 10 has now reached the end of support, and Microsoft is using that milestone to draw a line between older, more permissive security defaults and the stricter posture in Windows 11 and Windows Server 2025. Official guidance spells out that Windows 10 support has ended and that devices running it will no longer receive security updates, leaving them increasingly exposed as new vulnerabilities and cryptographic weaknesses are discovered. For enterprises, that means clinging to Windows 10 is not just a patching problem, it is a crypto problem, because the platform will not keep pace with deprecations like RC4 and NTLMv1 removal.
Microsoft’s lifecycle documentation reinforces that message by listing Multiple Microsoft products that are reaching end of support or retirement on October 14, 2025, and explicitly urging Customers to move to supported versions. When a product falls off that list, its cryptographic defaults effectively freeze in time, even as attackers continue to evolve. The company is betting that tying cipher and protocol deprecation to platform upgrades will push laggards over the line, because the alternative is running unsupported software with known weak encryption and no path to remediation.
Legacy TLS, Microsoft 365, and the push to modern encryption
Beyond Windows itself, Microsoft is also tightening encryption in its cloud services, particularly Microsoft 365, where outdated TLS cipher suites have lingered to accommodate old clients and appliances. Administrative guidance circulated to tenant admins explains that Legacy TLS cipher suites will be deprecated in M365 services on October 20, 2025, and that organizations need to ensure their clients support modern TLS configurations before that cutoff. The message is clear: if a device or application can only speak in weak ciphers, it will soon be unable to talk to core productivity services at all.
Security practitioners have been amplifying that warning, noting that Legacy TLS cipher suites will be deprecated in Microsoft 365 services and that this change will land squarely on helpdesk and infrastructure teams. In community discussions, admins highlight that Microsoft 365 will only support modern TLS 1.3 and TLS 1.2 cipher suites, and that older methods will no longer function, a point echoed in a Reddit thread titled Retire Legacy TLS Cipher Suites where users stress that Only TLS 1.3 and 1.2 will be accepted. For organizations still running legacy mail gateways, load balancers, or embedded devices that cannot be upgraded, this is a hard stop that will force either replacement or isolation.
Vendors scramble to keep up with Microsoft Active Directory changes
Microsoft’s decision to harden Active Directory by default is rippling far beyond Redmond, because third party products that integrate with Windows authentication now have to adapt or break. Dell, for example, has published a support note for its Data Protection Advisor product that explicitly asks, Is DPA impacted by a Microsoft Active Directory change deprecating legacy RC4 encryption ciphers and requiring AES 256 encryption by default for the Windows Server platform. In the Symptoms section, Dell describes how environments that still rely on RC4 based authentication can see connection failures once domain controllers are configured to require stronger ciphers.
Other enterprise vendors are going through similar exercises, mapping where their products still depend on RC4, NTLMv1, or outdated TLS suites and publishing remediation steps before customers flip the switch. A knowledge base article from another provider lays out a multi phase Deprecation Plan The eventual removal of older NETENCRYTPALGORITHM values, warning Customers that they must move away from using these algorithms or risk losing compatibility. The pattern is consistent: as Microsoft tightens its defaults, the entire ecosystem of backup tools, monitoring platforms, and line of business applications has to modernize its crypto or risk being stranded.
Why Microsoft is acting now, and why it took so long
From a security perspective, the case for killing RC4 and other legacy ciphers has been clear for years, so the obvious question is why Microsoft is acting decisively only now. Part of the answer lies in the sheer scale of its installed base, where even a small percentage of customers clinging to old protocols translates into thousands of critical systems that could break overnight. Microsoft’s own blog on moving beyond RC4 for Windows authentication acknowledges that organizations face an evolving threat landscape but also that deprecation has to be phased to avoid disrupting essential services. That tension between security urgency and operational reality has kept weak ciphers alive far longer than their cryptographic shelf life.
External pressure has also shifted the calculus. After the Ascension incident, Sen. Ron Wyden used his platform to argue that Microsoft’s failure to disable RC4 and other insecure defaults contributed directly to the scale of the breach, a point underscored in reporting that highlights US Senator Ron Wyden (D) pressing the company over leaving networks open to Kerberoasting. When lawmakers start tying specific cryptographic settings to real world patient harm and calling for regulatory investigations, the cost of inaction rises quickly. Microsoft’s current wave of deprecations looks less like a voluntary cleanup and more like a response to a political and security environment that no longer tolerates “secure by default” as a marketing slogan rather than a product reality.
What enterprises need to do before the cipher lights go out
For enterprises, the practical question is not whether RC4, NTLMv1, and legacy TLS will disappear, but whether they will be ready when they do. The first step is visibility: inventory where RC4 is still used for Kerberos tickets, which applications still negotiate NTLMv1, and which devices can only speak outdated TLS cipher suites. Microsoft’s support notes on upcoming changes to NTLMv1 and its lifecycle announcements for Multiple Microsoft products give a roadmap for when specific protocols and platforms will fall out of support, but it is up to each organization to map those timelines onto its own environment.
Once that map exists, the work becomes a mix of upgrades, configuration changes, and in some cases, retirements. Domain controllers should be configured to prefer AES 256 for Kerberos and to reject RC4, in line with the guidance that Microsoft Active Directory is moving to require AES 256 encryption by default for the Windows Server platform. On the cloud side, admins should test every mail relay, proxy, and client against the announced Legacy TLS cutoff in Microsoft 365, making sure that anything that cannot handle TLS 1.3 or 1.2 is either upgraded or segmented. The organizations that treat these deprecations as an opportunity to simplify and harden their identity and network stacks will be the ones that see the biggest security gains from Microsoft’s long overdue crypto cleanup.
More from MorningOverview