A blocklist is not a deployment plan

Microsoft publishes tested vulnerable driver block rules, and they are the right baseline. Enable them. That part is not in question.

What a published baseline cannot know is which hardware you own. That gap is small to describe and it is where driver programmes lose a quarter.

One question, asked of every driver on the list #

Not "is this driver dangerous", because the list already answered that. The useful question is: is it here, and can you actually stop it?

That produces three answers, and they need three different responses.

Not in your fleet, so nothing to do #

Most of a published list was never in your estate.

Blocking those drivers changes no risk. It still costs a change record, a review, and a slot in somebody's week. Do that across a long list and you have spent a quarter producing a policy that is measurably no safer than the one you started with, which is a difficult outcome to explain and an easy one to arrive at.

This is the largest of the three groups, and recognising that is what makes the work tractable.

Here, and nothing depends on it, so block it #

This is the set worth acting on, and it is far smaller than the list.

Present in the fleet, exploitable, and attached to nothing anyone relies on. Usually the residue of hardware that has been replaced, a peripheral nobody uses any more, or a utility installed once for a purpose long finished.

Straightforward decisions, and there are fewer of them than a first read of the blocklist suggests.

Here, and load bearing, so stage it #

Real hardware, with a vulnerable driver, and a working exploit against it.

Block this one outright and the device may not boot. That is a desk visit rather than a ticket, and at fleet scale it is the kind of incident that ends a driver programme rather than delaying it.

What this case needs is a replacement driver from the vendor, a pilot ring, and a way back. It is a deployment, not a rule. Treating it as a rule is how a well intentioned blocklist rollout becomes an outage.

Which is why the inventory comes first #

None of the three answers is available without knowing what drivers are actually deployed, at which versions, on which machines, and what depends on them.

That is not something a blocklist can supply, and it is not something a gold image tells you either, because modern provisioning means there is no single image to inspect. It has to come from the devices.

Windows stopped trusting cross-signed kernel drivers makes the same point from the other direction: the estates that took that change well were the ones that could answer, on the day, which drivers they had and where they ran.

The same question, asked about tools #

Dual purpose tooling has the identical shape, and people reach for a yes or no answer when the real answer is a location.

PsExec belongs on an administrator's machine. It has no business running on a finance laptop. It is not malware and banning it outright annoys the people who legitimately need it, which is how exceptions start.

So it is rarely a decision about whether, and almost always a decision about where. Restricting a tool to the endpoints that need it costs the people who use it nothing, and removes it from everywhere an attacker would rather find it. That applies to remote access tooling, to debuggers, to scripting hosts, and to most of what turns up on a living off the land list.

Stop asking what is dangerous covers why scope beats absence across the whole estate, not just drivers.

What to do with this #

1. Turn the blocklist on, and check the version on the device is current rather than whatever shipped with the build. It is free and it is the floor.
2. Inventory your kernel mode drivers across the fleet, with a version and an owner against each.
3. Sort them into the three groups. Expect the first group to be most of the list, the second to be small, and the third to be the only one that needs a project.
4. Give the third group a deployment, not a rule. Replacement driver, pilot ring, way back.

The reason this order matters is that steps three and four are impossible without step two, and step two is the one most estates have never done.

That second step is what PoliEze is for. It produces the driver inventory from the fleet itself, with a version against each one, so what you sort into the three groups is what your estate is actually running rather than a list assembled by hand from vendor documentation. The platform covers where that sits in the sequence.

A blocklist tells you what is dangerous. Only an inventory tells you what is yours.