Windows Will Auto-Enable Memory Integrity in October 2026 - Decide Now, or Windows Update Will Decide For You

Starting in October 2026, Windows quality updates will begin turning on Memory Integrity - and virtualization-based security (VBS) alongside it, if it is not already on - for eligible devices, automatically. Microsoft's own framing is calm: hardware, compatibility, and performance are evaluated first, and any existing admin or user policy decision is respected. Read that framing carefully, though, because it contains the actual action item: it is respected only if you have made one.

Every device where nobody has ever explicitly configured this setting is, by definition, unmanaged - and unmanaged is exactly the population this rollout is aimed at.

The problem: "unmanaged" is about to stop meaning "off"

For years, Memory Integrity has quietly defaulted to off on most devices unless someone turned it on deliberately - through Windows Security, through Intune, or through Group Policy. Devices with no explicit setting simply stayed in the same state they shipped in.

That stops being true from October 2026. A device with no explicit policy is exactly the device Microsoft's rollout logic is watching for, and it will get switched on for you, on Microsoft's schedule, not yours.

Why it happens: what Memory Integrity actually does

Memory Integrity - also called Hypervisor-Protected Code Integrity (HVCI) - is one of the features built on virtualization-based security (VBS). VBS uses the Windows hypervisor to carve out an isolated region of memory that even the Windows kernel itself cannot directly touch. Memory Integrity moves the check for "is this kernel-mode code and drivers actually signed and trustworthy" into that isolated region, so a compromised or malicious kernel-mode driver cannot tamper with the check that is supposed to be stopping it.

Microsoft has been pushing toward this being the normal state of a Windows device for a while - it already ships on by default on new Windows 11 hardware in many cases. This announcement is the next step: extending it to already-deployed devices that are technically capable but have simply never had the setting touched.

How to verify: check the current state on real devices

Two different questions need two different checks: is the feature currently running, and has anyone ever set an explicit policy for it.

That is the current runtime state - whether VBS and Memory Integrity are actually active right now. It says nothing about whether that state was set deliberately or is just whatever the device happened to ship with.

For the policy question, check the registry key both the CSP and Group Policy write to:

A device that returns nothing there is unmanaged for this setting, regardless of what its current runtime state happens to be - and unmanaged is what the October rollout is targeting.

The fix: make the decision yourself, before Windows Update does

Cover both deployment paths - the CSP for Intune, and the matching Group Policy setting, since they write to the exact same registry value and either one counts as "an explicit decision" for the purposes of this rollout.

Both map to the same Group Policy path: Computer Configuration › Administrative Templates › System › Device Guard › Turn On Virtualization Based Security - VBS itself is the top-level checkbox, and Memory Integrity is one of the sub-elements inside that same policy.

1. Inventory first. Run the registry check above across a representative slice of the fleet, or push it as a compliance script, to find out how much of the estate is genuinely unmanaged today.
2. Check the site's driver blocklist post against your fleet's actual installed drivers before enabling anything at scale - this is the step most likely to surface a real, fleet-specific incompatibility that Microsoft's own broad evaluation would not have caught.
3. Decide, don't default. If you are ready, deploy HypervisorEnforcedCodeIntegrity via a Settings Catalog policy in Intune, targeted at a pilot group first. If you are not ready by October, explicitly set it to 0 (Disabled) rather than leaving the setting untouched - an explicit "no" is honored; an absence of any setting is not.
4. In the Intune admin center: Devices › Configuration › Create › New policy › Windows 10 and later › Settings catalog, search for Hypervisor Enforced Code Integrity under the Virtualization Based Technology category, set your chosen value, and assign to a pilot group before any wider rollout.

Proof it worked

Re-check both signals on a device you have configured: the runtime state now shows Memory Integrity running, and the registry value under DeviceGuard now reflects the value you actually set, rather than being empty.

The real target, though, is not any one device - it is the registry check returning a real value everywhere in the fleet, so that whatever Windows Update does in October is enforcing a decision you already made, not making one for you.

References

• Expanding memory integrity protection across Windows devices - the original announcement this post is responding to.
• Enable memory integrity - Microsoft's own configuration guidance for Memory Integrity across Intune, Group Policy, and Windows Security.
• Policy CSP - DeviceGuard - the EnableVirtualizationBasedSecurity node and its Group Policy mapping.
• Policy CSP - VirtualizationBasedTechnology - the HypervisorEnforcedCodeIntegrity node itself, its UEFI-lock values, and the matching Group Policy element.

Related on EndpointWeekly

• Memory Integrity will not turn on: finding the incompatible driver, and what the vulnerable driver blocklist actually blocks - what to do when a specific driver is the thing standing in the way.
• Virtualisation-based security will not start - the firmware, hypervisor, and licensing prerequisites, checked in the order Windows actually checks them.