VBS, memory integrity (HVCI) and Kernel DMA Protection

Once an attacker runs code in the Windows kernel, most other defences are negotiable: they can disable security tools, read LSASS and hide themselves. Three hardware-backed features push back on that:

• Virtualization-based security (VBS) uses the Windows hypervisor to create an isolated environment (Virtual Trust Level 1) that the normal kernel cannot read or modify.
• Memory integrity, also called hypervisor-protected code integrity or HVCI, runs kernel code integrity checks inside VBS. Kernel memory pages are writable or executable, never both, and only signed code can become executable, even if the kernel is compromised.
• Kernel DMA Protection uses the IOMMU to stop external devices on Thunderbolt, USB4 or PCIe hot-plug ports from reading or writing memory through direct memory access.

The BitLocker hardening pillar mentions DMA protection as part of the boot chain, and the Credential Guard guide covers the credential isolation that runs on top of VBS. This guide deploys VBS and memory integrity across a fleet and makes Kernel DMA Protection part of your hardware standard. The rest of the series is on the BitLocker & Boot Security topic.

Requirements

Windows 11 on hardware that meets its minimum requirements supports all three. Many desktops and older laptops lack Kernel DMA Protection even when VBS works.

Step 1: check readiness

On a sample of each hardware model, msinfo32 > System Summary shows Virtualization-based security, Kernel DMA Protection and the list of VBS services configured and running. The same data from PowerShell:

$dg = Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard
$dg.VirtualizationBasedSecurityStatus     # 0 off, 1 enabled but not running, 2 running
$dg.AvailableSecurityProperties           # 1 hypervisor, 2 Secure Boot, 3 DMA protection, 7 MBEC/GMET, ...
$dg.SecurityServicesConfigured
$dg.SecurityServicesRunning               # 1 Credential Guard, 2 memory integrity, 3 System Guard Secure Launch

For drivers, the Windows Security app under Device security > Core isolation details lists incompatible drivers that prevent memory integrity. At fleet scale, the more reliable method is an audit phase: enable memory integrity on a pilot ring per hardware model and check the Microsoft > Windows > CodeIntegrity > Operational log for drivers blocked from loading. Update or replace them before broad rollout. Typical offenders are old hardware utilities, anti-cheat engines, older VPN and virtualization drivers, and unmaintained vendor tools.

Step 2: enable VBS and memory integrity with Group Policy

GPO path: Computer Configuration > Policies > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security, set to Enabled:

The UEFI lock stores the setting in a firmware variable so it cannot be turned off by editing the registry or policy; removing it later requires a documented procedure with physical presence. Start without it.

Registry equivalents, for images or non-domain devices:

HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard
  EnableVirtualizationBasedSecurity   REG_DWORD 1
  RequirePlatformSecurityFeatures     REG_DWORD 1 (Secure Boot) or 3 (Secure Boot and DMA protection)

HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity
  Enabled                             REG_DWORD 1
  Locked                              REG_DWORD 0 (no UEFI lock) or 1

A restart is required. On Windows 11, Kernel-mode Hardware-enforced Stack Protection is a further core isolation option that builds on memory integrity and CPU shadow stack support; evaluate it after memory integrity is stable.

Step 3: the Intune equivalent

In the settings catalog, the Device Guard and Virtualization Based Technology categories carry the same settings:

• Enable Virtualization Based Security and Require Platform Security Features (Policy CSP DeviceGuard/EnableVirtualizationBasedSecurity, DeviceGuard/RequirePlatformSecurityFeatures).
• Hypervisor Enforced Code Integrity: disabled, enabled with UEFI lock, or enabled without lock (Policy CSP VirtualizationBasedTechnology/HypervisorEnforcedCodeIntegrity, values 0, 1 and 2).
• Require UEFI Memory Attributes Table (VirtualizationBasedTechnology/RequireUEFIMemoryAttributesTable).

Endpoint security > Account protection also exposes Credential Guard. Avoid configuring the same setting in two profiles, or in both GPO and Intune on hybrid devices, as conflicts leave devices in an error state.

Add Require code integrity under Device Health in your compliance policy to report or gate access based on attested code integrity.

Step 4: Kernel DMA Protection

Kernel DMA Protection is switched on by the firmware, not by Windows. Your jobs are to buy hardware that has it, keep it enabled, and decide how to treat incompatible devices.

1. Hardware standard: require Kernel DMA Protection: On in msinfo32 as a purchasing criterion for all laptops and for desktops with Thunderbolt or USB4.
2. Firmware settings: keep VT-d / AMD-Vi and the IOMMU enabled; they can be disabled in BIOS setup, which is another reason for a firmware password.
3. Enumeration policy: GPO Computer Configuration > Administrative Templates > System > Kernel DMA Protection > Enumeration policy for external devices incompatible with Kernel DMA Protection. Options are Block all, Only while logged in (default behaviour) and Allow all. Choose Block all for high-risk devices, knowing that some older docks and peripherals whose drivers do not support DMA remapping will stop working. Intune: Policy CSP DmaGuard/DeviceEnumerationPolicy (0 block all, 1 only after log in, 2 allow all).

For devices without Kernel DMA Protection, compensate:

• BitLocker with TPM and PIN for high-risk users, so keys are not in memory before authentication.
• The BitLocker setting Disable new DMA devices when this computer is locked under Windows Components > BitLocker Drive Encryption.
• Disable Thunderbolt or set its security level in firmware where docks are not used.

What breaks

• Incompatible kernel drivers fail to load when memory integrity is on; hardware that depends on them loses functionality, and a boot-critical storage or security driver can stop the system from starting. Always pilot per model.
• Third-party hypervisors and emulators must run on the Windows Hypervisor Platform once VBS is on; current versions of the main products do, older ones do not.
• Performance on processors without MBEC/GMET, particularly for gaming and graphics workloads.
• UEFI lock makes rollback slow. Keep it off until the fleet is stable.
• Docks and peripherals without DMA-remapping-capable drivers stop enumerating with Block all.

Memory integrity also makes driver-based attacks harder; combine it with the vulnerable driver blocklist, which is enforced automatically on devices with memory integrity on, and with App Control for Business for user-mode code.

Verify it

On the device:

$dg = Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard
[pscustomobject]@{
  VBS              = $dg.VirtualizationBasedSecurityStatus -eq 2
  MemoryIntegrity  = $dg.SecurityServicesRunning -contains 2
  CredentialGuard  = $dg.SecurityServicesRunning -contains 1
  DmaAvailable     = $dg.AvailableSecurityProperties -contains 3
}

Confirm Kernel DMA Protection: On in msinfo32 for the hardware model. Collect the same values fleet-wide and alert on devices where VBS is configured but not running: that usually means virtualization was disabled in firmware, a BIOS reset happened or an incompatible driver was installed.

Checklist

• Hardware inventory: VBS capable, MBEC/GMET, IOMMU and Kernel DMA Protection per model
• Incompatible drivers identified in a pilot and updated or removed
• VBS and memory integrity enforced by GPO or Intune, UEFI lock after stabilisation
• Platform security level includes DMA protection where every device has an IOMMU
• Kernel DMA Protection required in the hardware purchasing standard
• Enumeration policy set; compensating controls on devices without DMA protection
• Fleet report on SecurityServicesRunning; alerts when VBS stops running