If you’ve enabled Memory Integrity on a fleet of Windows devices and found yourself staring at a sea of red Attention Required tiles in Intune, there’s a good chance you’ve already met the Require UEFI Memory Attributes Table policy — usually without knowing what it does. The checkbox is buried three menus deep in the Settings Catalog, the in-product description is 40 words of jargon, and the only guidance most admins ever see is “turn it on for security.”
It’s more interesting than that. This setting is the difference between Hypervisor-Enforced Code Integrity working correctly and your help desk fielding bluescreens for a week. Here’s what it actually does, when to enable it, and when to leave it alone.
The 30-second primer
Windows has a security feature called Virtualization-Based Security (VBS). VBS uses the Hyper-V hypervisor to carve off a small, isolated region of memory that runs underneath the kernel, in something called Virtual Trust Level 1 (VTL1). The regular Windows kernel runs in VTL0 and cannot touch VTL1 memory, even if it’s fully compromised.
Hypervisor-Enforced Code Integrity (HVCI) — which Microsoft also markets as Memory Integrity and as Core Isolation in the Settings app — is the headline feature built on VBS. HVCI moves the code integrity checks (is this driver signed? is this kernel page executable?) into VTL1, where kernel-mode malware cannot disable them. It is one of the most effective mitigations against rootkits shipped in the last decade.
For HVCI to actually enforce page protections on firmware memory, the hypervisor has to know which regions of firmware are code (executable) and which are data (not executable). That information lives in a UEFI structure called the Memory Attributes Table (MAT).
No MAT → the hypervisor has to guess → guessing conservatively means either weakened protection or compatibility explosions.
That’s the entire problem this setting exists to solve.
The two values, honestly
In the Intune Settings Catalog, under Virtualization Based Technology → Require UEFI Memory Attributes Table, you get two options. Microsoft’s official descriptions are accurate but polite. Here’s the plainer version.
Require UEFI Memory Attributes Table. Windows will refuse to turn on HVCI unless the firmware exposes a MAT. You get full strength protection or you get no protection — no middle ground. This is the right choice for a fleet you know is modern.
Do not require UEFI Memory Attributes Table. Windows will attempt to enable HVCI even on firmware that doesn’t expose a MAT. This is the more forgiving setting — but “forgiving” is doing a lot of work in that sentence. On incompatible firmware, you may see bluescreens (commonly PAGE_FAULT_IN_NONPAGED_AREA or ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY), plug-in cards that stop working (older NICs, legacy storage controllers, some FPGA add-in boards), or silent degradation where HVCI reports as enabled but doesn’t actually protect firmware pages.
Neither value is “more secure” in the abstract. Require is more secure on devices that support MAT and no-op on devices that don’t (HVCI just fails to start). Do not require is less secure on modern devices and potentially destabilizing on old ones. The right answer depends on what you’re pointing it at.
When to enable it (and when not to)
A practical decision tree:
Enable “Require” when:
- Your fleet is Windows 11 certified hardware (MAT is part of the Windows 11 logo requirements, so any certified device has it)
- You’re standing up a new Autopilot ring and want to guarantee HVCI is either fully on or obviously off — no ambiguous middle state
- You have compliance requirements that demand verifiable HVCI enforcement (common in regulated industries)
Leave it unset, or explicitly “Do not require,” when:
- You have a mixed fleet with hardware from before ~2018 still in rotation
- You have specialized hardware (industrial, medical, point-of-sale) where the vendor hasn’t certified for Windows 11
- You use plug-in cards with drivers that predate the HVCI compatibility shake-out — test first
The worst outcome is enabling Require on a fleet where half the devices silently drop HVCI because of missing MAT support. You now have two populations — protected and not — and no easy way to tell them apart from a compliance dashboard. Either commit to the hardware refresh or stay on the permissive setting until you have.
Configuring it in Intune
The policy lives in the Settings Catalog, not under a named profile template. Skip the older Endpoint Protection templates — they don’t expose this setting.
- Intune admin center → Devices → Configuration → Create → New policy
- Platform: Windows 10 and later. Profile type: Settings catalog
- Name the policy something searchable.
VBS - Require UEFI MAT - [Ring]beatsHVCI Policy 2 - Add setting → search for Memory Attributes. The full path is Device Guard → Virtualization Based Technology → Require UEFI Memory Attributes Table
- Set the value to Require UEFI Memory Attributes Table
- Assign to a pilot group first — not All Devices, ever, on any VBS-adjacent policy
- Monitor for 48-72 hours before expanding rings
That’s the entire workflow. Nothing about it requires the 12-screenshot tour most guides give you.
Verifying it works
Don’t trust the Intune compliance tile alone — it reports on policy delivery, not on runtime behavior. On a target device, open msinfo32 and look at the bottom of the System Summary:
- Virtualization-based security should read
Running - Virtualization-based security Services Running should include
Hypervisor enforced Code Integrity
From PowerShell:
Get-CimInstance -ClassName Win32_DeviceGuard `
-Namespace root\Microsoft\Windows\DeviceGuard |
Select-Object VirtualizationBasedSecurityStatus,
SecurityServicesRunning,
CodeIntegrityPolicyEnforcementStatus
VirtualizationBasedSecurityStatus of 2 means running. SecurityServicesRunning containing 2 means HVCI is active. If you enabled Require and the device lacks MAT support, you’ll see VirtualizationBasedSecurityStatus of 1 (enabled but not running) — that’s the tell.
The compatibility gotchas nobody warns you about
Most guides stop at “click save.” These are the things that will actually eat your week:
SMM firmware bugs. System Management Mode is the oldest, gnarliest execution mode on x86. Some OEMs — especially on business laptops from 2016-2019 — shipped SMM handlers that don’t play well with HVCI’s page protections even when MAT is present. Symptoms are usually a sleep/resume hang, not an immediate crash. A firmware update from the OEM is the only real fix; there’s no Windows-side workaround.
Third-party antivirus. HVCI requires all boot-start drivers to be signed with a specific WHQL attestation. Older endpoint protection products sometimes ship drivers that technically pass signature validation but fail HVCI’s stricter memory hygiene checks. The driver gets blocked at boot and the product falls back to a degraded mode. Check your EDR vendor’s HVCI compatibility matrix before rolling out.
Nested virtualization. If you’re deploying to VMs — Hyper-V guests, Azure VMs, Windows 365 Cloud PCs — the host has to expose the right virtualization extensions. Azure Gen2 VMs support this; many on-prem Hyper-V setups don’t have nested virt enabled by default. The setting will deploy cleanly but VBS won’t actually run.
Older discrete GPUs and capture cards. Anything whose driver maps physical memory directly (some pro video capture cards, some legacy Quadro drivers, some PCIe FPGAs) can conflict with VBS memory isolation. The driver will either fail to load or operate in a reduced-capability mode.
The bottom line
“Require UEFI Memory Attributes Table” is not a security checkbox you turn on because turning it on sounds responsible. It’s a hardware compatibility gate that either guarantees HVCI is working properly or explicitly refuses to pretend it is. Both outcomes are fine; the dangerous middle ground is HVCI that looks enabled in a dashboard but isn’t actually enforcing anything.
If your fleet is modern, enable it, verify with Win32_DeviceGuard, and move on. If your fleet is mixed, stage the rollout by hardware generation, and don’t promote the policy out of your pilot ring until SecurityServicesRunning shows the right values on every device in scope.
Everything else — the screenshots, the scope tag ceremony, the assignments tab walkthrough — is Intune workflow that works the same way for every settings-catalog policy you’ll ever deploy. The part worth thinking about is the hardware sitting underneath it.
