Memory integrity: what it protects, and what it breaks
HVCI is one of the strongest protections Windows ships, and one of the easiest to switch off by accident. What it does, why drivers fight it, and how to turn it on without losing hardware.
Memory integrity — Hypervisor-protected Code Integrity, or HVCI — is the single most valuable security feature most Windows machines already have and never turn on.
It is also the one most likely to leave you with a device that no longer works, which is why so many guides tell you to enable it and then go quiet about the consequences.
What it actually does
Normally, code running in the Windows kernel is trusted because it is in the kernel. If an attacker gets a foothold there, they can modify kernel memory freely — including the structures that decide what code is allowed to run.
HVCI moves that decision somewhere the kernel cannot reach. Code integrity checks run inside a hypervisor-isolated environment, so even kernel-level code cannot rewrite the rules about which kernel code is permitted to execute.
The practical effect: an attacker who achieves kernel access cannot simply load an unsigned driver of their choosing. This shuts down a large family of rootkits and the "bring your own vulnerable driver" technique that modern ransomware crews rely on.
Why it breaks things
HVCI requires every driver to meet stricter rules than Windows normally enforces — no memory that is both writable and executable, correct section alignment, and no dynamic code generation in kernel space.
Plenty of legitimate drivers violate these rules, particularly:
- older printer and scanner drivers
- virtualisation and anti-cheat components
- USB peripherals shipping drivers written before 2018
- some VPN and packet-capture drivers
If one of those is installed, Windows will either refuse to enable HVCI or enable it and leave the device dead. That is not a bug; it is the feature working.
Turn it on the careful way
Check what would block it first. Windows Security lists incompatible drivers under Device security → Core isolation, and it names them. Do that before changing anything.
Update the offending driver rather than abandoning the feature. Most vendors shipped HVCI-compatible versions years ago. The driver on your machine is often simply old — Windows Update will happily leave a 2011-era driver in place indefinitely if the device works.
Know your way back. If a device stops working after enabling memory integrity, you can turn it off again from the same screen. Write down what you changed before you change it.
The trap that catches administrators
Here is the part almost nobody documents, and it is worth reading twice.
Taking explicit policy control of virtualisation-based security disables every VBS service you do not explicitly name.
If HVCI is running by Windows default — with no policy key set at all — and you then write a policy enabling some other VBS feature, HVCI stops. Not because you disabled it, but because you took manual control and did not list it.
We did exactly this to one of our own machines. A script enabling one VBS feature wrote policy at the VBS root naming only that feature. After the next reboot, memory integrity was off, Windows Security raised an alert, and the feature we were trying to enable had not started either. Strictly worse than before we touched it.
The lesson generalises well beyond VBS: when you move a setting from "default" to "explicitly managed", you become responsible for everything that setting governs, including the parts that were working fine on the default.
Verify, do not assume
After a reboot, check what is actually running rather than what you asked for:
Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard |
Select-Object SecurityServicesConfigured, SecurityServicesRunning
SecurityServicesRunning containing 2 means memory integrity is genuinely active. SecurityServicesConfigured tells you only what was requested. The gap between those two fields is where most misconfiguration hides.
OmniGuard watches this continuously, because a platform can silently lose kernel code-integrity enforcement after a driver install or a policy change, and nothing in the everyday Windows interface will tell you.