WDAC closes the BYOVD gap that blocklists cannot stop

At a glance

What this is: Expel argues that BYOVD attacks persist because blocklists only stop drivers already known to be malicious, while WDAC changes the default to allow only approved code.

Why it matters: This matters to endpoint, IAM, and platform teams because driver trust is part of privileged access at the kernel boundary, and reactive blocklists leave a standing exposure window.

Context

Bring your own vulnerable driver attacks exploit a control gap, not just a malware problem. If defenders rely on blocklists, they are always waiting for the next bad driver to be identified before they can act, which leaves signed but vulnerable code free to load until detection catches up. That is a governance failure in kernel trust, because signature validity is not the same as security approval.

The identity angle here is indirect but real: driver loading is a privileged act, and once kernel-level code is running it can interfere with higher-value protections, including credential isolation and policy enforcement. For Windows estates, the question is not whether the driver is signed, but whether the system has a deny-by-default model that prevents unapproved privileged code from entering the environment in the first place.

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 does BYOVD create kernel risk even when the driver is signed?

A: A digital signature confirms publisher identity, not safety. If a signed driver contains a vulnerability, it can still be used to execute code at kernel privilege, where it can interfere with endpoint controls. That is why signing alone is an assurance signal, not a trust decision.

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. Audit mode should reveal what would be blocked before enforcement, and enforcement should not depend on manual reaction to each new driver.

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.

Technical breakdown

Why blocklists fail against signed vulnerable drivers

A blocklist is a retrospective control. It can only stop drivers that are already known, named, and distributed into the list, which means any newly found or obscure vulnerable driver remains usable until defenders update coverage. BYOVD attackers benefit from that lag because they do not need a malicious driver, only one that is signed and exploitable enough to abuse. The security model is therefore inverted: defenders try to enumerate badness while attackers search the long tail of trusted but unsafe software.

Practical implication: Treat driver blocklists as supplementary detection, not as the primary control for kernel trust.

How WDAC changes driver and application trust

Windows Defender Application Control enforces an allowlist model at the operating system level. Instead of asking whether code is on a bad list, it asks whether the driver, application, script, or DLL is explicitly approved by policy. That shifts control from reputation to authorization, which is much harder for an attacker to bypass when the target is kernel loading. It also makes policy governance central: the environment must know which code is permitted, why it is permitted, and how exceptions are reviewed.

Practical implication: Use allowlisted policy as the decision point for privileged code, not post-load cleanup.

Why HVCI matters for BYOVD containment

Hypervisor-Protected Code Integrity moves integrity enforcement into a protected layer that a vulnerable kernel driver cannot easily tamper with. That matters because BYOVD is most dangerous when loaded code can disable or subvert the very control meant to stop it. HVCI hardens that boundary by placing code integrity checks outside direct kernel control, making enforcement more resilient after a driver is loaded. In practice, WDAC without that isolation can still be undermined by kernel-level manipulation, while HVCI makes the control structurally harder to defeat.

Practical implication: Pair kernel allowlisting with hypervisor-backed integrity so enforcement survives hostile driver activity.

Threat narrative

Attacker objective: The attacker wants reliable kernel-level control that lets vulnerable code run despite blocklists and thereby weakens endpoint security controls.

1. Initial access occurs when the attacker finds a legitimately signed but vulnerable driver that is not yet on the blocklist.
2. The vulnerable driver is loaded to gain kernel-level execution and bypass controls that assume signed code is safe.
3. Kernel execution enables policy evasion or security impairment, allowing the attacker to operate beneath endpoint defenses.
4. Impact follows in the form of disabled protections, weakened endpoint visibility, and expanded room for follow-on compromise.

Breaches seen in the wild

• NVIDIA code-signing certificates stolen 2022: Lapsus$ leaked two NVIDIA code-signing certificates; Windows still trusted them for drivers and attackers signed Cobalt Strike and Mimikatz with them.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Deny by default is the named concept that changes the game: only explicitly approved drivers and applications should be allowed to load. That shift matters because privilege at the kernel layer is not comparable to ordinary endpoint execution. Once a driver can execute below the operating system’s normal controls, recovery depends on how well trust was governed before load time, not on how fast the blocklist was updated.

Kernel trust now intersects directly with identity and access governance. Driver execution is a privileged action, and privileged actions need lifecycle rules, approval paths, and revocation logic just like administrative access. The article’s real lesson is that endpoint enforcement and identity governance meet at the point where code gains control over the machine’s security boundary.

HVCI turns integrity into an isolation problem rather than a patching problem. If enforcement can be reached and altered by the same kernel code it is meant to govern, the control is too close to the threat. Moving code integrity checks into a hypervisor-protected layer is the structural response. Practitioners should view that as resilience engineering for the enforcement plane itself.

Ring-based rollout is the only realistic way to operationalise deny by default at scale. The article’s deployment path is important because a technically correct control that breaks business workflows will not survive. Audit mode, pilot OUs, and exception governance are not administrative extras. They are the mechanism that lets organisations change the trust model without creating an outage-driven rollback.

What this signals

Deny by default is the operating model that BYOVD defense actually requires. A signed-but-vulnerable driver is still privileged code, so the control problem is not reputation but authorization. Teams should expect blocklists to remain useful only as a backstop, while the real policy decision moves to allowlisting and exception governance.

Kernel integrity needs isolation, not just detection. Once a vulnerable driver reaches the kernel, the defender has already lost the easy layer of control. HVCI matters because it separates enforcement from the code it is meant to constrain, which is a more durable model for endpoint resilience.

Driver trust should be managed like privileged access. The rollout pattern in the article aligns with how strong IAM programmes change state: audit first, enforce in rings, and govern exceptions explicitly. That makes driver policy a lifecycle control rather than a one-time hardening task.

For practitioners

• 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.
• Keep the native blocklist as a secondary control Leave the vulnerable driver blocklist enabled for known bad drivers, but do not depend on it as the decision point for whether kernel code is allowed to load.
• Use exception workflows for legitimate third-party drivers Route new driver requests through an approval process that records why the driver is needed, who approved it, and when the exception expires.

Key takeaways

• BYOVD succeeds because blocklists are retrospective and cannot stop every newly discovered signed driver that attackers can weaponise.
• The control shift is from detecting known bad drivers to allowing only approved code to load, with HVCI protecting enforcement at the kernel boundary.
• Teams that want durable BYOVD resistance need policy governance, audit-mode rollout, and exception handling, not just a bigger deny list.

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 Log: A Windows audit trail that records application and driver loading decisions made by code integrity policy. Security teams use it to see what would have been blocked, validate allowlists, and tune enforcement before moving from audit mode to production blocking.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.