Notifications
Clear all
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.
NHIMG editorial — based on content published by Expel: WDAC closes the BYOVD gap that blocklists cannot stop
Questions worth separating out
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 do signed vulnerable drivers remain dangerous in Windows environments?
A: A signature proves origin, not safety.
Q: How do security teams know whether WDAC is actually reducing BYOVD risk?
A: Look for fewer unauthorised driver loads, fewer exception requests for legacy or niche drivers, and clean separation between audit findings and enforced policy outcomes.
Practitioner guidance
- Implement WDAC as the primary driver control Build an allowlist policy that permits only explicitly approved drivers and applications to load on managed Windows endpoints, then use blocklists only as secondary coverage for known bad cases.
- Pilot audit mode before enforcement Start with a pilot organisational unit in audit mode, collect CodeIntegrity events, and use those logs to resolve legitimate driver exceptions before moving to enforced mode.
- Prioritise privileged endpoints for early rollout Apply enforced WDAC and HVCI first to domain controllers, privileged access workstations, and administrator endpoints where kernel compromise would expose the highest-value credentials.
What's in the full article
Expel's full post covers the operational detail this analysis intentionally leaves for the source:
- The step-by-step WDAC policy deployment sequence, including audit-to-enforce rollout mechanics and GPO delivery considerations
- The specific Microsoft-supported controls that complement WDAC, including HVCI, VBS, and the Vulnerable Driver Blocklist
- The practical exception handling model for legitimate third-party drivers that need narrow, auditable approval
- The device classes and Windows versions where legacy driver trust assumptions still create exposure
👉 Read Expel’s analysis of BYOVD, WDAC, and Windows driver policy →
BYOVD and WDAC: why blocklists are no longer enough?
Explore further
18/08/2026 3:17 pm
Blocklists are a lagging control, not a governance model. BYOVD succeeds because the defender is asked to predict the attacker’s next driver choice, which is structurally impossible at internet scale. The better model is explicit approval of trusted code paths, with everything else denied by default. That aligns with the control logic behind allowlisting and with the broader identity principle that trust should be granted by policy, not by assumption. For practitioners, the lesson is to retire reactive driver lists as a primary defence and treat them only as a backstop.
A question worth separating out:
Q: Who is accountable when a vulnerable driver bypasses endpoint protections?
A: Accountability usually sits with the teams that own endpoint policy, privileged workstation standards, and platform security baselines. In regulated environments, that also includes governance teams that approve exceptions and track control effectiveness. The key issue is whether the organisation treated driver loading as a governed trust decision before the incident occurred.
👉 Read our full editorial: WDAC closes the BYOVD gap that blocklists cannot stop
