Memory Integrity Shows “Off” in Windows 11 - Here's What…

Open Windows Security, click Device security › Core isolation, and there it is: Memory integrity, switched off. No error code, no red banner - just a grey toggle sitting in the "Off" position. For most people that's the entire investigation. Flip it on, close the window, done.

Except sometimes it isn't done. Sometimes the toggle refuses to move, or it moves and then quietly reverts to Off after the next reboot. Those two outcomes look identical at first glance but come from completely different causes - and the fix for one does nothing for the other.

The short version

Memory integrity is a Windows 11 protection that stops malicious code from being inserted into the most trusted, kernel-level part of the operating system. It shows "Off" for one of two very different reasons: either nobody has turned it on yet (a one-click fix), or Windows tried to turn it on and refused because a currently-loaded driver failed its compatibility check (not a one-click fix - it requires finding and dealing with that driver). This post shows you how to tell which situation you're in within about 30 seconds, walks through the easy fix, and points you to the two deeper EndpointWeekly guides for the driver-blocked case and for when the whole feature refuses to start at all.

The problem: a toggle with no error message

Here is what most people actually see. Not an error, not a warning icon - just a switch in the Off position and two lines of description underneath it.

Windows Security

Device security › Core isolation

Memory integrity

Prevents attacks from inserting malicious code into high-security processes.

Off

Two people can be looking at that exact same screen and be in completely different situations. One of them has a device that has simply never had this feature turned on - clicking the switch will just work. The other has a device where Windows itself turned this off, on purpose, because something already installed on that machine failed a safety check. Clicking the switch for that second person either does nothing, or briefly appears to work and then reverts.

Note: "Memory integrity" and "HVCI" (Hypervisor-enforced Code Integrity) are the same feature under two names. Windows Security's UI calls it memory integrity; the registry, Group Policy, and most technical documentation call it HVCI. This post uses both interchangeably, matching whichever the section is talking about.

Why it happens: what memory integrity actually protects, and the two ways "Off" happens

To understand why the toggle behaves the way it does, it helps to know what it's actually doing - not just "a security setting," but the specific problem it closes off.

Windows runs some code in kernel mode, the most trusted, least restricted part of the operating system. Device drivers are the most common thing running there. If an attacker manages to get malicious code to run in kernel mode - often by exploiting a vulnerable but otherwise legitimate driver - that code can tamper with almost anything on the machine, including the security software meant to catch it.

Memory integrity closes that door using virtualization-based security (VBS). VBS uses the same hardware virtualization your CPU uses for running virtual machines to carve out a small, isolated region of memory that even the Windows kernel itself cannot directly touch. Memory integrity moves the job of verifying that kernel-mode code is trustworthy into that isolated region. A compromised kernel can no longer lie to the checker, because the checker isn't running anywhere the compromised kernel can reach.

Tip: Think of it like a bank keeping the vault combination with a separate security company instead of the branch manager. If someone takes over the branch, they still can't get into the vault, because the thing that verifies the combination was never inside the branch to begin with.

That protection depends on VBS actually being available and running underneath it - which is where the two different "Off" states come from:

What's really going on	What you'll see	Is the toggle usable?
Never turned on - default state on most consumer PCs and many enterprise images	Off, toggle is clickable	Yes - flip it, reboot, done
Windows auto-disabled it after a loaded driver failed its compatibility check	Off, may say "incompatible drivers" and offer a scan, or may just be Off with no explanation	No - reverts or won't move until the driver is dealt with
VBS itself can't start (firmware virtualization, Secure Boot, or hypervisor prerequisites not met)	Off, and the whole Core isolation page may look unusually empty or the toggle is greyed out entirely	No - nothing above VBS can turn on until VBS itself starts

Gotcha: Windows Update itself can cause the second scenario without you touching anything. If a new driver ships that hasn't been validated against memory integrity's requirements, or an existing driver on your machine is later found to be unsafe, Windows can turn memory integrity off automatically to keep the machine bootable - and it doesn't always surface a clear notification when it does.

How to verify: which "Off" do you actually have

Before trying anything, find out which row of that table you're actually in. This takes one command.

Windows PowerShell

PS> Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object AvailableSecurityProperties, SecurityServicesConfigured, SecurityServicesRunning AvailableSecurityProperties : {1, 2, 3, 5, 7} SecurityServicesConfigured : {} SecurityServicesRunning : {}

Here is how to read that output. AvailableSecurityProperties lists what your hardware and firmware are actually capable of - if 2 (Secure Boot) and 3 (DMA protection) appear there, your hardware can support memory integrity. SecurityServicesConfigured lists what you've asked Windows to turn on - an empty set here means nobody has ever configured it, which is the easy "never turned on" case. SecurityServicesRunning lists what's actually running right now - if this is empty while SecurityServicesConfigured shows 2 (the code for HVCI), that's the second case: you asked for it, but it isn't running, which almost always means a driver blocked it.

Watch out: A quicker but less reliable check is just re-opening Core isolation and reading whatever message sits under the toggle. Don't stop there - that message doesn't always appear even when a driver genuinely is the blocker, and its absence is not proof you're in the easy case.

If SecurityServicesConfigured is empty, skip ahead to the fix below - you're in the simple case. If it shows a value but SecurityServicesRunning doesn't match it, you have a blocked driver, and the right next stop is our deeper guide: Memory Integrity will not turn on: finding the incompatible driver, which walks through identifying the exact driver by name and path. If AvailableSecurityProperties doesn't even list Secure Boot or virtualization support, the problem is one level further down, and Virtualisation-based security will not start: the firmware, hypervisor and licensing prerequisites covers that chain end to end.

The fix: turning it on, three ways

If you confirmed you're in the simple case, here are the three ways to turn memory integrity on, depending on who manages the device.

On your own PC, through Settings

Windows Security › Device security › Core isolation details

Open Windows Security from the Start menu.
Select Device security in the left-hand list.
Under Core isolation, select Core isolation details.
Switch Memory integrity to On.
Restart the device when prompted - the change does not take effect until after a reboot.

Across a fleet, through Intune (CSP)

Both the underlying VBS setting and memory integrity itself are controlled via CSP, and they need to be considered together since HVCI depends on VBS being on.

Setting	CSP (Intune)	Value to set
Turn on VBS	`./Device/Vendor/MSFT/Policy/Config/DeviceGuard/EnableVirtualizationBasedSecurity`	1 (on)
Memory integrity (HVCI)	`./Device/Vendor/MSFT/Policy/Config/VirtualizationBasedTechnology/HypervisorEnforcedCodeIntegrity`	1 (on, UEFI-locked) or 2 (on, unlocked)

Sign in to the Intune admin center.
Go to Devices › Configuration › Create › New policy.
Choose platform Windows 10 and later, profile type Settings catalog.
Search for and add Virtualization Based Security and Hypervisor Enforced Code Integrity from the Device Guard and Virtualization Based Technology categories.
Set both to enabled, choose an unlock mode for HVCI (see the callout below), and assign to your target device group.

Gotcha: Setting HVCI to UEFI-locked (value 1) means it cannot be turned off remotely afterward without also removing the lock through firmware - useful against tampering, painful if you need a fast rollback for a compatibility issue. Value 2 (unlocked) stays fully remotely manageable. Pick based on how confident you are that nothing in your fleet will need HVCI turned back off in a hurry.

Across a fleet, through Group Policy

Open gpmc.msc and either edit an existing GPO or right-click the target OU and select Create a GPO in this domain, and Link it here.
Edit the GPO, then navigate to Computer Configuration › Administrative Templates › System › Device Guard.
Open Turn On Virtualization Based Security, set it to Enabled.
Under Virtualization Based Protection of Code Integrity, choose Enabled with UEFI lock or Enabled without lock.
Select OK, then let the policy apply on the next Group Policy refresh (or run gpupdate /force to apply it immediately for testing).

Note: This is the same setting most fleets already interact with when preparing for Microsoft's October 2026 auto-enablement change - if you've already configured this policy in Intune or GPO ahead of that rollout, you don't need to do it again here.

Proof it worked

After the reboot, run the same check from earlier. A healthy, successfully-enabled device shows matching values in both fields.

Windows PowerShell - after enabling and rebooting

PS> Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object SecurityServicesConfigured, SecurityServicesRunning SecurityServicesConfigured : {2} SecurityServicesRunning : {2}

This is what good looks like: 2 is the code for HVCI, and it now appears in both the "configured" list and the "running" list. If SecurityServicesConfigured shows 2 but SecurityServicesRunning comes back empty after a full reboot, you've moved from the easy case into the driver-blocked case covered in the linked guide above - the setting was accepted, but something is still stopping it from actually starting.

Tip: You can also confirm visually in Windows Security - Core isolation details will show Memory integrity as On, with no "Review incompatible drivers" link underneath it.

References

Enable virtualization-based protection of code integrity - Microsoft Learn - the official explanation of memory integrity/HVCI, its requirements, and deployment options.
Core isolation - Microsoft Support - the consumer-facing explanation shown from Windows Security itself.
Virtualization-based security (VBS) - Windows Hardware Dev Center - the underlying VBS mechanism memory integrity is built on.

Related on EndpointWeekly

Memory Integrity will not turn on: finding the incompatible driver, and what the vulnerable driver blocklist actually blocks - for when the toggle won't stick because of a specific driver.
Virtualisation-based security will not start: the firmware, hypervisor and licensing prerequisites in the order Windows checks them - for when the Core isolation page itself looks broken or empty.
Windows Will Auto-Enable Memory Integrity in October 2026 - Decide Now, or Windows Update Will Decide For You - what changes fleet-wide once Microsoft starts turning this on by default.

Memory Integrity Shows “Off” in Windows 11 - Here's What That Actually Means