Windows stopped trusting cross-signed kernel drivers. What broke, and what to do

In April 2026 Windows stopped treating the old cross-signed root program as a general purpose source of trust for kernel drivers. On the affected builds, a driver now loads if it was signed through the Windows Hardware Compatibility Program, or if it appears on an allow list Microsoft maintains. Otherwise it does not load.

If your fleet came through that update without incident, it is worth understanding why, because the estates that felt nothing and the estates that lost a peripheral fleet differ in one specific way.

What actually changed #

The change applies to Windows 11 24H2, 25H2 and 26H1, and to Windows Server 2025, and to versions after them. Older builds are not covered, which is its own problem: a mixed estate is now running two different sets of kernel trust rules, and the machines that are fine today are the ones that will surprise you at their next feature update.

The framing that matters is that this was not a new rule so much as the end of an old exception. The cross-signed program was deprecated in 2021 and its certificates have since expired. April 2026 is when Windows stopped honouring signatures from a programme that had already been shut for five years.

Microsoft's own description of the intent is that the default expectation becomes simple, which is that drivers should be signed through WHCP or explicitly permitted.

Who this hits, and it is not who people assume #

Mainstream hardware was never the exposure. Anything current from a major vendor has been going through WHCP for years, which is why a modern, well managed fleet can take this change and notice nothing at all.

The exposure sits in four places, and they are the four places nobody has an inventory of.

Old peripherals that still work, and whose vendor stopped shipping updates long before the deprecation. Label printers, scanners, card readers, laboratory and clinical equipment, industrial controllers. The hardware is fine. The driver is from 2016.

Internal and custom drivers, written by somebody who has left, for a system that still matters.

Small vendors and appliances, where the driver ships inside a larger product and nobody thinks of it as a driver at all. Backup agents, storage controllers, virtualisation add ons, licensing dongles.

Software with a kernel component that is not really about hardware, which is a longer list than most teams expect.

The allow list is a bridge, not a destination #

Microsoft is maintaining an explicit allow list of reputable, widely used drivers that came through the old programme, so that a limited set of legitimate legacy hardware keeps working.

Read that sentence carefully before relying on it. It is limited, it is aimed at drivers that are both reputable and widely used, and it exists to cover a transition. A driver that is essential to you but rare in the world is not the kind of driver an allow list like this is designed to carry. If your continuity plan is that somebody else's list will keep containing your driver, you do not have a plan, you have a hope with a timer on it.

The path for drivers you genuinely cannot replace #

This is the part worth knowing, because Microsoft names it directly. Enterprises with unavoidable custom or internal drivers can authorise those specific drivers through an App Control for Business policy, rather than weakening the machine's overall posture.

That is a meaningfully different move from the alternatives. You are not turning enforcement off, and you are not putting the machine back on the old trust model. You are naming one driver, on the machines that need it, as something you have decided to permit, and everything else on those machines is still held to the new bar.

It also puts the decision where it belongs. Somebody has to own the statement "we are running this 2016 driver because the alternative is that the pathology analysers stop", and a policy rule with an owner and a recorded reason is a far better home for that than an undocumented exception nobody can find later.

The trade off is real and should be said plainly. A driver you allow is a driver you are responsible for. If it turns out to carry a vulnerability, you authorised it, and the scope of the damage is the scope you granted. That is an argument for scoping the rule to the machines that need it rather than the whole fleet, not an argument for refusing to make the decision.

Why this matters beyond compatibility #

There is a security dividend here that is easy to miss while you are chasing broken printers.

A large share of the drivers abused in bring your own vulnerable driver attacks are exactly this kind of driver: old, widely distributed, signed under a programme with a lower bar, and still trusted by Windows a decade after anyone maintained them. Removing blanket trust for that whole category attacks the technique at its root rather than one driver at a time. We wrote about that technique and why a denylist struggles to keep pace with it in EDR killers and what they tell you about where enforcement belongs.

It is not a complete answer. A WHCP signed driver can carry a vulnerability too, and some of the drivers on the published block lists were properly signed. What changes is the size of the pool.

What to do about it #

Inventory your kernel mode drivers. Across the fleet, not from the gold image, with a version and a signing type against each one. This is the step everything else depends on, and it is the step most estates cannot currently perform.

This is what PoliEze is for. It produces that inventory from the fleet, with a version against each driver, so what you review is what the estate is actually running rather than something assembled by hand from vendor documentation. The platform covers where that sits in the sequence.

Separate what is broken from what is about to be. Machines on older builds are unaffected today and will inherit the policy when they move. Treat the next feature update as the real deadline.

Chase vendors for WHCP signed builds while there is still time to test them, and treat "the vendor is looking into it" as a finding rather than a status.

Then scope what is left. For each driver with no replacement, decide whether the dependency is real, which machines actually need it, and who owns the exception. Drivers with a known flaw and nothing depending on them are an easy refusal. Drivers with a known flaw that something critical depends on are a scoping exercise, and pretending otherwise is how these projects stall.

The organisations that took this change well were not lucky. They were the ones who could answer, on the day, which drivers they had and where they ran.

Sources #

• Advancing Windows driver security, removing trust for the cross-signed driver program, Microsoft's announcement
• The Windows driver policy, Microsoft support
• Microsoft's April 2026 update ends trust for cross-signed kernel drivers, for the affected build list