Starting point: a validly signed driver can still be dangerous

Windows requires kernel drivers to carry a trusted signature. This control primarily establishes who published a driver and whether the file was altered. It does not guarantee that every released version remains secure. Legitimate, signed drivers can contain vulnerabilities or functionality that can be used to cross Windows security boundaries.

That matters to Active Directory even though the blocklist is not an AD feature. A compromised client, member server or administrative workstation can quickly become a path to domain identities. On Domain Controllers, the kernel underpins RunAsPPL, EDR sensors and Code Integrity; on PAWs and eligible Tier 0 member systems, it also underpins Credential Guard. If a vulnerable driver weakens this layer, several controls above it lose value at the same time.

The Microsoft Vulnerable Driver Blocklist denies known non-Microsoft drivers when they are vulnerable or malicious, or when they circumvent the Windows security model in an exploitable way. It is therefore a useful baseline, but it is not a complete driver allowlist and it does not imply that every unlisted driver is safe.

Since the Windows 11 2022 Update, the blocklist has been enabled by default on Windows 11. On supported systems it is also enforced when Memory Integrity, or HVCI, Smart App Control or S mode is active; Windows Server 2016 needs separate handling. In a mixed enterprise estate, “Windows 11 already enables this” is not adequate evidence. OS level, security mode, managed App Control policies and the policy that is actually loaded must be assessed together.

Target state: give kernel code its own verifiable trust boundary

A defensible target state combines controls that cover different parts of the driver path:

  1. Supported Windows versions remain current. Monthly Windows updates also deliver blocklist updates; stale builds do not provide a dependable current baseline.
  2. The Microsoft Vulnerable Driver Blocklist is effective on clients, member servers, PAWs and Domain Controllers. Evidence comes from the active Code Integrity configuration and central events, not only a UI toggle.
  3. HVCI is the preferred enforcement model on compatible hardware. Where Memory Integrity is not yet compatible, the blocklist is enforced through a controlled App Control for Business policy.
  4. The current recommended driver blocklist is maintained as a separate App Control policy where stronger assurance is required. It moves from audit to enforcement only after audit findings have been resolved.
  5. The ASR rule for abused vulnerable signed drivers complements the blocklist. It prevents a process from writing an affected driver to disk. By itself, it does not stop an existing driver from loading.
  6. Drivers have owners and a lifecycle. Hardware agents, backup filters, security products, RMM components, VPN, storage and print drivers are tracked with their version, vendor, purpose and update path.
  7. Exceptions do not replace updates. A blocked legitimate driver is upgraded, removed or replaced with a supported product. Allowing a vulnerable version is a narrowly time-boxed emergency state.
  8. Recovery is tested before enforcement. Out-of-band access, the recovery environment, BitLocker recovery and the last-known-good policy are available for boot failures.

The objective is not to block every driver deviation immediately. It is to prevent known-risk kernel code from loading silently without allowing a new block rule to take a business-critical server down by surprise.

Implementation: clean up the driver estate, then enforce in rings

1) Inventory device classes and their enforcement path

Separate at least Windows 11 clients, older clients, PAWs, member servers, Domain Controllers, virtualization hosts and systems with specialist hardware. The same driver may be irrelevant on a standard laptop but boot-critical on a storage server. Record more than file names: capture device class, vendor, driver version, dependent software, restart window and technical owner.

Run the following read-only query from an elevated PowerShell session. It provides an initial local view of signed Plug and Play drivers, HVCI and relevant Code Integrity events:

Set-StrictMode -Version Latest

$deviceGuard = Get-CimInstance `
  -Namespace 'root\Microsoft\Windows\DeviceGuard' `
  -ClassName 'Win32_DeviceGuard' `
  -ErrorAction Stop

$blocklistPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config'
$blocklistValue = Get-ItemProperty `
  -LiteralPath $blocklistPath `
  -Name 'VulnerableDriverBlocklistEnable' `
  -ErrorAction SilentlyContinue

[pscustomobject]@{
  ComputerName              = [Environment]::MachineName
  VbsStatus                 = $deviceGuard.VirtualizationBasedSecurityStatus
  HvciConfigured            = $deviceGuard.SecurityServicesConfigured -contains 2
  HvciRunning               = $deviceGuard.SecurityServicesRunning -contains 2
  ExplicitBlocklistSetting  = if ($null -eq $blocklistValue) {
    'Not explicitly set'
  } else {
    [int]$blocklistValue.VulnerableDriverBlocklistEnable
  }
}

Get-CimInstance -ClassName 'Win32_PnPSignedDriver' |
  Where-Object { $_.DriverVersion } |
  Select-Object DeviceName, DriverProviderName, DriverVersion, InfName, DriverDate |
  Sort-Object DriverProviderName, DeviceName

Get-WinEvent -FilterHashtable @{
  LogName = 'Microsoft-Windows-CodeIntegrity/Operational'
  Id      = 3076, 3077, 3099
} -MaxEvents 100 -ErrorAction SilentlyContinue |
  Select-Object TimeCreated, Id, Message

The registry value is only an indicator. A missing value does not prove that the blocklist is disabled because HVCI, Smart App Control, S mode or an App Control policy can enforce independently. Likewise, a value of 1 does not prove that the expected App Control policy is current and effective. Policy-load events, Code Integrity telemetry and effective device state belong together.

The PnP output is not a vulnerability scanner either. It helps assign vendors and versions. Whether a specific binary is affected by a Microsoft rule must be established from audit events, the deployed policy and vendor status.

2) Remove outdated drivers before the security change

Start with software classes that commonly install their own kernel components: hardware monitoring, tuning and RGB tools, legacy VPN clients, storage and backup agents, print software, endpoint security, DLP, encryption, RMM and virtual hardware tools. Also check applications that were uninstalled while their driver packages remained in the Driver Store.

Every finding needs one of four clean outcomes:

  • deploy a fixed and supported version from the vendor,
  • upgrade or reconfigure the dependent application,
  • remove unused software and its driver package in a controlled way,
  • replace the system or isolate it under a clearly time-boxed exception.

A blocklist is not a patch mechanism. It prevents a listed version from loading but does not repair the product or its dependencies. Do not disable the blocklist permanently just to restore an old management utility. That moves risk from a visible compatibility issue back into the kernel.

3) Establish Windows servicing and HVCI as the foundation

First ensure pilot devices receive current cumulative Windows updates and actually restart after servicing. Microsoft maintains the blocklist regularly and delivers updates through normal Windows servicing. Devices that have not taken a current build or restarted for months must not be marked protected in compliance reporting.

Enable HVCI, or Memory Integrity, on compatible hardware in dedicated rollout rings. Validation must include boot drivers, the hypervisor, EDR, VPN, storage, backup, print and specialist peripherals. PAWs and newly procured standard clients are often useful early targets. Domain Controllers and business-critical servers follow with a representative test group and a tested recovery path.

HVCI and the Vulnerable Driver Blocklist are not the same control. HVCI protects Code Integrity in a virtualization-based environment and, on supported systems, also enforces the blocklist. An App Control policy can provide the driver rules where HVCI has not yet been deployed. Document which mechanism is authoritative for every device class.

4) Pilot the current blocklist as an App Control policy

For systems that must always use the most recently published recommended list, or devices without a suitable HVCI path, the Microsoft policy can be deployed as a separate App Control for Business policy. Obtain the policy and refresh tool only through the controlled Microsoft download path. Validate origin, signature and hash, assign an internal version to the package and manage it as a security artifact.

Start with the Microsoft-provided audit variant. Event 3099 demonstrates that an App Control policy loaded; the policy ID and name must match the intended package. Event 3076 identifies code that would be denied under enforcement. Move to the enforced policy only when these findings are mapped to a device, driver, product and owner. Event 3077 records an actual enforcement block.

The supplied driver policy contains Allow All rules so it can operate as a standalone deny policy. On Windows versions that support multiple policies, deploying it as a separate side-by-side deny policy is usually clearer than merging. If it is merged with an existing explicit allowlist, remove the Allow All rules first. Otherwise, the merged ruleset can undermine its intended allowlisting behavior.

Drivers that are already running are not unloaded from the kernel when a new policy is activated. A restart is required so that the newly denied component is blocked on its next load attempt. Make the restart part of the change, then validate boot, hardware function and Code Integrity events.

Place Windows Server 2016 in its own ring. The current policy must be converted on a newer supported Windows system or taken from the specifically provided variant. Improvised edits directly in EFI or CodeIntegrity directories are not a dependable enterprise deployment method.

5) Add the ASR rule as an upstream control

The Defender ASR rule “Block abuse of exploited vulnerable signed drivers” reduces a different part of the path: it prevents applications from writing known vulnerable signed drivers to disk. Introduce it in audit mode, review the findings centrally and then move each device class to block mode.

The rule does not replace the blocklist. If the driver is already present, the ASR rule alone cannot stop it from loading. Conversely, the blocklist does not automatically cover every new or organization-specific driver that an ASR or App Control rule might address. Maintain both controls as separate compliance signals.

6) Bind pilot, enforcement and monitoring together

A useful ring structure starts with security and IT test devices, then covers representative hardware models and application servers before reaching PAWs, Domain Controllers and the wider estate. A pilot needs more than one successful reboot. Test at least:

  • cold boot and restart with Secure Boot enabled,
  • BitLocker and recovery procedures,
  • EDR, backup, VPN and storage operation,
  • firmware and driver updates through the approved management path,
  • printing, docks and specialist peripherals,
  • virtual hardware, snapshot and restore processes,
  • Code Integrity events after policy update and restart,
  • rollback to the last-known-good policy.

Collect events 3076, 3077 and 3099 centrally. A single audit event is not automatically an incident, but it requires a decision. An enforcement block on a Domain Controller, PAW or security product is high priority. Retain at least policy ID, policy version, device, driver path, hash, signer, product, owner and decision.

Correlate technical telemetry with servicing data. An active policy on a system running a months-old Windows build is not a current blocklist. A device that has not restarted after enforcement should not be marked fully validated either.

7) Prepare recovery without creating a permanent security gap

Driver failures can appear as missing hardware functionality, a boot loop or, in rare cases, a blue screen. The recovery plan must therefore work outside the normal user session. Test out-of-band server access, Windows Recovery Environment, Safe Mode where supported by the operating model, BitLocker recovery and restoration of the last approved policy.

Define who can approve an exception before it is needed. A temporary reversal needs affected devices, driver version, vendor case, compensating controls, expiry date and a return plan. Disabling HVCI or the blocklist for an entire OU is not a rollback; it creates a new security state.

Advantages

  • Known kernel risks are stopped before load: a valid signature is no longer the only trust decision.
  • Credential protection becomes more robust: RunAsPPL, Credential Guard and EDR operate on a kernel foundation that rejects known vulnerable drivers.
  • Domain Controllers and PAWs gain another defensive layer: a local administrative mistake does not automatically enable arbitrary kernel code.
  • Vendor and version sprawl becomes visible: audit findings force ownership of a driver and its associated product.
  • The state is measurable: loaded policies, audit and block events, OS level and restart status can be assessed centrally.
  • The control acts before behavioral detection: a listed driver is denied even if a downstream sensor has not observed suspicious behavior.
  • ASR and App Control are complementary: writing, loading and broader code authorization can be controlled separately.

Disadvantages and limits

  • Compatibility failures are real: hardware, backup, VPN, storage, print or security products can fail when they depend on a blocked version.
  • Boot failures are possible: kernel drivers act early during startup, and untested enforcement can result in a blue screen.
  • The list is not exhaustive: new, unknown or organization-specific vulnerabilities are not covered automatically.
  • An unblocked driver is not automatically safe: absence from the list is not approval or a security assessment.
  • Audit mode does not protect: it provides decision data while the affected driver can still load.
  • A restart is still required: already loaded drivers are not removed from the kernel retroactively.
  • HVCI does not immediately fit every platform: legacy hardware, firmware or specialist drivers may require a separate migration path.
  • Servicing remains mandatory: an enabled but stale OS blocklist loses value over time.
  • ASR is only complementary: preventing a driver from being written does not block one that is already present from loading.
  • A deny list does not replace an allowlist: especially sensitive systems may still require explicit App Control authorization.
  • Local administrator rights remain risky: the blocklist reduces exploitable driver paths but does not replace least privilege.

Typical pitfalls

  • Treating “signed” as “safe”: signatures establish publisher trust, not permanent freedom from vulnerabilities.
  • Checking only the Windows Security toggle: UI, registry, HVCI and App Control policies can expose different parts of the state.
  • Enforcing across the whole domain in one change: hardware models and server roles need separate pilot rings.
  • Testing drivers only after they are blocked: vendor updates and removal belong before enforcement.
  • Allowing audit findings without review: a broad publisher exception can permit other vulnerable versions too.
  • Merging Allow All rules incorrectly: the standalone deny policy must not accidentally open an existing explicit allowlist.
  • Confusing ASR with the blocklist: writing a file to disk and loading it into the kernel are separate control points.
  • Skipping the restart after a policy change: the old driver can continue running even though the new policy loaded.
  • Testing only one hardware model: docks, storage, printing, VPN and firmware often vary within one device class.
  • Skipping Windows updates: the blocklist is a continuing servicing process, not a one-time project artifact.
  • Calling the blocklist a driver inventory: it covers selected risky drivers, not the complete approved estate.
  • Leaving HVCI disabled after troubleshooting: a time-boxed recovery action must not become the unnoticed target state.
  • Deleting policies manually from EFI directories: ad-hoc repairs can leave Code Integrity and Secure Boot in an opaque state.
  • Defining rollback only as another GPO: a system that cannot boot or connect will not receive the change in time.
  • Failing to record the policy version: without ID, version and ring, a block event is not reproducible.

Project checklist

  • [ ] Classify Windows 11 clients, older clients, PAWs, member servers, DCs, hosts and specialist devices separately.
  • [ ] Record current OS build, patch level and last successful restart for every pilot device.
  • [ ] Check both HVCI configuration and the actual running state.
  • [ ] Document the effective blocklist or App Control enforcement path per device class.
  • [ ] Inventory signed PnP drivers with vendor, version, INF and device.
  • [ ] Prioritize boot, storage, VPN, backup, EDR, RMM, print and hardware drivers.
  • [ ] Remove unused legacy software and remaining driver packages in a controlled way.
  • [ ] Assign a product owner and vendor update path to each remaining driver.
  • [ ] Monitor Windows servicing and monthly blocklist delivery.
  • [ ] Test HVCI on representative hardware in a dedicated pilot ring.
  • [ ] Obtain the current Microsoft blocklist only from a controlled source and version it internally.
  • [ ] Record App Control policy ID and name before distribution.
  • [ ] Verify event 3099 as policy-load evidence.
  • [ ] Collect audit event 3076 centrally and assign every finding to a product owner.
  • [ ] Do not create a broad allow rule for a vulnerable driver version.
  • [ ] Validate multiple-policy or merge behavior against existing App Control policies.
  • [ ] Handle Windows Server 2016 through its own compatible policy path.
  • [ ] Introduce the ASR rule in audit mode before moving device rings to block.
  • [ ] Assess ASR and blocklist compliance as separate signals.
  • [ ] Expand enforcement across all relevant hardware models and server roles.
  • [ ] Make restart a mandatory part of the enforcement change.
  • [ ] Alert on and investigate event 3077 after enforcement.
  • [ ] Test firmware, driver and Windows updating after enforcement.
  • [ ] Validate BitLocker recovery, WinRE and out-of-band access in practice.
  • [ ] Document the last-known-good policy and recovery procedure.
  • [ ] Track exceptions with device, driver, owner, rationale, compensation and expiry date.
  • [ ] Monitor HVCI or blocklist disablement as a time-critical deviation.
  • [ ] Schedule a quarterly policy review and reassess whenever hardware or software classes change.