For gamers, the practical message is to understand the setting before the rollout reaches a device, rather than assume either a universal performance penalty or a universal problem-free upgrade. For IT administrators, the key point is that the change reinforces the importance of knowing which endpoints are already governed by security policy and which drivers can support the protection.
What Microsoft is changing in October 2026
Beginning in October 2026, Windows quality updates are set to start enabling memory integrity on eligible devices. Where virtualization-based security (VBS) is not already enabled, the rollout will also enable VBS.
This is an expansion of an existing Windows protection, not the arrival of a new Windows 11 feature. Memory integrity is available across Windows 10, Windows 11, and Windows Server 2016 or later. It was already enabled by default in certain circumstances, including qualifying clean Windows 11 installations and Secured-core PCs.
There is an important limit on what the announcement establishes. Microsoft has announced a start month, but not an exact October update date, KB number, rollout schedule, full eligibility matrix, or a definitive list of editions and Windows versions affected. The announcement refers broadly to “eligible devices”; it does not explicitly frame the quality-update expansion as Windows 11-only.
That lack of a published exhaustive matrix means users should not mistake the existing clean-install criteria for a complete description of the new rollout. They are useful context, but they are not a guaranteed pass-or-fail test for a system receiving an October quality update.
Why memory integrity exists
Memory integrity is also known as Hypervisor-Protected Code Integrity, or HVCI. It is a VBS feature designed to harden kernel-mode code integrity, one of the areas where Windows must be especially careful about what code is allowed to run.
In simplified terms, it uses virtualization-based protections to enforce rules around executable kernel memory. Executable kernel-memory pages are not allowed to be writable, and code-integrity checks must occur before pages can become executable. Those restrictions make certain forms of malicious or improperly trusted kernel code harder to run.
This is not merely an abstract hardening option. Kernel-mode drivers and code operate with substantial system privileges, which is why Microsoft’s compatibility checks are relevant. A security feature that increases scrutiny of low-level components can encounter driver issues on systems with incompatible drivers. The company says compatibility is one of the readiness signals it will consider before enabling the feature.
VBS and memory integrity should also not be treated as interchangeable labels. VBS is the broader foundation; memory integrity is one VBS security feature. The new rollout may activate both when VBS is not active already, so a user assessing performance or configuration changes should recognize that the security posture can involve more than one switch.
Eligibility is conditional, not a blanket switch
The most consequential detail in Microsoft’s plan is its conditional language. Windows will assess hardware capability, compatibility, and performance considerations before enabling memory integrity. That makes claims that every PC will be forcibly switched on in October inaccurate.
Microsoft’s published documentation for automatic enablement on eligible clean Windows 11 installations provides useful indications of the sort of conditions that matter. The documented requirements include:
- A supported processor
- At least 8GB of RAM on x64 systems
- A 64GB SSD
- Memory-integrity-compatible drivers
- Virtualization enabled in the system BIOS
These conditions are explicitly documented in the clean-install context. They do not fully define the distinct quality-update rollout, particularly for upgraded systems. A PC matching those specifications should not be presumed certain to receive the change, while a system outside the published clean-install list should not be presumed to be part of or excluded from the quality-update rollout without further Microsoft detail.
Equally important, Microsoft says current administrator and user decisions remain effective. If memory integrity has already been disabled on a device, this expansion is not supposed to automatically reverse that choice. Existing policies also remain in place. That should reduce the likelihood of a policy-managed fleet being silently altered by the consumer-facing interpretation of the announcement.
The gaming-performance question needs context
Memory integrity has long been associated with performance concerns, especially in games that are constrained by CPU performance. There is evidence for a real impact in some configurations, but the evidence does not support a single percentage or an assumption that every player will notice the same result.
Microsoft’s own current documentation identifies processor generation as an important factor. On Intel systems, Kaby Lake or later processors with Mode Based Execution Control (MBEC) support are better suited to this workload. On AMD systems, Zen 2 or later processors with GMET capabilities are similarly better positioned. Older processors rely on Restricted User Mode emulation, which Microsoft says has a larger performance impact.
That does not mean newer CPUs eliminate the cost or that older machines necessarily become unusable for gaming. It means the hardware implementation changes the trade-off, and older systems deserve closer attention when assessing any before-and-after change.
Historical independent testing illustrates the range. A 2021 test across four desktop CPU platforms found HVCI reductions of roughly 3.3% to 5.7% in a gaming geometric mean. Its use of an RTX 3090 at 1080p was intended to reduce GPU bottlenecks and reveal CPU-side differences. That methodology is useful for exposing a potential penalty, but it is not representative of every game or every player’s graphics settings.
A separate 2021 ten-game test on a Core i7-12700KF found a 7% average-frame-rate deficit and a 15% deficit in 1%-low results with VBS enabled in its comparison. The 1%-low figure is especially relevant because it relates to worse short-term frame-rate dips, which can be more noticeable than an average-frame-rate change. Yet that test also cautioned that more GPU-limited conditions might reduce the impact to around 5%.
These are historical measurements, not forecasts for the October 2026 update. Windows builds, firmware, drivers, CPUs, graphics cards, games, resolutions, and rendering settings all influence results. More importantly, a system that is GPU-limited at a higher resolution may mask much of a CPU-side overhead, while a high-refresh-rate player using lower settings to maximize frame rate may be more exposed to it.
The sensible conclusion is neither “memory integrity hurts all gaming” nor “the effect is always negligible.” The credible conclusion is that the effect is configuration-dependent, can be more important on older processor designs, and may be most visible in CPU-limited workloads or in frame-time-sensitive play.
How to check the setting on a Windows PC
Users can see the current state of memory integrity in the Windows Security app:
Windows Security > Device security > Core isolation details > Memory integrity
That location is the useful first stop after an October quality update, particularly for users who want to understand whether their device was part of the expansion. It also gives users an established location to change the setting.
Changing it should be a considered security decision, not a reflexive gaming tweak. Disabling memory integrity removes the protection’s kernel code-integrity hardening, even if a particular benchmark suggests a performance gain. The right balance depends on the device’s age, workload, driver state, exposure to untrusted software, and the value placed on security protections versus the potential for higher or steadier game performance.
There is no verified current Microsoft consumer instruction in the available material advising gamers to temporarily turn memory integrity off and then turn it back on after play. A report has attributed such advice to an older Microsoft support page, but that page is no longer available in a form that confirms the recommendation, and the new rollout announcement does not repeat it. Users should therefore avoid treating that reported guidance as current official policy.
What players should do before drawing conclusions
A methodical approach is more useful than reacting to the setting’s existence alone.
First, check whether memory integrity was already active. Many machines may have had it enabled well before the October expansion, so a performance issue that predates the update is unlikely to be explained by the rollout itself.
Second, consider the system profile. An older processor that lacks the newer hardware capabilities Microsoft highlights is a more plausible candidate for a noticeable overhead than a newer platform. Conversely, a system limited chiefly by GPU performance may show little measurable difference in a particular game.
Third, separate one game’s behavior from a broad claim about Windows. Games differ sharply in whether they are CPU-bound, GPU-bound, or prone to frame-time swings. A small average frame-rate change can coexist with a more perceptible change in low-frame-rate behavior, while another title may show little practical movement.
Finally, be cautious about assuming that a device did or did not qualify based solely on RAM, storage, or processor generation. Compatible drivers, virtualization configuration, and Microsoft’s undisclosed readiness assessment are also part of the picture.
Implications for managed Windows environments
For organizations, Microsoft’s preservation of existing policy decisions is significant. Administrators already have documented management routes through Intune and configuration service provider controls, Group Policy, Registry settings, and App Control. That means the expansion should be evaluated as part of an existing endpoint-security baseline rather than handled as an ad hoc user preference.
The operational challenge is likely to be driver readiness and exception management. Memory integrity’s focus on kernel-mode code makes low-level driver compatibility material to both security and stability. IT teams with hardware-dependent applications or specialized peripherals should know their current policy state and compatibility position before broad update deployment, rather than rely on assumptions about device eligibility.
Microsoft has not disclosed how many previously off but otherwise eligible systems will be switched on, how individual readiness decisions will be surfaced to users, or which rollout waves will apply. Those unknowns leave room for follow-up guidance as October approaches.
A security upgrade with a real trade-off
The October 2026 expansion is best understood as a targeted security hardening effort, not a universal performance regression. Memory integrity raises the bar for kernel-mode code execution, and Microsoft will use hardware, compatibility, and performance signals before enabling it. Existing disabled settings and management policies are intended to remain respected.
For the majority of users, the appropriate response is awareness: check the setting, understand the device’s hardware and driver situation, and assess any claimed game-performance change in the context of the actual workload. For players on older CPUs or those pursuing maximum frame rates in CPU-limited games, the security-performance balance may deserve more careful testing. For everyone else, broad claims based on a few historical benchmarks should not overshadow the purpose of the feature: reducing risk in one of Windows’ most sensitive execution environments.