Windows Kernel Driver Signing: Security Benefits, BYOVD Gaps and the Cost to PC Owners

The argument in brief​

XDA's case is simple. Kernel-mode drivers run at the highest privilege level, so Windows checks their digital signatures before loading them. That check blocks a whole class of rootkits and kernel malware. It also means Microsoft, not the person who owns the PC, decides which low-level code gets to run on it.

The piece makes several claims:

• Security benefit: Malware without a stolen or leaked certificate has a much harder time getting into the kernel on patched 64-bit Windows than it did in the Windows XP days.
• Anti-cheat benefit: Kernel anti-cheat products such as Easy Anti-Cheat, FACEIT and Riot Vanguard rely on cheat developers not being able to load their own kernel drivers whenever they like.
• Known workaround: Attackers and cheat makers use "Bring Your Own Vulnerable Driver" (BYOVD). They load a legitimately signed driver that has a flaw, then exploit the flaw.
• Consumer cost: Hobbyists, open-source projects and owners of old hardware get stuck. They either pay for the signing process or switch off protections to load their own code.

That tension between security and control is real. XDA mentions both Vista and Windows 10 version 1607, but its opening description can blur two requirements that changed at different times.

What Vista required and Windows 10 changed​

Signature enforcement for kernel drivers began with 64-bit Windows Vista, not Windows 11. What changed later is who has to sign.

Microsoft's current Driver Signing Policy says that "starting with Windows 10, version 1607, Windows will not load any new kernel-mode drivers which are not signed by the Dev Portal." The same documentation notes that an EV code signing certificate is required to establish a dashboard account.

Before 1607, a vendor could sign a driver with its own Authenticode certificate plus Microsoft's cross-certificate. Under the new policy, Microsoft's own signing portal became the required route for new drivers.

That rule also has more exceptions than headlines usually admit. Microsoft's documentation says cross-signed drivers are still permitted if the PC was upgraded from an earlier release of Windows to Windows 10, version 1607; Secure Boot is off in the BIOS; or the driver was signed with an end-entity certificate issued prior to July 29th 2015 that chains to a supported cross-signed CA. Microsoft also made room for boot drivers: to prevent systems from failing to boot properly, boot drivers will not be blocked, but they will be removed by the Program Compatibility Assistant.

SecurityWeek's coverage of the rollout at the time put it more bluntly. Code Integrity would enforce the policy "only on new installations with Secure Boot on." Microsoft said the delay between announcing and enforcing the policy was "due to technical and ecosystem readiness issues."

Section summary: Signature checks for 64-bit kernel drivers date back to Vista. Since Windows 10 version 1607, new kernel drivers have needed Microsoft's signature on clean installs with Secure Boot on. Windows 11 inherited the policy; it didn't invent it.

Signed isn't the same as safe​

XDA says a stolen certificate is "running on borrowed time." That's true, but the legacy exceptions above have given attackers a lot of time.

In 2023, Cisco Talos reported that threat actors were taking advantage of a Windows policy loophole that allows the signing and loading of cross-signed kernel mode drivers with signature timestamp prior to July 29, 2015, using multiple open-source tools that alter the signing date of kernel mode drivers to load malicious and unverified drivers signed with expired certificates. Talos also said it had observed over a dozen code signing certificates with keys and passwords contained in a PFX file hosted on GitHub being used alongside those tools. It even identified an instance of one of these open-source tools being used to re-sign cracked drivers to bypass digital rights management.

The lesson for Windows admins: a signature proves who signed a driver and that it hasn't changed since. It says nothing about whether the driver is well written, and the compatibility exceptions can be abused. That's why BYOVD works, and why Microsoft maintains a separate vulnerable-driver blocklist alongside signature enforcement. Microsoft itself warns that the blocklist won't catch everything.

Is the lock-in claim fair?​

This is where XDA's argument is strongest, and independent analysis backs it up.

Windows researcher Geoff Chappell has written that if you write a kernel-mode driver and want it to load on Windows 10 in its 1607 release or later in ordinary configurations, especially with Secure Boot enabled, then (barring the cross-signing back doors) you must send your driver to Microsoft to get a Microsoft signature — even for loading only on your own computers.

That last clause is the heart of the ownership complaint. You can't sign a driver for your own hardware on your own machine and have it load normally.

The escape hatches exist, but they cost something. Chappell notes that a driver signed with an in-house test certificate shouldn't load on any 64-bit Windows back to Vista except if Windows is started with a boot option such as testsigning or under a kernel-mode debugger, both of which are disabled by Secure Boot. To run your own kernel code without Microsoft's signature, you effectively have to switch off Secure Boot first. That's not a switch most people should be flipping.

To be fair, Chappell doesn't treat this as a scandal. He adds, "please don't take me as objecting to the very idea of needing Microsoft's permission." Many security engineers see it the same way: centralizing trust is the price of keeping the kernel clean for the hundreds of millions of people who will never write a driver.

The practical options​

If you hit a signature wall, here are the realistic paths, from safest to least safe:

1. Get a properly signed driver. For a device showing Device Manager error Code 52, Microsoft's recommended fix is to find and install a digitally signed driver. Check the vendor's site, Windows Update, and chipset or OEM support pages.
2. Check whether the vendor signed through the Dev Center. Microsoft's documentation says for testing on Windows 10 client only systems, you can submit your drivers for attestation signing, which does not require HLK testing, while production drivers normally go through the full HLK test logs. Attestation lowers the bar for vendors, but it still needs a dashboard account and an EV certificate.
3. Use test mode, but only on a dedicated development or lab machine. Test signing needs administrator rights and a restart, puts a "Test Mode" watermark on the desktop, and in practice means turning off Secure Boot. Don't do this on your daily driver.
4. Use the one-time "Disable driver signature enforcement" startup option. XDA notes that this lasts until the next reboot. It's fine for diagnosis, but it isn't a permanent fix for a peripheral you use every day.
5. Retire the hardware. XDA points out that old XP-era peripherals with unsigned drivers are often stuck. Sometimes the honest answer is that the device has reached end of life.

The Linux comparison​

XDA says Linux distributions can enforce kernel module signing, especially with Secure Boot, but the user can always recompile the kernel or remove the checks. That openness is why kernel-level anti-cheat can't simply be ported over. It's a fair structural point: the more root can do, the less any client-side defense can promise.

XDA also brings up examples such as the WinRing0 driver behind fan-control and RGB tools being flagged by Microsoft Defender, and it quotes RGB software developers speaking to The Verge about the cost of building their own drivers. Those examples show how the burden falls hardest on small open-source projects. They're XDA's reporting, though, not something Microsoft's signing documentation itself shows.

The verdict​

XDA's headline oxymoron holds up. Kernel signing is a real barrier against unsigned and tampered drivers, and the 1607 change made it stricter by putting Microsoft's own portal at the center. But its effectiveness has limits: signed-but-vulnerable drivers and the pre-2015 cross-signing loophole show that a signature is a statement of identity, not of quality. The ownership complaint is also valid. On an ordinary Secure Boot machine, even a driver meant only for your own PC needs Microsoft's signature.

For most Windows 11 users, the trade is worth it. For tinkerers, small open-source developers and anyone with a drawer of legacy hardware, it's a toll booth they never asked for. Which side you land on probably depends on whether you've ever tried to write a driver yourself.

Correction (September 27, 2026): We clarified that XDA's article does discuss Vista-era driver signing. Our earlier introduction implied it had overlooked that history; the actual distinction is between requiring a valid signature and the later Microsoft signing route for new kernel drivers.