Memory integrity turns itself on in October, and only where nobody decided anything

On 1 September Microsoft published two sentences back to back: "existing administrator and user choices and policies will remain in effect" and "devices on which memory integrity was previously disabled will not be automatically changed by this rollout". Both describe a census, and Microsoft is not hiding it. The consequence is the part worth reading twice: the change lands on the machines where there is no decision at all, for or against. In October, on that set, the administrator is Windows Update.

What gets switched on, in Microsoft's own words

The entry sits in the Windows message center, dated 1 September 2026, and points to the Windows IT Pro blog. It says, verbatim: "Beginning in October 2026, Windows quality updates will start enabling memory integrity on more eligible Windows devices. On some devices, this change will also enable virtualization-based security (VBS). The rollout will occur gradually, so the change might not reach all eligible devices at the same time." And it closes by setting the scope: "Existing administrator and user choices and policies will remain in effect. Devices on which memory integrity was previously disabled will not be automatically changed by this rollout."

Memory integrity is the consumer-facing name for what the technical documentation calls HVCI, hypervisor-enforced code integrity. It stands up an isolated environment using the Windows hypervisor and moves the signature check for kernel-mode code inside it. The practical effect: only kernel code and drivers the system trusts get loaded, and an attacker who already has kernel execution finds they cannot load their own driver. It is one of the few mitigations that genuinely raises the cost of a kernel attack, and it is worth saying early so there is no misunderstanding: we think the change is right, and the correct end state for almost any fleet is "on". What we are arguing about here is who decides, and on what information.

A calendar note, because this will circulate badly: Microsoft says "October 2026 quality updates", not a specific day. That month's Patch Tuesday is 13 October, which is where the date you will see repeated in the news comes from. For this rollout, plan against the month; for the other two things landing that same day — further down — the 13th is confirmed in writing.

"Eligible": five factors, none of them queryable

The same entry lists the factors Windows uses to judge whether a device is ready: "hardware capabilities, compatibility, performance considerations, Windows 11 system requirements, and recommended built-in protections". The exact wording is "factors such as", so the list is not even closed, and none of the five it names is queryable. There is no command that tells you "this machine is in the set", no published list of models, no Intune report that anticipates it. You can guess — and it is our guess, not a published criterion — that a recent machine with Secure Boot on is a candidate. That is as far as it goes.

That leaves planning with a single useful question, since "will it reach me?" is one you cannot answer: what state is each machine in today, and what happens to it if it is reached? That one does have an answer, and you can get it in an afternoon.

There is a detail in the manual itself that points at which part of the fleet will feel it. Memory integrity "works better" with Intel Kaby Lake and higher processors, which carry Mode-Based Execution Control, and with AMD Zen 2 and higher, which carry Guest Mode Execute Trap. Older processors fall back on an emulation called Restricted User Mode and, quoting directly, "will have a bigger impact on performance". Put another way: the machines that will take it worst are the old ones, which is exactly where nobody has ever touched this setting.

The census: three fields that tell you where you stand today

Windows exposes all of this through a WMI class, Win32_DeviceGuard. From an elevated PowerShell session:

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

The three fields read as follows, per the table in the documentation:

The distinction between the last two matters in practice: "configured" and "running" can diverge, and the manual documents a case where they do. On Azure virtual machines, if Secure Boot with DMA was selected, memory integrity is not supported and — quoting directly — "VBS will show as enabled but not running". If your inventory only collects the "configured" field, it will tell you the fleet is protected while part of it is not. Collect all three.

For a one-off check on a single machine, msinfo32 shows the same thing at the bottom of System Summary, and the user-facing panel lives under Windows Security → Device security → Core isolation details. One warning for when you go looking for the setting: in the registry and in Group Policy this still hangs off Device Guard, a name Microsoft retired. Their own manual puts it like this: "Device Guard is no longer used except to locate memory integrity and VBS settings in Group Policy or the Windows registry." You will be hunting for a feature under a name its own vendor no longer uses.

How this reaches the ticket queue

The warning that opens the memory integrity manual is not the kind of thing anyone writes casually: "Some applications and hardware device drivers may be incompatible with memory integrity. This incompatibility can cause devices or software to malfunction and in rare cases may result in a boot failure (blue screen)." And further down, in the registry section: "All drivers on the system must be compatible with virtualization-based protection of code integrity; otherwise, your system may fail."

Now translate that into what reaches your ticket queue. Nobody is going to open a ticket saying "memory integrity blocked a driver". They will tell you the warehouse label printer will not print, that no application detects the signature pad, that the accounts department's document scanner — the one that works perfectly, which is why nobody has ever touched its driver — has stopped appearing, or that a laptop boots to a blue screen. And because the rollout is gradual, the tickets do not all arrive on the same day: they arrive one at a time over a period Microsoft does not specify, which is the worst possible way to receive a common problem.

Which is why the inventory happens first. Afterwards, the question "what changed on this machine?" no longer has a cheap answer. It is the same mechanism we wrote about with the conditional access policies that appear in your tenant without you writing them: a legitimate change, signed by the vendor, well intentioned, that surfaces somewhere completely different from where it originated.

If you decide: where it gets written, and the lock trap

There are three places where Windows reads a decision about this, and meeting minutes are not one of them. In Group Policy: Computer Configuration → Administrative Templates → System → Device Guard → "Turn on Virtualization Based Security" → Enabled, and underneath, under "Virtualization Based Protection of Code Integrity", Enabled without UEFI lock. In Intune: settings catalog, Virtualization Based Technology → Hypervisor Enforced Code Integrity, or the equivalent node of the VirtualizationBasedTechnology CSP. And in the registry, which is what the other two end up writing:

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

Those are Microsoft's recommended values, and the two Locked zeros are the reason for this section. The alternative, the UEFI lock, comes with its own warning in the manual: "Only select Enabled with UEFI lock if you want to prevent memory integrity from being disabled remotely or by policy update. Once enabled with UEFI lock, you must have access to the UEFI BIOS menu to turn off Secure Boot if you want to turn off memory integrity."

Read that as a sentence about operations, not about security. With the lock on, undoing it is a physical trip to the machine. With a fleet of a couple of hundred laptops spread across offices and homes, you have just turned a policy change into a logistics problem. Our rule, for what it is worth: hardening you cannot undo remotely is not hardening, it is a hostage. The UEFI lock has its place, but you choose it deliberately and for the machines that earn it — a domain controller, a handful of high-risk laptops — not as the default for the whole fleet. And there is also, in that same registry key, a Mandatory value, which per the manual makes the system "refuse to boot" if the virtualization modules fail. Do not touch that one without a very good reason and a written recovery plan.

Two more details that slip past easily. The first is counter-intuitive: RequirePlatformSecurityFeatures set to 3 (Secure Boot with DMA protection) sounds stricter than 1 (plain Secure Boot), but the manual warns that with 3 "memory integrity and the other VBS features will only be turned on for computers that support DMA. That is, for computers with IOMMUs only. Any computer without IOMMUs will not have VBS or memory integrity protection." The stricter value protects fewer machines. Microsoft recommends 1 "in most situations". The second: if you are piloting App Control for Business, take note, because "if your App Control policy is set to turn memory integrity on, it will be turned on even if the policy is in audit mode". For this, audit mode does not audit.

The seven-day plan we would run

• 1. The census, dated. The command above across the whole fleet, through whatever management tool you already have. Columns: machine, processor, the three VBS fields, and whether a written policy exists. Keep it: in a month's time it is the only cheap way to answer "was it already like this?".
• 2. Three piles. Already on (nothing to do). Off: Microsoft says the rollout does not touch these machines, and it does not require a policy to exist — being disabled is enough — though we would write it down anyway, because a decision that only lives in somebody's head does not survive the next rebuild. And untouched: this is where the change lands, and it is the only pile that matters.
• 3. From the third pile, pull the odd ones. Machines with a peripheral that is not a mouse: label printers, scanners, signature pads, USB licence dongles, lab or workshop instruments, old storage controllers, third-party disk encryption software. That is your test list, and it is short.
• 4. A real pilot ring. Microsoft recommends it in writing: "we recommend that you enable these features on a group of test computers before you enable them on users' computers". A real ring is machines people actually use, with their peripherals and their odd software plugged in. Three clean virtual machines prove nothing about what breaks here.
• 5. Write the decision for all three piles, including the "yes, on" one. No UEFI lock unless there is a reasoned, recorded exception. The goal is that the state has an owner.
• 6. The rollback, prepared in advance. The manual documents it in four steps, and the first is the one everybody skips: first disable any policies that enable VBS and memory integrity — the GPO, the Intune profile — because otherwise they reapply the value on the next boot and the procedure looks broken. Then yes: boot into the Windows Recovery Environment and set the HVCI key's Enabled value to 0. Printed, in the hands of whoever answers the phone, before it is needed. And if somebody set the UEFI lock, you also have to turn off Secure Boot in the BIOS.
• 7. Alert on change, not on state. "Tell me if memory integrity is off" is an alert that gets muted in the first week. The useful one is: tell me when a machine changes state, in either direction. A change you did not ask for is exactly what you want to see in the inbox.

October brings three clocks, and only two of them read the 13th

While you were looking at memory integrity, the same message center carries two other entries with that date. On 14 September: "On October 13, 2026, Windows 11, version 24H2 Home and Pro editions, and Windows 10 Enterprise LTSB 2016 will reach end of updates." On 11 September: "On October 13, 2026, Windows Server 2022 will reach end of mainstream support. The October 2026 security update will be the last mainstream support update available for this version", after which it moves to extended support with security updates at no additional cost through 14 October 2031. And the third, with reminders published at 90, 60 and 30 days: the AD FS DKM container ACL hardening enters Enforcement mode in October, addressing the elevation of privilege CVE-2026-56155.

With memory integrity that is four things in the same month, and they are worth keeping apart: only the end of updates for 24H2 and the end of mainstream support for Server 2022 are dated the 13th in writing. Memory integrity and the AD FS hardening both carry the same label, "October 2026", with no day. And their natures do not match: one switches something on at the desks, another stops giving you something on the servers, the third modifies permissions on an object in your directory, and the fourth merely takes a date off the calendar. They share no rollback plan and, in most companies, no owner. The classic October mistake is treating all of it as a single maintenance window.

If you run AD FS, the one with the alarm clock is the third, for a specific reason: the rollback is not "uninstall the update", it is permissions on a container in your Active Directory. Microsoft's notice says that "during Enforcement mode, supported versions of Windows Server will run remediation by default unless administrators explicitly opt out", and adds that "Windows Server 2012 and Windows Server 2012 R2 still require manual remediation and will not be automatically remediated". In other words: on modern versions it happens by itself, and precisely on the old ones — where nobody has ever looked at that container's permissions — nobody takes charge. And the first two are the same story we already told about Office 2021: end of updates does not mean it stops working, it means it stops being tested.

Virtual machines are in the census too

Memory integrity works inside a virtual machine just as it does on physical hardware, and Microsoft documents the Hyper-V case with its requirements: generation 2, a host running at least Windows Server 2016 or Windows 10 1607, and the ability to exclude a VM from the host with Set-VMSecurity -VMName <name> -VirtualizationBasedSecurityOptOut $true. The interesting part is the two incompatibilities it lists, because they point straight at the kind of machine you do not want to touch blind: virtual Fibre Channel adapters are not compatible with memory integrity, and neither is the AllowFullSCSICommandSet option for pass-through disks. In both cases the VM has to be opted out first. That is not on some random laptop: it is on the backup server with its tape library, and on the VM talking to a direct disk.

An honest note on the scope of that section: all of it is the Hyper-V table, and we are not going to stretch it to platforms Microsoft does not cover. We run our Windows guests on Proxmox, and there the dependency is the same in nature — the guest has to be able to bring up its own hypervisor, so the host has to expose the virtualization extensions to it — but the person who answers that is whoever operates the host, not a Hyper-V manual. If your Windows VMs run somewhere else, that is the question to ask, and it is worth asking before October rather than during. And if you are also mid-way through a migration where the vendor's repository sets the calendar, you already know how stacking two other people's clocks into the same week ends.

What we are not saying

We are not telling you to turn memory integrity off. Quite the opposite: if your fleet already has it on and nothing has broken, good, you are where you want to be. Nor do we think the default is wrong; at the scale of hundreds of millions of home machines, switching it on is the right call and doing otherwise would be negligent. Our objection is narrower, and it is this: inside a company, "there is no decision" is not the same as "it does not matter", and it is being resolved by somebody who does not know what is plugged into your machines.

The rollout starts this month, so there is no incident to tell here yet: what there is is the message center and the memory integrity manual read end to end, plus the method we apply to any change that arrives on its own. If we have one in six weeks, we will tell it with its numbers.

Conflict of interest, up front: we are not resellers of any one platform, so nobody pays us to recommend what we recommend here. Running the census, standing up the pilot ring and writing the policy is work we do bill for.

Sources (verified on 2 October 2026): the announcement of the memory integrity rollout beginning October 2026, the five readiness evaluation factors and the sentence stating that existing choices and policies remain in effect (entry of 01-09-2026), the end of updates for Windows 11 24H2 Home and Pro and Windows 10 Enterprise LTSB 2016 on 13-10-2026 (entry of 14-09-2026), the end of mainstream support for Windows Server 2022 on 13-10-2026 with extended support through 14-10-2031 (entry of 11-09-2026) and the three reminders about AD FS DKM container ACL hardening moving to Enforcement mode, including the note on Windows Server 2012 and 2012 R2 (entries of 29-07, 17-08 and 14-09-2026) — Windows message center, which points to "Expanding memory integrity protection across Windows devices" on the Windows IT Pro blog and to KB5121391; the warning about incompatible drivers and blue screens, the memory integrity = HVCI equivalence, the note on Kaby Lake/Zen 2 and Restricted User Mode, the Group Policy and Intune paths, the recommended registry keys, the UEFI lock warning, the behaviour of RequirePlatformSecurityFeatures at value 3, the Mandatory option, the App Control audit mode note, the Win32_DeviceGuard value tables, the Azure VM case with Secure Boot with DMA, the recommendation to test on a group of test computers, the Windows RE recovery procedure and the requirements and incompatibilities for Hyper-V virtual machines — "Enable memory integrity", Microsoft Learn (article date 14-08-2026). Reading Microsoft's sentence as a census, the UEFI lock rule, the seven-day plan and the alert-on-state-change rule are ours, not those sources'.