🧱🪟💻ES - Memory Integrity and Credential Guard
Move code-integrity checks and stored credentials into a hypervisor-isolated room the running OS cannot reach, so a kernel-level attacker still hits a wall.
What this policy is about 🧱
Virtualization-based security (VBS) uses the CPU's own virtualization to carve out a small, isolated space that even the Windows kernel cannot read or modify. Two of the most valuable protections live in that space:
- Memory Integrity (HVCI) verifies that every driver and kernel module is properly signed before it is allowed to run, from inside the isolated space, so an attacker who reaches the kernel still cannot load malicious code into it.
- Credential Guard keeps derived credentials (NTLM hashes, Kerberos tickets) in that isolated space instead of normal LSASS memory, so even a successful in-memory credential dump comes back empty.
This policy enables VBS and both protections, locked in firmware.
Most defenses can be undone by whatever has the highest privilege on the machine. VBS changes the game: the protected space sits below the OS, so compromising the kernel is no longer enough to reach what is inside it.
Why this matters 🕵️
The two techniques VBS blocks, loading an unsigned kernel driver and dumping credentials from memory, are exactly the moves an attacker reaches for after the first foothold. Memory Integrity turns "I have kernel access" into "and I still cannot run my rootkit", and Credential Guard turns "I dumped LSASS" into "and there was nothing usable in it". Together they raise the cost of a local compromise from minutes to genuinely hard.
It layers with the rest of the hardening set: LSA Protection shields the LSASS process, Credential Guard makes sure the secrets are not sitting there to begin with.
🛠️ Configuration
Where: Intune admin center → Devices → Configuration → Create → Windows → Settings catalog → Device Guard.
| Setting | Value |
|---|---|
| Enable Virtualization Based Security | Enabled |
| Require Platform Security Features | Turn on VBS with Secure Boot |
| Virtualization Based Protection of Code Integrity (Memory Integrity) | Enabled with UEFI lock |
| Credential Guard Configuration | Enabled with UEFI lock |
| Assignment, include | All devices |
| Assignment, exclude | 🛡️🪟💻👈🔓⚙️Group - VBS Incompatible Devices |
The UEFI locks stop the protections being silently switched off; reversing them is a deliberate act, not a background change.
Caveats ⚠️
Memory Integrity is picky about drivers. HVCI refuses to run unsigned or incompatible kernel drivers, which is the point, but a device with an old printer, VPN, or peripheral driver can lose that hardware or fail to enable HVCI at all. Run the Microsoft driver-compatibility check on your standard images before a broad roll-out.
Credential Guard breaks a few legacy auth paths. Unconstrained delegation, MSCHAPv2/older RADIUS, and some third-party credential providers do not survive Credential Guard. Modern setups are fine; inventory the legacy ones first.
Hardware and performance. VBS needs a recent CPU with virtualization extensions and adds a small overhead. On capable business hardware it is negligible; on marginal machines, measure.
The escape hatch is the paired inverse. Devices that genuinely cannot run VBS (incompatible driver, unsupported hardware) go into the exception group and receive the Disable inverse, rather than loosening this for everyone.
License and reversibility. Included in Business Premium. Clean-revert on its own, though the UEFI-locked protections and the exception path make the paired inverse the proper way to reverse it on a specific device.
🔗 Related
- 🧱🪟💻🔓ES - Memory Integrity and Credential Guard - Disable: the paired inverse for devices that cannot run VBS.
- 🧱🪟💻ES - LSA Protection: the structural guard on the LSASS process itself.
- 🛡️🪟💻👈🔓⚙️Group - VBS Incompatible Devices: the documented exception group.
Put the crown jewels in a room the operating system cannot be tricked into opening. 🧱