A critical Windows security fix puts legacy hardware on borrowed time

Microsoft is finally blocking a long-since retired program that it said led to “abuse and credential theft,” yet remained widely trusted for years. Beginning in April, Redmond will remove trust for kernel drivers that haven’t been vetted through its Windows Hardware Compatibility Program (WHCP). The company is specifically targeting kernel drivers signed by the now defunct cross-signed root program . But while this closes a security hole, Microsoft acknowledges that it could impact some legacy applications and use cases. To balance security with compatibility, the company will initially roll out the policy in “evaluation mode” with its April 2026 Windows 11 and Server update. It will also provide some leeway for older, widely-used and reputable drivers, and admins in certain situations will have the ability to override the new policy altogether. “Essentially, Microsoft is closing a 20-year-old critical security hole in its OS,” said David Shipley of Beauceron Security. “Device drivers get to touch the OS kernel and can abuse that supreme-level access to do fun things like disable anti-virus and endpoint monitoring tools .” Program put platforms at risk Microsoft introduced the cross-signed root program in the early 2000s to give driver providers Windows-trusted code signing certificates with, it said, “varying degrees of partner vetting.” But it offered zero assurances around the security and compatibility of that kernel code. The program was administered by third parties who stored private keys associated with the certificates, which, Microsoft says, “led to abuse and credential theft that put our customers and their platforms at risk.” As a result, the program was deprecated in 2021, and all certificates have since expired. However, third-party drivers signed by the program are still “broadly trusted,” Microsoft says. The new kernel trust policy will apply to Windows 11 24H2, 25H2, 26H1, and Windows Server 2025, and all future versions will enforce it, because, Peter Waxman, a group program manager at Microsoft, writes in a blog post , “drivers are a critical part of the Windows ecosystem, and ensuring their integrity is essential to providing a secure and trustworthy environment.” However, in its initial evaluation mode, Microsoft will monitor and audit driver loads to test for compatibility issues should cross-signed drivers be blocked. Systems will remain in evaluation mode until they meet specific runtime (100 hours) and boot-start (2-3 restarts) scenarios. If all drivers loaded during the evaluation period are trusted, the policy activates, but if any cross-signed drivers are audited that would not pass the new kernel trust policy, the system remains in evaluation mode until those drivers are no longer audited. Once activated, the kernel trust policy will automatically block untrusted drivers. Only drivers that have been passed and signed by WHCP, which scans all driver submissions for malware and tests whether the device is compatible with Windows hardware and operating system, will be loaded by default. Those drivers are then trusted across the Windows ecosystem. Microsoft calls the certification program a “rigorous driver signing process” that helps ensure its partners are “continuously vetted” and comply with its latest security and compliance requirements. Workarounds in certain scenarios Even as it enforces this new policy, Microsoft is taking steps to minimize disruption. The tech giant will maintain an explicit allow list so that the kernel can load old, but “widely-used and reputable drivers” previously vetted through the retired program. This exception list is based on two years of real-world data around enterprise use of older drivers. Further, admins will have the ability to override the policy via Application Control for Business. This can be particularly useful in scenarios where enterprises are loading custom drivers built for internal use. “This gives enterprises the ability to run privately-signed drivers on enrolled systems without degrading security,” Microsoft notes. However, these bypass policies must be granted specific authority in the device’s cryptographic key to ensure it is applicable only to a specific enterprise environment. It’s a win for security — but there are tradeoffs On the whole, this is great news for security, analysts note. “There seems to be no single breach, instance, law, or sudden trigger that is prompting this step,” said Thomas Randall , a research director at Info-Tech Research Group. “Instead, this is part of a long-running cleanup for avoidable security risks.” But, noted Beauceron’s Shipley, with great security comes some “usability or convenience trade-offs.” For instance, disabling device drivers, even those whose certificates have expired, might render highly-customized internet of things (IoT) devices obsolete. This could also impact critical medical equipment like x-ray machines. Microsoft is being smart by baking in the two safety valves during evaluation (the 100 driver loads and three restarts) to make sure “they don’t brick something vital,” said Shipley. Does this add more friction to malware creators? Yes. Is it a silver bullet? No, he said. “ Endpoint detection and response -killing malware is still going to happen, but the blast radius just got smaller, so that’s a win.” What enterprises should keep in mind While Microsoft does extend some exceptions to its new policy, enterprises taking advantage of them shouldn’t consider themselves immune to ultimate driver blockage. “Even those permissible older drivers will be on borrowed time,” Randall said. “We can expect Microsoft to eventually phase those out, too.” The main risk for organizations is that they may be using older drivers without realizing it, he noted. For instance, factories or medical facilities relying on older hardware, specialized equipment, long-running business systems, or internal tools that were built years ago but never fully updated are all at risk. “The device may still work perfectly well, but it may rely on an older driver, and nobody had a strong reason to replace it until now,” said Randall. “If one of those older drivers is not on Microsoft’s allowed list and no replacement exists, a device or application may stop working properly once a machine begins enforcing the new rule.” To prepare for the policy change, Randall advised enterprises to make a list of hardware and software that install Windows drivers, then test machines that are in heavy, day-to-day use, or that serve highly important functions (like emergency medical equipment); ask hardware and software providers whether they have a roadmap for updated drivers; and identify any internal-only drivers that may require company-managed exceptions. Further, “organizations should not assume Microsoft’s exception list will save them, because Microsoft says that list will be limited,” Randall noted.

Go to News Site