WDAC closes the BYOVD gap that blocklists cannot stop

At a glance

What this is: This analysis argues that BYOVD attacks succeed because blocklists are reactive, and that WDAC with HVCI changes Windows from block-known-bad to allow-known-good.

Why it matters: It matters because endpoint and identity teams must treat kernel driver loading as a governed trust decision, not just a malware detection problem, especially where privileged access and credential protection are at stake.

👉 Read Expel’s analysis of BYOVD, WDAC, and Windows driver policy

Context

Bring your own vulnerable driver attacks exploit a governance gap in Windows trust decisions. If defenders rely on blocklists, they are always behind the attacker, because a newly disclosed signed driver can be weaponised before the list catches up. The primary keyword here is WDAC, and the real issue is how organisations decide which drivers are allowed to execute on managed endpoints.

This is not only an endpoint control problem. A loaded vulnerable driver can undermine credential protections, tamper with kernel checks, and open the door to privilege abuse that affects both human and non-human identity security. In practice, BYOVD shows why allowlisting, code integrity, and privileged workstation hardening need to be treated as part of identity governance, not separate technical chores.

Expel’s analysis is a typical example of the pattern rather than an outlier. The same control gap appears anywhere defenders trust signatures, inherited driver lists, or reactive blocklists more than explicit policy enforcement.

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. BYOVD attackers look for obscure signed drivers that are not yet listed, so the security team stays reactive. A deny-by-default policy such as WDAC is more durable because it approves only known-good code paths.

Q: Why do signed vulnerable drivers remain dangerous in Windows environments?

A: A signature proves origin, not safety. A signed driver can still contain exploitable logic, and if it is allowed to load, an attacker can use it to tamper with kernel security checks, disable protections, or gain privilege escalation. That is why trust decisions must be based on explicit approval, not signature alone.

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. If CodeIntegrity logs still show unexpected drivers, the allowlist is too broad or the rollout is incomplete. Measurement should focus on policy coverage, not just malware alerts.

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.

Technical breakdown

Why driver blocklists fail against BYOVD

Bring your own vulnerable driver attacks work because a blocklist only helps after a driver is already known to be dangerous. Attackers search for obscure, legitimately signed drivers that are not yet listed, then use them as a trusted path into kernel execution. Microsoft’s own vulnerable driver blocklist improves coverage, but it remains inherently reactive. The core failure is a negative security model: defenders try to enumerate what must not run instead of defining what is permitted to load.

Practical implication: organisations should stop treating blocklists as the primary control for driver governance and move high-risk Windows fleets toward allowlisting.

How WDAC and App Control for Business change the trust model

Windows Defender Application Control, also called App Control for Business, enforces a deny-by-default policy. Drivers, applications, scripts, and DLLs only load if they match an approved rule based on publisher, certificate, hash, filename, or version. That matters because an unrecognised but signed driver no longer receives trust by default. For BYOVD, the key point is structural: the control does not need to know the next malicious driver in advance, it only needs to know which drivers are approved for this environment.

Practical implication: build a narrow base policy first, then expand only through auditable exception workflows and supplemental policies where they are supported.

Why HVCI makes kernel enforcement durable

Hypervisor-Protected Code Integrity, or HVCI, moves code integrity checks into a hypervisor-protected layer that the kernel driver cannot easily alter. This matters because a vulnerable driver often becomes dangerous only when it can interfere with the operating system’s own security checks. HVCI raises the trust boundary above the compromised kernel, which helps WDAC enforcement survive even after a bad driver is present. In practice, HVCI does not replace WDAC, it reinforces it at the layer BYOVD targets most directly.

Practical implication: enable HVCI on hardware that supports it, especially on privileged-access workstations, administrators' endpoints, and systems with high identity value.

Threat narrative

Attacker objective: The objective is to gain kernel-level control that weakens endpoint defences and creates a reliable path to privileged access or credential theft.

1. Entry begins when an attacker finds a signed but vulnerable driver that is absent from current blocklists and can still be loaded on a target system.
2. Escalation follows when the driver is used to disable or bypass endpoint protections and obtain kernel-level execution on Windows.
3. Impact occurs when the attacker can tamper with security controls, weaken detection, and reach high-value credentials or persist through trusted code paths.

NHI Mgmt Group analysis

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.

WDAC is as much an identity control as an endpoint control. Driver loading is a high-trust authorisation decision, and compromise at that layer can undermine credential protection, privilege boundaries, and detection. When a vulnerable driver can interfere with security checks, the endpoint is no longer just at risk of malware execution, it is at risk of trust collapse. That makes WDAC relevant to IAM and PAM teams that manage privileged endpoints, because the control boundary protects the systems where high-value credentials live.

Kernel hardening changes the practical meaning of least privilege. If privileged workstations can load arbitrary signed drivers, least privilege stops at the user session and never reaches the execution layer. HVCI and code integrity shift that boundary downward into the kernel, where BYOVD operates. The result is a stronger model for Windows fleets that depend on administrative isolation, especially in environments that already use privileged access controls. Practitioners should therefore align endpoint enforcement with identity risk rather than treating it as separate hygiene.

GentleKiller is a named example of driver diversity as the attacker advantage. The framework matters because it demonstrates scale, not novelty: attackers do not need a single famous vulnerable driver, they need access to a large pool of obscure ones. That is why allowlisting beats blocklist expansion over time. The governance implication is clear for security teams, which must manage driver trust as an approved inventory problem rather than a detection backlog.

Named concept: driver trust inversion. This is the shift from blocking known bad code to permitting only known good code, and it is the core strategic response to BYOVD. Once teams accept that signed does not mean safe, they can rebuild endpoint policy around explicit trust decisions. Practitioners should use that concept to frame their rollout, especially when explaining why audit-first deployment is safer than endless reactive blocking.

What this signals

Driver trust inversion is the right lens for BYOVD programmes. Once teams accept that signatures do not equal safety, the operational question becomes which code paths are explicitly allowed, how exceptions are governed, and how quickly audit findings can be turned into enforceable policy. That mindset aligns with zero standing privilege thinking in identity programmes and with the approval-first logic described in the Ultimate Guide to NHIs , Standards.

For identity and privileged access teams, the next step is to connect endpoint hardening to credential protection. A vulnerable driver that can interfere with kernel checks threatens the same trust boundary that protects session tokens, admin credentials, and privileged operations. In that sense, BYOVD is not just a Windows problem, it is a control assurance problem for the systems that hold the most sensitive access paths.

The programme signal is clear: audit-first rollouts, exception governance, and privileged endpoint baselines need to be measured together. Teams that cannot explain why a driver is allowed should assume the trust model is already too loose, especially when code integrity controls are deployed alongside identity and access controls.

For practitioners

• 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.
• Remove legacy driver trust assumptions Disable legacy driver cross-signing grandfathering on supported builds and inventory old or niche drivers that should be replaced before they become an attacker entry point.
• Use exception workflows for legitimate third-party drivers Route new driver requests through a documented approval process with publisher validation, business justification, and rollback plans instead of widening the base policy ad hoc.

Key takeaways

• BYOVD succeeds because blocklists are reactive and attackers can search a vast pool of signed vulnerable drivers faster than defenders can enumerate them.
• WDAC with HVCI shifts Windows to an allow-known-good model that protects driver loading at the kernel layer, where BYOVD actually operates.
• Practical rollout should start in audit mode on privileged endpoints, then move to enforced policies and governed exceptions rather than expanding blocklists indefinitely.

Key terms

• Bring Your Own Vulnerable Driver (BYOVD): A technique where an attacker loads a legitimate but vulnerable signed driver to gain capabilities that normal user-mode malware does not have. The driver becomes an enforcement bypass, letting the attacker perform privileged actions such as process termination, memory manipulation, or defense evasion from kernel space.
• Windows Defender Application Control: Windows Defender Application Control is a Windows code integrity feature that permits only approved drivers, scripts, DLLs, and applications to run. It shifts enforcement from detecting bad software after the fact to allowing only known-good code paths before execution begins.
• Hypervisor-Protected Code Integrity: Hypervisor-Protected Code Integrity is a Windows protection that moves code integrity checks into a hypervisor-protected environment. By placing enforcement above the kernel trust boundary, it makes it harder for a malicious or vulnerable driver to tamper with the security checks that are supposed to block it.
• Code Integrity: Code Integrity is the Windows enforcement layer that validates whether executable code can be loaded or run under a given policy. In practice, it turns signature and trust decisions into runtime gates, so untrusted binaries are blocked before they can join a process context.

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

👉 Expel’s full post covers deployment phases, supporting controls, and the driver trust assumptions that still create exposure.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management. It is designed for practitioners who need to connect identity controls to the broader security decisions that shape risk.