Core Isolation and Memory Integrity in Windows 11

Two decades ago, the idea that Windows should stop third-party security software from reaching into the kernel was contentious enough to trigger public accusations of anti-competitive behaviour. Today it is simply how Windows works, and Microsoft is going further: moving anti-virus products out of the kernel altogether.

This guide explains what is actually protecting the Windows 11 kernel in 2026, what you control, and what changed in 2026 for anyone still running old drivers.

Kernel patch protection: the rule that started it

Kernel patch protection arrived with Windows Server 2003 SP1 on x64 systems. Microsoft's original documentation is blunt about the policy: 64-bit Windows does not allow the kernel to be patched except through authorised Microsoft hotfixes. Protected structures include the system service dispatch tables, the interrupt descriptor table and the global descriptor table.

The reason it applied to x64 and not x86 is worth knowing, because it explains a lot about how Microsoft makes these decisions. Microsoft discouraged kernel patching on 32-bit Windows but did not block it, because doing so "would break compatibility for a significant amount of released software". On x64 there was no large installed base yet — so the restriction could go in before anyone came to depend on the alternative.

That policy is not history. Current driver documentation still lists four specific prohibitions: a driver must not modify kernel code at run time, implement its own stacks, modify the IDT or GDT, or modify undocumented kernel data structures.

Driver signing, and what changed in April 2026

Since Windows 10 version 1607, a new kernel-mode driver must be signed through the Microsoft hardware developer portal, and an EV code-signing certificate is required just to open the account. For years there were standing exceptions that kept much older, cross-signed drivers loading.

Those exceptions have now largely closed. Microsoft announced in March 2026 that it is removing kernel trust for drivers signed by the deprecated cross-signed root program, so that by default only drivers signed through the current hardware certification programme load. It applies to Windows 11 24H2, 25H2 and 26H1 and Windows Server 2025 from the April 2026 update, and to future releases.

Two details matter more than the headline. First, Microsoft keeps an explicit allow list so a limited number of widely used cross-signed drivers keep working — this is not a blanket block. Second, the policy arrives in evaluation mode: the kernel audits driver loads instead of blocking them, and a machine only switches to enforcement after meeting thresholds (250 system hours, plus a small number of restarts). If an untrusted cross-signed driver is seen during that window, the clock resets and the machine stays in evaluation mode.

The practical consequence is that nobody can tell you in advance whether your PC will start blocking an old driver, because the answer depends on what your own machine audits. If you depend on ageing hardware with drivers signed long ago, that is the thing to test.

What Memory integrity actually does

Virtualisation-based security uses the Windows hypervisor to build an isolated environment that becomes the root of trust for the operating system — on the working assumption that the kernel itself can be compromised. That environment is a more privileged virtual trust level than the one the normal kernel runs in.

Memory integrity runs kernel-mode code integrity inside it. The distinction that trips people up is this: Microsoft's security documentation is explicit that HVCI moves the code-integrity decisions into the hypervisor while all kernel code still executes in the normal kernel. Nothing is being run inside a VM. What changes is who gets to approve a driver — and it is no longer code that malware in the kernel can reach.

It also enforces a write-xor-execute rule on kernel memory: a page becomes executable only after passing a code-integrity check, and executable pages cannot then be written to.

Is it on? The answer most articles get wrong

Microsoft's OEM documentation is precise, and the precision matters: auto-enablement applies to clean installs, not to upgrades of existing devices. So a PC that has been carried forward through upgrades can be fully patched and still have Memory integrity off — that is expected, not a fault.

There is a hardware bar for automatic enablement too: broadly Intel 8th generation or later, AMD Zen 2 and newer, and Qualcomm Snapdragon 8180 and newer. Intel 11th-generation desktop processors are explicitly excluded from the current auto-enablement logic even though Microsoft otherwise recommends them for the feature. Secured-core PCs are a separate category and ship with it on.

Elsewhere Microsoft describes the real-world position more loosely — on by default for most new Windows 11 devices. Both statements can be true at once, because an OEM can set these keys either way in its own image. If you want to know about a specific machine, check it rather than assume.

Checking it, and fixing a toggle that refuses

The setting lives at Windows Security > Device security > Core isolation details. From Windows 11 22H2 onward, Windows Security shows a dismissible warning when Memory integrity is off.

For a definitive answer rather than a UI reading, query it:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

In the result, SecurityServicesRunning containing 2 means Memory integrity is running. The state is also readable in msinfo32 under "Virtualization-based Security Services Running".

When the toggle will not stay on, the cause is nearly always an incompatible driver already installed. Blocked drivers are logged in Event Viewer under Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational, generally as event ID 3087. Microsoft's own advice is to get an updated driver from the manufacturer or remove the device.

The vulnerable driver blocklist, which is separate

Distinct from Memory integrity, Microsoft's vulnerable driver blocklist has been on by default for all devices since the Windows 11 2022 update, and is force-enforced whenever Memory integrity, Smart App Control or S mode is active. It is refreshed quarterly, with further updates in monthly Windows updates.

Be aware of one honest limitation Microsoft states openly: the blocklist shipped in Windows is deliberately a subset of the published list, because some blocks would break functionality, and Microsoft does not guarantee that every vulnerable driver is blocked.

The direction of travel: security software leaving the kernel

In July 2024 a faulty update to a kernel-level security product took down machines worldwide. Microsoft's response, the Windows Resiliency Initiative, set out a goal that would have been unthinkable during the 2006 argument: anti-virus and endpoint protection running in user mode, like ordinary applications, rather than in the kernel. The reliability case is fault containment — a bug takes down the security app instead of Windows.

Be careful with the status. As of Microsoft's November 2025 update, the Windows endpoint security platform was still described as a private preview with a set of partner vendors, and we have found no Microsoft statement since announcing general availability. Vendors publicly associated with the work include Bitdefender, CrowdStrike, ESET, SentinelOne, Sophos, Trellix, Trend Micro and WithSecure.

One piece has shipped, though, and it is a concrete example of the same idea: Windows Protected Print mode means no printer drivers are installed in the kernel at all.

Which brings the 2006 argument full circle. The objection then was that keeping third parties out of the kernel would make Windows less secure because vendors could not do their job. The direction two decades later is that doing that job from inside the kernel was the problem.