System Guard Enabled but Not Running in Windows Server [Fixed]

System Guard Secure Launch uses Dynamic Root of Trust for Measurement (DRTM) to protect Windows Server from firmware-level attacks. When the feature shows as enabled in policy but fails to run at startup, the server loses the firmware protection it is supposed to have.

This issue appears most often on Windows Server 2019 and 2022 because System Guard has strict hardware requirements and depends on several components working together. If any single component is missing or misconfigured, Secure Launch registers as enabled but never activates.

What Causes System Guard to Show as Enabled but Not Running

System Guard requires a specific combination of firmware, hardware, and Windows components. A gap in any one of them stops it from running.

Common causes include:

TPM 2.0 absent or disabled in UEFI
Secure Boot turned off in firmware
Virtualization-Based Security (VBS) not active
Hyper-V role not installed on the server
IOMMU (Intel VT-d or AMD-Vi) disabled in BIOS
Running inside a virtual machine without nested virtualization
A domain Group Policy overriding local settings

Fix 1: Confirm the Current Status Before Making Changes

Run a quick check first so you know exactly what is and is not running on the server.

Using MSINFO32:

Press Win + R, type msinfo32, and press Enter.
Click System Summary in the left pane.
Scroll down and look for these entries on the right:
- Virtualization-based security: should say Running
- Virtualization-based security Services Running: lists active services
- System Guard Secure Launch: should say Running
If VBS says Not enabled or Enabled but not running, work through the fixes below.

Using PowerShell:

Open an elevated PowerShell window and run:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

Check the SecurityServicesRunning value in the output. A value of 1 means Credential Guard is active; 2 means HVCI is active. An empty value means neither VBS nor System Guard is running.

Fix 2: Enable TPM 2.0 in UEFI Firmware

System Guard Secure Launch requires TPM 2.0. If TPM is disabled in the server firmware, Secure Launch cannot initialize.

Restart the server and enter UEFI setup (typically F2, Del, or F10 during POST).
Navigate to the Security or Trusted Computing section.
Set TPM State or Security Device to Enabled.
Set the TPM version to 2.0 if the firmware offers that option.
Save and reboot into Windows Server.

After booting, press Win + R, type tpm.msc, and press Enter. The TPM Management console should display TPM is ready for use with Specification Version: 2.0. If it shows version 1.2, System Guard will not run.

Also confirm in BIOS that Intel TXT (on Intel servers) or AMD SKINIT (on AMD servers) is enabled alongside TPM. These CPU-level features are what DRTM actually relies on, and they usually sit in the same BIOS section as TPM or CPU virtualization settings.

Fix 3: Enable Secure Boot in UEFI

Secure Boot must be active for the DRTM process to verify boot environment integrity. Without it, System Guard cannot confirm that the boot chain is uncompromised.

Enter UEFI settings during server restart.
Go to the Boot or Security section.
Set Secure Boot to Enabled.
Confirm the boot mode is set to UEFI, not Legacy/CSM.
Save changes and restart the server.

Windows Server 2016, 2019, and 2022 all support UEFI Secure Boot when the OS was installed in UEFI mode. If the server was originally installed in Legacy mode, switching to UEFI requires a disk conversion first.

Fix 4: Enable Virtualization-Based Security via Group Policy

VBS creates the isolated Virtual Trust Level (VTL) environment that System Guard depends on. Without VBS running, Secure Launch has no protected environment to operate in.

Press Win + R, type gpedit.msc, and press Enter.
Navigate to: Computer Configuration > Administrative Templates > System > Device Guard
Double-click Turn On Virtualization Based Security.
Set it to Enabled.
Under Select Platform Security Level, choose Secure Boot and DMA Protection.
Under System Guard Secure Launch, set it to Enabled.
Click OK.
Open an elevated Command Prompt and run: gpupdate /force
Restart the server.

After the restart, check MSINFO32 again to see if System Guard now shows as running.

Fix 5: Enable VBS via Registry

If Group Policy is managed at the domain level and you cannot edit local policy, use the registry to enable VBS directly on the server.

Open an elevated Command Prompt and run these commands one at a time:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 1 /f

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v RequirePlatformSecurityFeatures /t REG_DWORD /d 3 /f

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\SystemGuard" /v Enabled /t REG_DWORD /d 1 /f

The value 3 for RequirePlatformSecurityFeatures enables both Secure Boot and DMA protection. Use 1 for Secure Boot only if the server hardware does not support DMA protection.

Restart the server after running these commands.

Fix 6: Install the Hyper-V Role

System Guard needs the Hyper-V hypervisor to create the VTL environment. Without the Hyper-V role installed, VBS cannot start and System Guard has no platform to run on.

Run this command in an elevated PowerShell session:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart

On Windows Server Core:

Install-WindowsFeature -Name Hyper-V

After the server restarts, confirm the role is installed:

Get-WindowsFeature -Name Hyper-V

The Install State column should show Installed.

Fix 7: Set Hypervisor Launch Type to Auto

The Hyper-V role can be installed but the hypervisor can still fail to launch at boot if the launch type was manually set to off at some point. This silently blocks VBS and System Guard from starting, and MSINFO32 gives no obvious indication of why.

Open an elevated Command Prompt and run:

bcdedit /set hypervisorlaunchtype auto

Then restart the server. After the restart, confirm the setting applied:

bcdedit /enum | findstr hypervisor

The output should show hypervisorlaunchtype Auto. If it still shows Off, re-run the first command and reboot again.

This fix applies even if Fix 6 installed Hyper-V correctly. A previous administrator or a deployment script may have set the launch type to off to disable Hyper-V on that server.

Fix 8: Enable IOMMU in BIOS

DMA protection within System Guard requires IOMMU support at the hardware level. Intel platforms use VT-d; AMD platforms use AMD-Vi.

Enter UEFI/BIOS setup during a server restart.
For Intel servers, go to Advanced > CPU Configuration or Chipset > System Agent Configuration and enable Intel VT for Directed I/O (VT-d).
For AMD servers, go to the equivalent chipset or CPU section and enable IOMMU or AMD-Vi.
Save and restart.

Without IOMMU, System Guard can run in a reduced capacity, but the DMA protection component stays inactive. The Group Policy setting Secure Boot and DMA Protection requires IOMMU to work.

Fix 9: Check for a Conflicting Domain Group Policy

In a domain environment, a GPO applied at the domain or OU level can silently override local policy and prevent System Guard from activating. This is a common cause in managed enterprise environments.

Open an elevated Command Prompt on the affected server.
Run: gpresult /h C:\GPReport.html
Open C:\GPReport.html in a browser.
Search the page for Device Guard and Virtualization Based Security.
Note which GPO is applying the setting and what value it sets.

If a domain GPO forces System Guard off, work with the domain administrator to update the policy for the relevant OU or create a targeted exception for the server.

Fix 10: Verify Nested Virtualization If Running in a VM

System Guard does not run inside a virtual machine by default. If the Windows Server instance is a guest VM, the hypervisor host must support and enable nested virtualization.

On Hyper-V host (run on the host, not the guest):

Set-VMProcessor -VMName "YourServerVMName" -ExposeVirtualizationExtensions $true

On VMware ESXi:

Power off the VM.
Edit the VM settings and go to VM Options > Advanced.
Enable Virtualize Intel VT-x/EPT or AMD-V/RVI.
Power the VM back on.

Even with nested virtualization enabled, some System Guard components may have limited functionality in virtual environments compared to bare-metal deployments. Microsoft recommends bare-metal servers for full System Guard Secure Launch support.