Topic starter
18/08/2026 2:30 pm
TL;DR: Driver blocklists cannot keep pace with bring your own vulnerable driver attacks because they only catch known bad drivers, while The Gentlemen’s GentleKiller framework used obscure signed drivers to evade them, according to Expel. The real control shift is deny-by-default driver and application allowlisting through WDAC, with HVCI hardening kernel enforcement so defenders stop playing whack-a-mole.
Editorial analysis by NHI Mgmt Group, based on content published by Expel: “The feature that stops BYOVD (bring your own vulnerable driver)”.
Key questions
Q: What fails when organisations rely on driver blocklists against BYOVD attacks?
A: Blocklists fail because they only stop drivers that defenders have already identified as malicious or vulnerable.
Q: Why does BYOVD create kernel risk even when the driver is signed?
A: A digital signature confirms publisher identity, not safety.
Q: How do organisations know if WDAC is working as intended?
A: WDAC is working when unapproved code fails to load, CodeIntegrity logs show the expected allow and deny decisions, and exceptions are controlled through policy rather than ad hoc local changes.
Practitioner guidance
- Define a deny-by-default driver policy Approve only the drivers, applications, scripts, and DLLs that the environment actually needs, and treat everything else as blocked unless an exception is reviewed and time-bound.
- Run WDAC in audit mode before enforcement Pilot the policy in a narrow organisational unit, collect CodeIntegrity events, and use the findings to build the approved software and driver baseline before switching to enforced mode.
- Enable HVCI on capable systems Turn on Hypervisor-Protected Code Integrity where hardware and operating system support it so kernel integrity checks cannot be altered by a loaded vulnerable driver.
Bottom line: BYOVD succeeds because blocklists are retrospective and cannot stop every newly discovered signed driver that attackers can weaponise.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:17 pm
Blocklists are a lagging governance control, not a kernel safety model. The article shows that BYOVD succeeds because defenders are trying to catalogue bad drivers after the fact. That is not a durable trust model for privileged code, especially where the attacker only needs one signed driver that is not yet listed. Practitioners should read this as a boundary problem, not a tuning problem.
A question worth separating out:
Q: Should teams prioritise WDAC or HVCI first in BYOVD defence?
A: If the goal is to stop unapproved kernel code from loading, WDAC is the primary policy control. If the goal is to preserve enforcement after a risky driver appears, HVCI adds the isolation layer that makes tampering harder. In mature environments, they should be treated as complementary, not competing, controls.
👉 Read our full editorial: WDAC closes the BYOVD gap that blocklists cannot stop