Windows' blocked driver list is 1,702 hashes

Windows has been blocking vulnerable drivers for years and almost nobody has looked inside that list. We downloaded it this morning and counted it: 1,713 block rules, of which 1,702 identify the file by its hash.

Four days ago we wrote here that memory integrity turns itself on on new machines and on a good part of the estate. This is the uncomfortable sequel to that post. Turning it on is right —we insist that you do—, but it is worth knowing exactly what you are turning on, because what you are turning on is, for the most part, a list of hashes.

What we downloaded and what we counted

Microsoft publishes the vulnerable driver blocklist as an App Control policy downloadable from aka.ms/VulnerableDriverBlockList. There are four files inside the ZIP; the one that matters is DriverPolicy_Enforced.xml, half a megabyte of XML. We pulled it on 6 October 2026 and counted the elements by hand. These are the figures, and anyone can reproduce them in five minutes:

The policy identifies itself as Microsoft Windows Driver Policy, version 10.0.29545.0. If that number has changed by the time you read this, so much the better: it means it has been updated.

If you want to repeat the count on your own machine, unzip it and count on the XML. Two lines of PowerShell:

$x = [xml](Get-Content .\DriverPolicy_Enforced.xml)
$d = $x.SiPolicy.FileRules.Deny
"Deny: {0} | por hash: {1} | por nombre: {2} | Signer: {3}" -f `
  $d.Count, ($d | ? Hash).Count, ($d | ? FileName).Count, $x.SiPolicy.Signers.Signer.Count

What Microsoft says about its own list

The most honest part of this is not ours: it is Microsoft's, on the very page you download the file from. They run back to back, in a note almost nobody opens:

The third one shut us up for a while. The 1,713 rules we just counted are not the ones on your laptop. The ones on your laptop usually are, by the vendor's own admission, a subset. On cadence Microsoft is precise and deserves quoting in full: "The blocklist is updated quarterly", and also "blocklist updates are delivered through the monthly Windows updates as part of the standard servicing process". So: a full revision each quarter, a trickle each month. The page that publishes the file carried a date of 1 May 2026 on the day we wrote this.

479 samples that load with memory integrity on

There is a public, community-run catalogue of signed drivers that can be abused: LOLDrivers. It is not a vendor bulletin and that is worth stating plainly: it is community-maintained, anyone can contribute, and its fields are annotations, not certifications. That said, it is the best public picture available, and it has one field that changes everything: LoadsDespiteHVCI — loads despite HVCI, that is, despite memory integrity.

We pulled the JSON the same day and counted it the same way as Microsoft's. 702 catalogued drivers, 2,407 samples. The LoadsDespiteHVCI field is filled in on 2,145 of them (262 are unannotated and we left those out of the denominator, which is the honest thing to do). Of those 2,145, 479 are marked as loading anyway: 22.3%. At entry level —not sample level— 230 of the catalogue's 702 drivers have at least one such sample: nearly a third.

The contrast that matters: 45% against 18%

The catalogue separates two families: legitimate but vulnerable drivers (the driver of a diagnostics utility, of an old antivirus, of an overclocking tool) and malicious drivers, written or tampered with on purpose for this. When you split the count by family, this is what comes out:

Nearly one in two samples of drivers built on purpose for this gets past memory integrity, against fewer than one in five of those that merely had a flaw. The difference admits two readings and neither is reassuring. The first: whoever writes the driver knows which protection you have on and optimises against it. The second, more uncomfortable and probably truer: a malicious driver enters this catalogue because somebody saw it working in a real incident; the ones memory integrity stopped generate no incident, get no report and get no entry. If it is the second, the 45% does not measure the attacker's skill: it measures what got as far as being seen.

Whichever reading you take, the number you walk away with is the same and it is a good one: across the catalogue's 2,145 annotated samples, memory integrity stops 1,666. That is 77.7%. An enormous amount for something that ships by default and costs nothing. But 77.7% is a filter, and a filter is not a perimeter.

Why a hash ages and a certificate less so

A hash identifies that file. Change one byte, recompile, re-sign with another bought or stolen certificate, and you have a binary that does exactly the same thing and whose hash is on no list anywhere. That is why 1,702 hash rules age from minute one: they cover the past with excellent precision and the future with none.

This is where we expected to find the counterweight, and we half found it. We went to the 218 signer blocks assuming they would be the solid part —burning a certificate kills everything signed with it, past and future— and counting them turned up something else: only 50 burn a whole publisher. The other 168 are tied to a FileAttrib with a file name and a version range, and of the 156 that declare a maximum version, 79 are pinned to one specific version (of the form MaximumFileVersion="1.12.802.2023"). Translated: bump the version number and the rule no longer reaches you. The mechanism that does not expire exists, and it is used in 50 cases out of 218.

Two bits of small print that change your procedure

If you take only two operational sentences away from this post, make it these two, both from the official documentation:

So what does work?

What a list cannot do by definition is notice that a signed, legitimate driver that loads perfectly is doing something it should not at three in the morning. That does not get blocked: it gets detected, and somebody has to look at it. That is exactly the difference between prevention and managed detection and response, and why we have been saying for a while that having the tool is not having the service.

The four things we would ask to see if this came up in a review, in order of difficulty:

What we are NOT saying

We are not saying turn memory integrity off: quite the opposite. A protection that filters four out of five known samples is worth a great deal and it is free. We are not saying Microsoft is doing this badly either; in fact what it does well is write on its own page what its list does not cover, which is more than many do. And we are not saying a security programme is solved by buying another tool.

What we are saying is smaller and more uncomfortable: if your answer to "what about vulnerable drivers?" is "we have memory integrity", you have just answered with 1,702 ageing hashes and a subset of them at that. It is a good half-answer. The other half has a name and it is not a product: it is somebody watching what loads, and somebody awake when it fires.

Sources and method (all reproducible): our own counts, made on 6 October 2026. The 1,713 <Deny> rules, the 1,702 by hash, the 11 by name and the 218 <Signer> elements come from counting the elements of DriverPolicy_Enforced.xml (policy Microsoft Windows Driver Policy 10.0.29545.0), downloaded from aka.ms/VulnerableDriverBlockList. The verbatim quotes and the quarterly cadence come from Microsoft recommended driver block rules (Microsoft Learn, article date 1 May 2026). The 702 drivers, 2,407 samples and 479 marked LoadsDespiteHVCI come from the public JSON of LOLDrivers, a COMMUNITY catalogue (not a vendor one): its fields are community annotations and the 262 unannotated samples are left out of the denominator. The percentages are ours, computed on those figures.