What Windows is changing in October 2026
Microsoft says quality updates will start enabling Memory Integrity on more eligible Windows devices from October 2026. Some affected devices will also have virtualization-based security, or VBS, enabled as part of the change. The rollout will occur gradually rather than arriving as a single mandatory switch on a known date.
That distinction matters. Microsoft has not published a model-by-model eligibility list, readiness thresholds, rollout rings, a specific update number, or an estimate of how many PCs will be affected. The announcement is also not framed as a Windows 11-only policy, even though Windows 11’s hardware baseline and security posture are part of Microsoft’s readiness considerations.
Before enabling the protection, Microsoft says it evaluates such factors as hardware capability, compatibility, performance, Windows 11 system requirements, and recommended built-in protections. That is a meaningful safeguard, but it should not be read as a guarantee that every application, game, peripheral, or driver combination will behave identically after rollout.
There is another boundary likely to matter to enthusiasts and managed-PC users: Microsoft says existing user, administrator, and policy choices remain in effect. In particular, devices where Memory Integrity was previously disabled will not be automatically changed by this rollout. That does not answer every possible configuration question, but it directly undercuts the idea that Microsoft will indiscriminately override a previously disabled setting on every gaming machine.
Memory Integrity is HVCI, not a hidden Windows control
Memory Integrity is Microsoft’s user-facing name for Hypervisor-Protected Code Integrity, commonly abbreviated HVCI. It is a VBS feature: Windows uses virtualization to isolate code-integrity enforcement from the normal operating environment.
At a practical level, its job is to make it harder for untrusted or malicious kernel-mode code to get into the places it would need to compromise the system. It also limits certain kernel-memory allocations that could otherwise be useful to an attacker. This is not cosmetic hardening. Kernel-level compromise is especially serious because a malicious driver or kernel exploit can operate beneath many ordinary application-level protections.
Nor is the control hidden. On supported Windows installations, its documented location is:
Windows Security > Device security > Core isolation details > Memory integrity
That visibility is useful for PC owners who want to understand their present configuration before the staged rollout begins. It also helps separate two questions that are too often merged in performance discussions: whether Memory Integrity is active, and whether other VBS-related protections are also active.
The latter distinction is especially important because Microsoft says that, on some devices, its rollout will enable VBS as well. Since Memory Integrity itself depends on VBS, benchmarks that compare HVCI alone with HVCI plus broader VBS changes are not necessarily measuring the same thing.
Why performance can change at all
Security boundaries have costs. HVCI adds checks and isolation around kernel-mode code, and those operations can add overhead in workloads that make frequent system, driver, or kernel interactions. That does not mean every game will lose the same percentage of performance, or even exhibit an obvious reduction in ordinary play.
The size of the effect depends on several interacting factors:
- CPU generation and hardware support. Microsoft says Intel Kaby Lake and newer processors with Mode-based Execution Control, or MBEC, and AMD Zen 2 and newer processors with Guest Mode Execute Trap, or GMET, handle the feature better. Older CPUs depend on Restricted User Mode emulation, which Microsoft says produces a larger performance impact.
- Whether the game is CPU-limited or GPU-limited. At a low resolution with a very fast graphics card, the processor becomes the constraint and small CPU overheads are easier to expose. At higher resolutions or demanding visual settings, a GPU bottleneck can make the same overhead less noticeable.
- The game and its engine. Driver calls, scheduling behavior, render paths, and background workloads differ materially between titles.
- The exact security configuration. A test comparing VBS and HVCI together against both disabled is not interchangeable with one that changes only HVCI while everything else remains constant.
- Drivers and other software. Kernel-mode drivers are central to both the feature’s security purpose and its compatibility risk.
This is why a single average frame-rate number is a poor basis for a universal claim. Frame times may matter as much as average FPS, particularly in games where inconsistent delivery creates visible stutter despite a seemingly healthy average.
What the independent gaming tests actually show
The available independent testing provides useful bounds, not a definitive forecast for a particular PC.
One multi-CPU test measured VBS plus HVCI enabled against both protections disabled using an RTX 3090 at 1920×1080. That setup was deliberately intended to reduce GPU bottlenecks and make processor-side differences visible. Across its gaming suite, the reported geomean reductions ranged from 3.3% on a Ryzen 7 5800X to 5.7% on a Core i7-10700K, with a Core i7-11700K at 5.6% and a Ryzen 7 3800X at 4.1%. Individual games varied.
A separate CPU-limited test on a Ryzen 7 5800X paired with a Radeon RX 7900 XTX reported a 6% reduction in average FPS with HVCI active and an 8% worsening in frame times. It used 1280×720 specifically to create a maximum CPU-limited scenario, and its authors cautioned that the effect should be smaller when the GPU carries more of the load.
Taken together, these results support two conclusions that can coexist:
- Memory Integrity and related VBS configurations can impose measurable gaming overhead, especially in CPU-bound tests.
- Those test results do not prove that every modern gaming PC will lose 3% to 8%, or that a normal GPU-limited 1440p or 4K session will feel materially slower.
They also show why claims of a near-universal “very little” impact deserve qualification. A pair of games on one recent system can be valid evidence for that machine and those conditions, but cannot settle the question across processors, games, driver stacks, resolutions, or VBS configurations. Conversely, deliberately CPU-limited benchmarks are valuable stress tests, but they should not be presented as the everyday experience of every gamer.
Exact recent results sometimes cited for a Ryzen 5 7600X system — including very small differences in selected benchmarks and two games — cannot be independently corroborated from the supplied material. Even if those figures accurately describe that test setup, they would remain a narrow result rather than a general rule.
The compatibility risk is as practical as the FPS question
Performance is not the only consideration. Microsoft warns that some applications and hardware drivers may be incompatible with Memory Integrity. Such incompatibilities can cause affected software or hardware to malfunction. In rare cases, a system can fail to boot or encounter a blue-screen error after the protection is enabled or during enablement.
This warning is not a reason to assume a problem will occur on a current, well-maintained PC. It is, however, a reason to take driver maintenance seriously. Gaming systems often have an unusually broad collection of low-level components: GPU drivers, audio interfaces, RGB controllers, motherboard utilities, capture hardware, anti-cheat systems, emulation tools, virtualization products, and older peripheral software. The more kernel-connected software a system relies on, the more important it is to know whether vendors provide compatible drivers.
The security upside must also be part of the decision. Disabling a kernel protection solely to pursue an unverified performance gain creates a different kind of risk. The appropriate balance is not identical for everyone. A competitive player chasing maximum CPU-limited frame rates, a household PC used for general gaming, and an organization managing hundreds of endpoints may reasonably prioritize different outcomes.
What gamers should do before the rollout
The best preparation is to establish the current state of the PC rather than react to a future update headline.
First, check the Memory Integrity status in Windows Security through the Core isolation page. This tells you whether the setting is already enabled and avoids attributing pre-existing behavior to the October 2026 expansion.
Second, update Windows and obtain current drivers from the hardware and peripheral vendors you rely on. Microsoft’s documentation specifically identifies incompatible drivers as a possible source of problems. If Windows flags a driver incompatibility, treat that as a concrete maintenance issue rather than assuming the security feature itself is broken.
Third, players who care about consistent performance should create their own baseline. Use the same game version, graphics preset, resolution, driver version, background applications, and repeatable test area where possible. Record average FPS, but also pay attention to frame-time behavior and actual play. A 2% average difference may be hard to notice; recurrent stutter or instability is more consequential.
Fourth, distinguish a verified change from a coincidental one. Major quality updates, GPU driver updates, shader compilation, game patches, power settings, overlays, and background tasks can all affect benchmarks. A useful comparison changes one known variable at a time. That is particularly important here because the forthcoming rollout may involve VBS on some systems, not merely the visible Memory Integrity control in isolation.
Finally, users of work-managed PCs should remember that organizational policy may govern these settings. Microsoft explicitly says administrator and policy choices remain in effect, so an enterprise device may not behave like a personally managed gaming desktop.
A security rollout that needs careful framing
Microsoft’s planned expansion is a security-policy change with gaming implications, not a blanket anti-gaming switch. It begins in October 2026, proceeds gradually, and is limited by device eligibility and readiness checks. It does not automatically alter devices on which Memory Integrity was previously disabled, and it does not erase existing administrative or policy decisions.
The honest performance answer is conditional. Modern systems with the relevant hardware support may see little practical difference in many GPU-bound games. CPU-limited scenarios can show more substantial losses, with independent tests demonstrating average-FPS and frame-time effects beyond a trivial margin in some configurations. Older processors that must rely on emulation deserve particular caution.
For Windows users, the practical response is informed verification: know the current setting, keep drivers current, test the workloads that matter, and weigh any measured cost against a protection designed to defend the Windows kernel. That is more useful than either dismissing the concern or assuming one benchmark represents every gaming PC.