Memory integrity from October:
what to check

What is Memory integrity (HVCI)?

Memory integrity, also called HVCI (hypervisor-protected code integrity), is a protection for the Windows kernel. It relies on virtualization-based security (VBS): the Windows hypervisor creates an isolated environment that assumes the kernel may be compromised, and runs the code integrity check inside it. Every driver and kernel component is verified before it is loaded; memory pages become executable only after the check, and executable pages are never writable.

In practice, it makes it much harder for malware, even after exploiting a vulnerability, to load untrusted drivers or modify kernel code. It is the same foundation on which Microsoft builds other protections, such as hotpatch updates. On a computer you will find it under Windows Security, Device security, Core isolation details.

What changes from October 2026?

Until now, Memory integrity was on automatically only on clean installs of Windows 11 with compatible hardware and on Secured-core devices; on computers upgraded from earlier versions it often stayed off. On 1 September 2026 Microsoft announced that, starting in October 2026, Windows quality updates enable it on eligible devices, also turning on virtualization-based security where needed.

• Before enabling it, Windows assesses the device: hardware capability, compatibility and performance.
• Choices already made remain in force: where Memory integrity has been turned off by an administrator or a user, the rollout does not change it.
• Where it does not turn on by itself, it can always be enabled with Windows management tools.

Which computers does it turn on for?

For the requirements, the announcement refers to Microsoft’s documentation on enabling Memory integrity, which lists the minimum hardware for automatic enablement:

On older processors that lack certain dedicated hardware features, Memory integrity runs through emulation and Microsoft warns that the performance impact is greater. This is one of the reasons why Windows assesses the device before enabling it.

What can go wrong?

The sensitive point is drivers. Microsoft warns that some applications and device drivers are not compatible with Memory integrity: they may stop working and, in rare cases, cause a boot failure, either after enablement or during it. In a business, the typical candidates are drivers for less up-to-date peripherals: scanners, readers, capture cards, laboratory or production equipment, and outdated virtualization or remote control software.

On Hyper-V virtual machines there are two documented incompatibilities: virtual Fibre Channel adapters and pass-through disks with the AllowFullSCSICommandSet option require the machine to be excluded from virtualization-based security.

How do I check whether it is on and whether it blocks any drivers?

A computer’s status can be read with the Win32_DeviceGuard WMI class, from a PowerShell session run as administrator:

$dg = Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
[pscustomobject]@{
  VBS               = $dg.VirtualizationBasedSecurityStatus   # 2 = enabled and running
  MemoryIntegrityOn = $dg.SecurityServicesRunning -contains 2 # True = HVCI running
}

Drivers blocked by Memory integrity end up in the CodeIntegrity event log, usually with event 3087. This command lists them:

Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' -MaxEvents 500 |
  Where-Object Id -eq 3087 |
  Select-Object TimeCreated, Message

Without PowerShell: the System Information (msinfo32) summary shows, at the bottom, the virtualization-based security services running, and the Core isolation page in Windows Security shows the status and lets you see incompatible drivers.

How do I manage it in a business with Intune or Group Policy?

Letting the update decide, computer by computer, is not a good policy: it is better to decide once and enforce it. The settings documented by Microsoft:

• Without UEFI lock, as a rule. With the UEFI lock, the protection cannot be turned off remotely or with a policy: to disable it you have to go into the BIOS. Microsoft recommends it only for those who explicitly want to prevent it from being disabled.
• A test group first. Microsoft recommends enabling it on a group of test computers before extending it to everyone.
• Explicit, temporary exceptions. If a device has an essential but incompatible driver, the right way is to update the driver; if no update exists, a policy that turns Memory integrity off on that device only, with the reason written down and a review date.

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

What to do around the 13 October Patch Tuesday

• Capture the current status of Memory integrity and VBS on company computers, with the command above or with a report from your management tool.
• List peripherals with outdated or unusual drivers and check their compatibility with Memory integrity with the manufacturers.
• Roll out the October updates first to a test group that includes those peripherals.
• After the update, look for 3087 events and for user reports of devices that no longer work.
• Lock in the choice with an Intune or Group Policy policy and document the exceptions: for organisations within the scope of NIS2 it is part of the device protection measures they must be able to demonstrate.

How we work

In managing modern workplace devices, security settings such as Memory integrity are Intune policies, not choices left to the individual computer: we test them first on a pilot group, roll them out to everyone and record the exceptions. It is the same approach we described for passwordless sign-in with FIDO2 and Intune and for Windows without NTLM.