HVCI memory integrity: verify drivers, runtime state and UEFI lock

What Is HVCI Memory Integrity?

HVCI memory integrity is a Windows protection that runs kernel code integrity inside the isolated environment provided by virtualization-based security (VBS). Its deployment needs three separate answers: which configuration is intended, whether memory integrity actually runs on each target device, and whether recovery remains possible after the chosen UEFI lock mode. A domain GPO alone answers only part of the first question. Microsoft enablement guidance

For an AD team, the useful outcome is a tested rollout with evidence per device. Start with a representative population, resolve driver dependencies, measure the service after reboot, and record the lock decision. Include machines that could not be measured in the report; silently dropping them makes policy coverage look like verified protection.

This guide uses Microsoft Learn documentation checked on 3 October 2026 and the two collector checks described below. The Windows commands are documentation examples or identified read-only adaptations; they were not executed against a Windows estate for this article. No fleet coverage or successful compatibility test is claimed.

Our Credential Guard after upgrade guide uses the same WMI evidence method for a different service: isolation of selected secrets. Memory integrity concerns kernel code integrity. Proof that one service runs does not establish that the other runs.

How Policy, Runtime and UEFI Lock Differ

The same number has different meanings depending on the setting. Microsoft's VirtualizationBasedTechnology policy reference documents the policy mode and its Device Guard GPO mapping. The enablement page separately documents local Enabled and Locked values.

The local paths in the table are under HKLM\SYSTEM\CurrentControlSet\Control. The policy value is under HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard. Do not write Enabled=2 to reproduce the policy's unlocked mode. Do not interpret a WMI service identifier as a registry mode. Preserve the full path and value name in evidence so another administrator can interpret it without reconstructing the collection.

A useful change record keeps policy intent, applied policy, local settings and runtime observation as separate fields. If a GPO specifies one mode while an endpoint shows another, investigate the applied configuration before calling the change complete. If the settings agree but runtime differs, investigate the endpoint rather than repeatedly editing the same GPO.

UEFI lock also changes the recovery decision. Microsoft's GPO procedure offers an unlocked deployment and warns that selecting the locked mode restricts remote disablement. Decide who can reach the firmware menu and restore the machine before making that restriction part of production administration. Microsoft GPO instructions

Detection: Collect Evidence on the Target Device

Use an elevated PowerShell session on the target. Microsoft provides this command in its Win32_DeviceGuard reference:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

The following read-only adaptation selects the fields needed for this investigation:

$state = Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
$state | Select-Object SecurityServicesConfigured, SecurityServicesRunning, VirtualizationBasedSecurityStatus

Interpret the service arrays by membership. A result containing both 1 and 2 includes memory integrity; 1 identifies Credential Guard. VirtualizationBasedSecurityStatus=2 describes running VBS, while membership of 2 in SecurityServicesRunning identifies running memory integrity. Microsoft WMI property definitions

Treat the collection as an observation with a host, time and boot context. Keep the full arrays, even if the dashboard later displays a boolean. Distinguish a successful query that lacks memory integrity from a query that failed. Authentication failure, unreachable devices and missing output belong in an unknown category with a follow-up action.

Compare policy and local lock settings

This read-only PowerShell adaptation reads the named settings; missing paths or values should be recorded as absent, not silently replaced by zero:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard' -Name HypervisorEnforcedCodeIntegrity
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity' -Name Enabled, Locked
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard' -Name EnableVirtualizationBasedSecurity, RequirePlatformSecurityFeatures, Locked

Compare those observations with the approved mode and a resultant-policy report for that host. A setting exported from an unrelated GPO is insufficient evidence that the target received it. Capture conflicting configuration and collection errors instead of turning them into a simple protected/unprotected score.

The documented Win32_DeviceGuard properties above do not provide a Locked property. Read the named registry markers separately. They describe lock configuration and should not be presented as an independent firmware attestation. A CIM result showing memory integrity running likewise does not prove that UEFI lock is enforced. Microsoft configuration and validation reference

Driver Compatibility: Design a Pilot That Exercises Real Work

Microsoft's driver compatibility guidance combines Code Integrity checks in Driver Verifier, functional testing with memory integrity enabled, and the Windows HLK HyperVisor Code Integrity Readiness Test. It distinguishes signing readiness from thorough functional testing. A driver that loads during one boot has not necessarily exercised every relevant runtime path.

For a driver owner or engineering team, the documented verifier command is:

verifier.exe /flags 0x02000000 /driver <driver.sys>

Replace the placeholder with the selected driver in a recoverable test environment. Driver Verifier is a test tool, not a command to distribute indiscriminately to production endpoints. Record the selected driver, test conditions, findings and recovery route. Coordinate failures with the driver supplier rather than treating a permanent disable as the only solution.

For the deployment team, build a matrix of device models, firmware revisions, Windows builds, driver packages and business workflows. Include the combinations actually present in the target population. Choose pilot machines that expose meaningful differences; a convenient set of identical laptops can leave other hardware families untested.

Test the work those machines must perform: startup, peripherals, required applications and their driver-dependent operations. Define expected results before starting and attach failures to a named package and owner. These are rollout recommendations, not a claim that a particular application or device in your environment is incompatible.

Give each exception a reason, affected population, responsible owner, planned fix and review date. Separate a demonstrated compatibility failure from an assumption that an old exception is still needed. Ask suppliers for an updated package or supporting test evidence, then rerun the relevant workflow with memory integrity active. The exception inventory becomes the boundary of the next rollout wave.

Remediation: Stage the GPO and Prove the Result After Reboot

1. Approve the population and recovery plan

Assign owners for hardware review, driver testing, GPO changes and recovery. Record the intended lock mode, pilot scope and exclusions before editing policy. Set an acceptance rule that requires both a runtime observation and passing required workflows; merely creating a GPO should not close the task.

For administration workstations, place this decision in the broader architecture described by our ANSSI Active Directory guide: administration paths, dedicated use and trust boundaries. Hardening one Windows feature does not demonstrate that the administration architecture is sound or establish ANSSI compliance.

2. Apply a scoped supported configuration

Follow Microsoft's GPO procedure under Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security. Enable the policy and select the intended option under Virtualization Based Protection of Code Integrity. Link and filter the GPO for the approved pilot population; inspect the target's applied policy before expanding scope. Microsoft deployment procedure

The documented policy refresh command, run from an elevated Command Prompt, is:

gpupdate /force

Schedule a restart for the pilot evidence collection. After startup, repeat the CIM observation and local-setting comparison. Record the observed arrays and mode alongside the change request. Do not infer a fleet result from one successful machine; each unmeasured target retains its own unresolved state.

3. Document recovery before selecting UEFI lock

For instability following enablement, Microsoft's troubleshooting procedure starts by disabling the enabling policies, then using Windows Recovery Environment (Windows RE) to set the scenario's Enabled value to 0 and restart. The documented command is:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 0 /f

Build the machine-specific recovery runbook around that procedure. Validate access to Windows RE and the affected installation's registry, identify the operator, and test how the enabling policy will be withdrawn. Do not assume an ordinary remote registry change can recover a machine that cannot boot.

With UEFI lock, Microsoft additionally requires disabling Secure Boot to complete those recovery steps. That requirement makes firmware access part of the plan. Select lock only when the physical recovery route, authorized operator and rollback procedure are documented. Include restoration of the approved firmware configuration and revalidation in the runbook. Microsoft recovery guidance

4. Expand using retained evidence

Review pilot observations and failures before the next wave. Preserve exceptions and unknown devices in the same inventory as successful measurements. Recheck after relevant driver or platform changes. A useful closure record contains the approved policy, target scope, boot context, running-service evidence, functional test outcome and recovery owner.

How EtcSec Detects This

EtcSec's etc-collector exposes two GPO configuration checks for this topic. The following behavior comes from their actual Detect() branches, not an endpoint test:

gpoSetsAtLeast and gpoMaxValue iterate the collected GPOs, skip missing policy/settings objects and ignore unset values. The maximum starts at -1. The Registry.pol parser maps a DWORD named HypervisorEnforcedCodeIntegrity in a key containing deviceguard to HVCIEnabled. It does not obtain the runtime scenario's separate Enabled and Locked measurements.

The maximum is a numerical aggregate, not a security ranking or a calculation of GPO precedence. If one policy has 1 and another has 2, the maximum is 2 and the Low check fires. Values above 2 also enter that same finding branch because the code has no enum validation. They are not documented valid lock modes and should be investigated as unexpected data.

Count 1 is the detector's finding count, not a count of exposed endpoints. Neither check computes per-machine Resultant Set of Policy (RSoP), evaluates GPO links/filtering or queries WMI runtime. A positive setting anywhere can suppress the OFF check even when target coverage is incomplete. An absent GPO value can coexist with enablement through another mechanism; it does not establish that memory integrity is disabled at runtime.

Use these checks to start the policy investigation, then add independent device evidence. The detector names and comments do not by themselves prove ANSSI compliance, actual firmware lock, driver compatibility or successful protection across the fleet. Those conclusions need their own evidence and review.

Sources

• Microsoft Learn: enable memory integrity, GPO, registry, WMI and recovery
• Microsoft Learn: driver compatibility with memory integrity and VBS
• Microsoft Learn: VirtualizationBasedTechnology policy values and GPO mapping