Should teams prioritise WDAC or HVCI first in BYOVD defence?

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.

Why the first decision is policy coverage, not hardening depth

BYOVD defence starts with whether the platform will permit an untrusted driver to load at all. WDAC sits at the policy boundary and is the stronger first move when the objective is to stop unknown or unapproved kernel code before it executes. That matters because once a malicious or vulnerable driver is accepted, the attacker has already crossed into a high-trust execution path.

HVCI is different. It does not replace driver allowlisting, it strengthens the runtime environment so that kernel tampering becomes harder after a risky driver is present. In practice, the sequencing question is less about choosing one forever and more about deciding which control closes the most important gap in your current estate first.

NVIDIA code-signing certificates stolen 2022 is a useful reminder that trust in signed code can be abused even when the artefact appears legitimate.

What each control contributes to BYOVD defence

WDAC is the preventative policy layer. It constrains which binaries, drivers, and signing trust paths are allowed to execute, so it is the right control when the main problem is unauthorized kernel code loading. For BYOVD, that means shrinking the driver trust set, tightening signer trust, and reducing the number of paths an attacker can use to introduce a vulnerable driver.

HVCI is the enforcement and isolation layer. It helps protect code integrity by using virtualization-based protections to make kernel memory tampering and certain forms of post-load manipulation more difficult. That makes it especially valuable when you assume some risky software may still reach the endpoint and you need stronger resistance to abuse after load.

Used together, the controls address different parts of the same failure chain. WDAC reduces what can enter the kernel attack surface; HVCI raises the cost of exploiting what is already there. Teams that treat them as substitutes usually end up with a policy gap on one side or a resilience gap on the other.

CIS Controls v8 provides a practical control baseline for hardening, asset control, and malware defence that supports both driver governance and endpoint resilience.

How to choose the order in a real rollout

If your estate still allows broad driver trust, start with WDAC because it attacks the root issue: preventing unapproved kernel code from loading in the first place. If you already have a reasonably tight driver policy but need stronger protection against manipulation, HVCI becomes the better next step because it improves resistance after policy enforcement has done its job.

The rollout sequence also depends on operational tolerance. WDAC can expose more compatibility issues because it is a sharper policy gate, so teams often need inventory, testing, and exception handling before broad enforcement. HVCI tends to be a stronger fit when the estate can already support modern virtualization-based protections and the goal is to raise the bar without changing allowlisting logic.

For threat analysis and defensive mapping, MITRE D3FEND helps frame these controls as complementary countermeasures against code-loading and kernel-manipulation techniques.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-5 — Account Management	Driver governance and endpoint hardening depend on controlling trusted software and attack surface.
Recommendation — Use CIS-5 to restrict trusted software and reduce unnecessary driver exposure.
NIST SP 800-53 Rev 5	CM-7 — Least Functionality	BYOVD defence benefits from limiting what kernel code is allowed to run.
	SI-3 — Malicious Code Protection	Driver loading is a malware delivery path that requires preventive controls.
	SI-7 — Software, Firmware, and Information Integrity	HVCI aligns with integrity enforcement against kernel tampering and code modification.
Recommendation — Apply CM-7 to prohibit unnecessary drivers and other kernel functionality. Use SI-3 to block or detect malicious and vulnerable driver execution. Use SI-7 to preserve kernel code integrity after a driver is loaded.
NIST Zero Trust (SP 800-207)	AC-? — Zero Trust Architecture	BYOVD defence follows a verify-explicitly approach that limits trust in loaded code.
Recommendation — Apply zero trust principles to deny implicit trust to kernel drivers.

Practitioner Guidance

What to prioritise: Prioritise WDAC when the gap is untrusted driver admission, and prioritise HVCI when the gap is post-load tampering resistance. If you can only fund one first, choose the one that closes the larger live exposure in your environment.

What to verify: Check whether your current policy actually blocks unsigned, weakly trusted, or undesired drivers, and confirm whether HVCI can be enabled without breaking critical hardware, virtualization, or legacy driver dependencies.

Common mistake: Do not treat HVCI as a substitute for driver allowlisting. A protected kernel that still admits broad trust is still an exposed kernel.

Practitioner takeaway: In BYOVD defence, WDAC is usually the first control to tighten admission, while HVCI is the follow-on control that makes successful abuse harder after a risky driver appears.