On September 1, 2026, Microsoft announced that starting in October of the same year, it will roll out Memory Integrity to eligible devices through Windows quality updates. On eligible devices where Memory Integrity is currently disabled, the underlying Virtualization-Based Security (VBS) will also be enabled. The goal is to activate protections against attacks that penetrate the kernel without requiring users to change any settings.
However, this is neither a forced rollout to all Windows 11 devices nor an update that blanket-disables all undervolting software. Windows will evaluate hardware capability, compatibility, and performance before enabling the feature, and settings that users or administrators have already disabled will be preserved. What Microsoft's announcement confirms is limited to: "begins in October 2026," "delivered via Windows quality updates," and "eligibility assessed on a per-device basis." No target versions, KB numbers, or a specific rollout date such as October 13 have been disclosed.
What Changes in October 2026 Is the Scope of Default Activation, Not a New Feature
Memory Integrity is not a feature being added to Windows for the first time. It has been in use since Windows 10, and on compatible clean installs of Windows 11 or Secured-core PCs, it was already enabled by default. Previous Microsoft documentation explicitly stated that automatic activation would not apply to upgrades of existing devices. Connecting this announcement to that prior state, the change is not the feature itself but an expansion of the scope of default activation via quality updates.
For reference, the previous automatic activation requirements included Intel 8th generation or later, AMD Zen 2 or later, and Qualcomm Snapdragon 8180 or later, for Windows 11 22H2 and above. x64 devices required at least 8GB of RAM and a 64GB or larger SSD, along with the installation of compatible drivers and virtualization enabled in the BIOS. However, Microsoft has not explained whether the new quality update will use this same requirements table as-is. What is clear about the new rollout is only that Windows will evaluate readiness, including hardware, compatibility, and performance.
There are two compatibility-focused safeguards here. First, devices where a user or administrator has already disabled Memory Integrity will not be changed automatically. Additionally, under Microsoft's recommended configuration, if a device experiences repeated boot-time crashes immediately after activation, Memory Integrity can be automatically disabled as long as the BootId remains below EnabledBootId+3. High-security configurations may choose not to use this recovery mechanism, so the same behavior is not guaranteed across all organizations.
What Memory Integrity Closes Is Not Undervolting but a Kernel Loophole
Another name for Memory Integrity is Hypervisor-Protected Code Integrity (HVCI). VBS creates a virtualized environment isolated from the main Windows system, and within it, HVCI inspects kernel-mode code. Because executable kernel memory cannot simultaneously be writable, this narrows the path by which an attacker could use a driver flaw as a foothold to write and then execute code.
Low-level hardware control tools are affected because some rely on drivers that cross this boundary. When HVCI is enabled, the Microsoft Vulnerable Driver Blocklist is also applied. This list targets drivers with known vulnerabilities, as well as signing certificates that have been used in malware and behaviors that could bypass Windows' security model. Rules are distributed both through quarterly updates and monthly Windows Updates.
A concrete example is WinRing0.sys and WinRing0x64.sys. In CVE-2020-14979, insufficient access control allowed user-mode applications to read and write to memory regions that should have been protected. This became an entry point for BYOVD (Bring Your Own Vulnerable Driver) attacks that exploit legitimately signed drivers, and older versions were bundled with various hardware monitoring and control tools. The issue is not the purpose of undervolting itself but the overly broad privileges reaching the kernel. This does not mean that current versions of the named tools are dangerous, nor that the software itself is malware.
The blocklist also has limitations. Microsoft does not guarantee that all vulnerable drivers will be blocked, and in some cases withholds adding rules for OS-bundled versions to avoid breaking compatibility. Therefore, while automatic HVCI activation adds a layer of defense, it is not a substitute for updating drivers and applications.
Not "All Undervolting Software Disabled": Intel XTU Splits Into Four Scenarios Depending on Conditions
For the impact on undervolting, Intel's product documentation is more accurate than Microsoft's feature descriptions. Intel Extreme Tuning Utility (Intel XTU) detects VBS activity, and whether it can launch depends on the CPU generation and the BIOS's Undervolt Protection (UVP) setting. Undervolt Protection is a feature that restricts the CPU from allowing voltage to drop below the BIOS-configured value or the default boot-time value.
| Intel CPU and Setting | Intel XTU with VBS/HVCI Enabled | Undervolting in Windows | Undervolting in BIOS |
|---|---|---|---|
| 12th Gen or later, Undervolt Protection enabled | Launches | Not possible | Possible |
| 12th Gen or later, Undervolt Protection disabled | Fails to launch | Not possible via XTU | Depends on device's BIOS implementation |
| 11th Gen or earlier | Fails to launch | Not possible via XTU | Possible |
| Microsoft's October 2026 rollout | Varies by device eligibility and settings | Availability for individual software not disclosed | No mention of resetting BIOS settings |
Cross-referencing Intel's primary documentation, Intel XTU with HVCI enabled splits into either "launches but runtime undervolting is not possible" or "fails to launch" depending on whether Undervolt Protection is enabled, even on 12th generation or later. On 11th generation or earlier, it fails to launch entirely, though manual BIOS adjustments remain available.
What these four scenarios show is that Intel XTU launching and being able to apply a negative voltage offset within Windows are not the same thing. On 12th generation or later, enabling Undervolt Protection ensures compatibility with VBS, but the CPU will not accept settings that would push voltage below the boot-time value. Meanwhile, Intel's table indicates that BIOS-level undervolting, runtime overclocking, and BIOS-level overclocking remain possible. The adjustment functionality as a whole is not eliminated—rather, the specific path of undervolting within Windows is closed off.
11th generation and earlier CPUs lack Intel's Undervolt Protection feature. Intel explains that when VBS is detected, XTU cannot access processor parameters and therefore fails to launch, though manual BIOS adjustments remain available. For third-party tools such as ThrottleStop, Microsoft has not published an app-specific compatibility list. Extending Intel XTU's conditions directly to all such tools would be premature.
There is also a security dimension to voltage changes. CVE-2019-11157, disclosed by Intel in December 2019, was a vulnerability in the voltage settings of certain CPUs stemming from inadequate condition verification, which could allow a local high-privilege user to escalate privileges or leak information. It carried a CVSS base score of 7.9, and Intel recommended updating to the latest BIOS provided by system manufacturers. While HVCI and Intel's Undervolt Protection are separate mechanisms, the current restrictions on undervolting in Windows reflect a history of attack surfaces involving both kernel privileges and voltage control.
Gaming Performance Doesn't Uniformly Decline—Three Things to Check Before and After the Update
While HVCI does carry a processing overhead, it cannot be said that "enabling it will reduce gaming performance by a fixed percentage." Microsoft explains that on Intel Kaby Lake or later, Mode-Based Execution Control, and on AMD Zen 2 or later, Guest Mode Execute Trap, provide efficient operation, while older CPUs rely on Restricted User Mode to compensate for the feature, resulting in a larger performance impact. Even in this announcement, performance remains part of the eligibility assessment, but no per-game or per-CPU degradation figures have been published.
There are three things worth checking. First, open "Core isolation details" under "Device security" in Windows Security to check whether Memory Integrity is enabled. On managed devices, Win32_DeviceGuard can be used, and msinfo32 is available for general checks. Second, if peripherals or tuning tools stop working after the update, check the CodeIntegrity Operational log for compatibility issues, commonly recorded as Event ID 3087.
Third, identify the problematic driver and look for a compatible version through Windows Update, the PC manufacturer, or the app vendor. Microsoft itself acknowledges that devices or applications may fail to function without a compatible driver. In some cases, disabling Memory Integrity may resolve the issue, but on Secured-core PCs, this removes the device from its protected state and weakens defenses against attacks that exploit vulnerable drivers.
If CPU tuning is necessary, it's worth separately considering: "Will Intel XTU launch?", "Is undervolting within Windows required?", and "Can BIOS-level adjustment serve as an alternative?" What matters most about the October 2026 update is, for devices Windows judges eligible, which specific paths involving outdated drivers and low-level tuning actually get closed off—and whether that functionality can be migrated to safely updated versions or BIOS-level settings.