Virtualisation-based security will not start: the firmware, hypervisor and licensing prerequisites in the order Windows checks them

You push a policy to turn on Memory Integrity, or Credential Guard, or System Guard Secure Launch. A week later the compliance report says a few hundred machines still have it off. You remote onto one, open Windows Security, go to Device security, and the toggle is either off, or greyed out, or says it is managed by your administrator. Nothing on that screen tells you why. So somebody starts turning things off at random: Secure Boot, the policy itself, the Hyper-V feature, a driver. That is how a one-line firmware problem turns into a three-day outage.

The problem: the Settings UI knows and will not tell you

The symptoms all look different and all have the same root. Here is what lands in the ticket queue.

• Memory Integrity is off and the toggle does nothing when you click it.
• Memory Integrity is on in policy but the device reports it as not running.
• Credential Guard shows as configured but not running, and lsaiso.exe is nowhere in Task Manager.
• Firmware protection (Secure Launch) is missing from Core isolation entirely.
• The Windows Security taskbar icon carries a yellow warning badge that users keep dismissing.
• Your Intune compliance policy for a hardware-security setting reports Not compliant with no reason.

All six are the same sentence: something below the feature did not start. VBS is that something. Every one of those features is a tenant inside VBS. If the building does not open, no tenant opens either, and the Settings page only ever reports on the tenant.

Two consequences fall straight out of that definition, and both surprise people.

First, VBS needs the Windows hypervisor, which means it needs the same processor features a hypervisor needs. Second, VBS does not need the Hyper-V role. You do not install a Windows feature to get VBS. The hypervisor is loaded by the boot loader before Windows starts, whether or not you ever create a virtual machine. People uninstall the Hyper-V optional feature expecting VBS to survive, and it does. People disable the hypervisor in the boot configuration expecting only Hyper-V to stop, and VBS dies with it.

Why it happens: the prerequisite chain in evaluation order

Windows checks the prerequisites in a fixed order during boot. Knowing that order is the entire diagnostic technique, because a failure at link three makes every check after it meaningless.

The boot chain, file by file

These are the binaries involved, in the order they run. Every one lives in C:\Windows\System32 on a client install.

Only one of hvix64.exe and hvax64.exe is needed on any given machine, so seeing one of the pair missing is normal, not a fault.

The nine links, in the order they are evaluated

The hardware and firmware requirements, and which are hard

Microsoft publishes a requirements table for VBS. It is worth separating the items that block VBS outright from the items that are guidance to OEMs.

The hypervisor launch type

The Boot Configuration Data store holds a per-boot-entry option called hypervisorlaunchtype. Microsoft documents exactly two values: Off and Auto. Auto is the shipping default. Off tells the OS loader not to launch the hypervisor. There is a matching option, vsmlaunchtype, with the same two values, which controls Virtual Secure Mode specifically.

This single value has caused more silent VBS failures than any hardware fault, because a decade of performance guides, game anti-cheat advice and forum posts all end with the same instruction: run bcdedit /set hypervisorlaunchtype off. Users run it. Imaging scripts inherit it. Reference images carry it. And a machine with that value set will report VBS as enabled but not running forever, regardless of how many policies you push at it, because policy is evaluated after the loader has already declined to start the hypervisor.

The licensing and edition angle

This one confuses people because the answer is different for VBS and for the things inside it.

Microsoft's Windows security licensing and edition reference lists Virtualization-based security (VBS) as supported on Windows Pro, Windows Enterprise, Windows Pro Education and Windows Education, and available under Pro licensing as well as Enterprise E3/E5 and Education A3/A5. The same is true of Hypervisor-protected Code Integrity. So there is no edition gate on VBS itself, and no edition gate on Memory Integrity.

Credential Guard is different. The same reference marks it unsupported on Windows Pro and Windows Pro Education, and supported only on Enterprise and Education. The DeviceGuard CSP reference agrees and goes further: the EnableVirtualizationBasedSecurity node is listed for Pro, Enterprise, Education and IoT Enterprise, but RequirePlatformSecurityFeatures and LsaCfgFlags are listed for Enterprise, Education and IoT Enterprise only, with Pro explicitly excluded.

The practical effect: push a single Device Guard profile to a mixed fleet and the Pro machines will accept the VBS switch and quietly ignore the Credential Guard part. That reads on the device as Credential Guard configured but not running, which looks exactly like a hardware failure and is not one.

How to verify: reading which link actually failed

There are five places to look, and they answer different questions. Take them in this order.

1. Win32_DeviceGuard, and how to read all five enumerations

This is the authoritative source. It is a WMI class in its own namespace, and Microsoft's guidance is to query it from an elevated PowerShell session. The command below returns one instance describing both what the hardware can do and what is currently running.

Now the part everybody gets wrong. These are lists of flags, not single numbers, and each number is a property name. Here are the meanings Microsoft publishes, in full.

AvailableSecurityProperties - what this platform has. RequiredSecurityProperties - what the current policy demands. The values mean the same thing in both, except that value 8 is documented only for Available.

SecurityServicesConfigured and SecurityServicesRunning - which tenants are asked for, and which are actually inside VBS right now. Same numbering for both.

VirtualizationBasedSecurityStatus - the single most useful number on the whole device. Only three values are documented.

Two more properties on the class share an enumeration: CodeIntegrityPolicyEnforcementStatus and UsermodeCodeIntegrityPolicyEnforcementStatus, where 0 is Off, 1 is Audit and 2 is Enforced. VirtualMachineIsolationProperties uses 1 for AMD SEV-SNP, 2 for Virtualization-based Security and 3 for Intel TDX. Version has exactly one valid value, 1.0.

2. msinfo32 and systeminfo

System Information shows the same data in English at the bottom of the System Summary page, which makes it the fastest way to read a device over a screen share. Two of the field names are named explicitly in Microsoft's own instructions: the Credential Guard documentation tells you to confirm Credential Guard appears next to Virtualization-based Security Services Running, and the Secure Launch documentation tells you to look under Virtualization-based Security Services Running and Virtualization-based Security Services Configured. The remaining rows in that block, observed on a live Windows 11 device and matching the text systeminfo prints, are Virtualization-based security (carrying the status), Required Security Properties, Available Security Properties and SMM Isolation Level.

systeminfo prints the identical block as text, which is far easier to collect at scale than a GUI. The command below filters it down.

3. The registry

Two trees matter and they are not the same thing. Control\DeviceGuard is the live configuration Windows reads. SOFTWARE\Policies\Microsoft\Windows\DeviceGuard is the managed copy that Group Policy or the DeviceGuard CSP writes. Comparing them tells you whether your policy actually landed.

Credential Guard is the exception to the tree above: its live value is LsaCfgFlags under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa, with 1 for UEFI lock and 2 for no lock. There is a second LsaCfgFlags in the policy hive under DeviceGuard. Microsoft notes that deleting these values may not disable Credential Guard, and that they must be set to 0.

4. The Boot Configuration Data store

Reading the boot entry needs an elevated prompt. This is a read; the /enum verb changes nothing.

5. Event Viewer

Microsoft does not publish a complete VBS event ID catalogue. It does publish one small set, and that set is exactly the one that separates a VBS failure from a Credential Guard failure. Open Event Viewer, go to Windows Logs then System, and filter the event source to WinInit.

Event 15 is worth memorising. It says, in Microsoft's own words, that the tenant was configured and the building was not open. If you see 15, stop investigating Credential Guard and go back to link 5 and link 6.

Beyond that documented set, three log channels exist and carry relevant records, but their event IDs and message text are observed and undocumented. Read them for context and do not build fleet detection on them.

Surfaces that genuinely do not apply

Two entries on the usual checklist are honestly not relevant here, and saying so is more useful than inventing something.

There is no text log file for VBS. No .log under %WINDIR% records hypervisor launch. The closest documented thing is Ntbtlog.txt in %WINDIR%, produced when the bootlog boot option is set to yes, which lists loaded and unloaded drivers. That is useful for a driver problem but it will not tell you why the hypervisor did not start. Use the event channels above instead.

There is no service and no scheduled task that drives VBS. The hypervisor and secure kernel are launched by the boot loader before the Service Control Manager exists, so there is nothing to restart and nothing to re-trigger. You will see HvHost (HV Host Service), vmcompute (Hyper-V Host Compute Service) and vmms (Hyper-V Virtual Machine Management) on a machine with the Hyper-V role, but those serve virtual machines, not VBS. Stopping them does not stop VBS, and starting them does not fix it. Nothing under \Microsoft\Windows\ in Task Scheduler drives VBS either. Every VBS change is a reboot.

The fix: platform security level, launch type, policy

Fix the earliest failing link and nothing else, then reboot, then re-measure. Fixing three links at once means you never learn which one mattered.

Group Policy: the full click path and every dropdown option

There is exactly one Group Policy setting for all of this, and it carries six or seven child dropdowns depending on your ADMX version. The parent must be Enabled for any child to do anything.

1. Open the Group Policy Management Console, or gpedit.msc for a single machine, and create or edit a GPO.
2. Navigate to Computer Configuration > Administrative Templates > System > Device Guard.
3. Double-click Turn On Virtualization Based Security.
4. Select Enabled. This alone sets EnableVirtualizationBasedSecurity to 1.
5. Under Select Platform Security Level, choose Secure Boot unless every single machine in scope is known to have an IOMMU.
6. Under Virtualization Based Protection of Code Integrity, choose Enabled without UEFI lock. Microsoft's guidance is to pick UEFI lock only when you specifically want to stop Memory Integrity being turned off remotely or by a later policy update.
7. Under Credential Guard Configuration, choose Enabled without lock if you want to keep the ability to turn it off remotely. Leave it Disabled if your scope contains Pro machines.
8. Leave Require UEFI Memory Attributes Table unticked for a first rollout. Ticking it excludes any device whose firmware does not report a compliant MAT.
9. Under Secure Launch Configuration, choose Enabled only on hardware you know supports it.
10. Under Kernel-mode Hardware-enforced Stack Protection, choose Enabled in enforcement mode only after VBS and Memory Integrity are both confirmed running, because it depends on both.
11. Click OK, then run gpupdate /force from an elevated prompt on a target machine, and reboot.

Here is every documented option, with the value each one writes, so you can map a policy to a device and back.

Intune: the Settings Catalog path

Intune splits these across two settings-catalog categories, which is the single most confusing thing about configuring VBS from Intune. The VBS parent switch, the platform security level, Credential Guard and Secure Launch sit under Device Guard. Memory Integrity and the MAT requirement sit under Virtualization Based Technology. You will usually need settings from both in one profile.

1. Sign in to the Microsoft Intune admin center and go to Devices.
2. Select Configuration, then Create, then New policy.
3. Set Platform to Windows 10 and later and Profile type to Settings catalog. Click Create.
4. Give the profile a name such as CONTOSO-VBS-Baseline and click Next.
5. Click Add settings. In the picker, search for Device Guard and choose that category.
6. Tick Turn On Virtualization Based Security and set it to Enable virtualization based security.
7. Tick Select Platform Security Level and set it to Turns on VBS with Secure Boot. That is the value 1 option.
8. If your scope is Enterprise or Education only, tick Credential Guard and choose Enabled without lock.
9. Now search the picker for Virtualization Based Technology and choose that category.
10. Tick Hypervisor Enforced Code Integrity and set it to Enabled without lock.
11. Close the picker, click Next through Scope tags, and assign the profile to a small pilot group first.
12. Click Next, review, and Create. Reboot a pilot device and re-run the checks above.

If you would rather use a custom OMA-URI profile, the documented nodes are below. Data type is int for all of them.

Fixing the hypervisor launch type

If link 6 is your failure, one command fixes it, and you should suspend BitLocker first because you are changing a boot entry.

1. From an elevated prompt, suspend BitLocker for one reboot on the OS volume.
2. Run bcdedit /set hypervisorlaunchtype auto.
3. If a vsmlaunchtype line was also set to Off, run bcdedit /set vsmlaunchtype auto as well.
4. Reboot, then re-read Win32_DeviceGuard and confirm VirtualizationBasedSecurityStatus is now 2.

If link 5 is your failure instead, do not touch bcdedit at all. Change the platform security level to Secure Boot only, either in the GPO dropdown or with RequirePlatformSecurityFeatures set to 1, and reboot.

Proof it worked: a real run on a healthy device

The companion script walks all nine links in evaluation order, translates every WMI enumeration to English, and reports the first failing link with its specific remedy. It is read-only. It never writes a registry value, never changes a service, and the only bcdedit call it makes is /enum. It needs no PowerShell modules.

The block below is a genuine run on a Windows 11 Enterprise laptop with VBS healthy. No identifiers appear in the output, so nothing has been replaced.

The Wininit evidence from the same run confirms the tenant really launched, not just that policy was accepted. Both lines are real output from the lab device.

Event 14 reporting a first variable of 0x1 means configured to run with UEFI lock, and event 13 immediately after it means it actually did run. Event 15 in place of 13 would have meant the exact opposite: policy fine, VBS absent.

Finally, the observed Microsoft-Windows-DeviceGuard/Operational record from the same device, which is the single most readable summary of a policy evaluation anywhere on the machine. Remember that this channel is undocumented.

One line, every dropdown, and a status code. If you ever get to build detection at scale, do it on Win32_DeviceGuard rather than on this, precisely because this text can change without notice.

References

Microsoft official documentation:

• Virtualization-based Security (VBS) - the definition and the full hardware and firmware requirements table.
• Enable memory integrity - the registry surface, the Mandatory warning, and the complete Win32_DeviceGuard enumeration tables.
• DeviceGuard Policy CSP - every node, allowed value and Group Policy element mapping.
• VirtualizationBasedTechnology Policy CSP - Memory Integrity and the UEFI Memory Attributes Table node.
• Configure Credential Guard - the documented WinInit event IDs 13 to 17 and the UEFI lock removal procedure.
• Windows security features licensing and edition requirements - the edition table showing VBS and HVCI everywhere and Credential Guard on Enterprise and Education only.
• BCDEdit /set - hypervisorlaunchtype, vsmlaunchtype, hypervisoriommupolicy and the bootlog option.
• System Guard Secure Launch and SMM protection - the Scenarios\SystemGuard key and the msinfo32 verification fields.
• Kernel Mode Hardware-enforced Stack Protection - the dependency on VBS and HVCI, and the enforcement-mode dropdown.
• Microsoft Defender Credential Guard hardware requirements - the OEM-facing requirements table, and a link to the HVCI and Credential Guard hardware readiness tool if you want a second opinion on a specific model.

Community deep-dives, each fetched and confirmed on topic before citing:

The companion script is at Get-VbsPrerequisiteChain.ps1 in the Windows-11-Scripts repository, under the folder named after this post's slug.