System Guard in Windows 10 & 11: Troubleshooting “Enabled but not Running” and Boosting Boot Security

System Guard in Windows 11 and Windows 10 serves as a critical bulwark against sophisticated threats aiming to compromise a device during its earliest and most vulnerable startup phases. With the proliferation of firmware and boot-level attacks, Microsoft has emphasized leveraging hardware-level protections, such as Secure Boot, TPM 2.0, and Virtualization-Based Security (VBS), to deliver rapid security validation from the ground up. However, a recurring concern among administrators is the seemingly paradoxical status: “System Guard Enabled but not running.” This issue, found irrespective of meticulous configuration, has surfaced especially among users on server-class hardware such as Dell PowerEdge platforms running Windows Server 2022 Core, leaving many IT pros searching for a definitive, actionable fix.

System Guard: The Foundation of Secured-core PCs​

System Guard underpins Microsoft’s vision of hardware-rooted trust. At its heart, it consists of three vital capabilities: [1] System Management Mode (SMM) protection, [2] Secure Launch, and [3] Virtualization-Based Security (VBS). These work together within the device’s firmware and OS to establish and continuously enforce a root of trust, detect and block malicious code during boot, and isolate sensitive workloads from even highly privileged malware.
Introduced with Windows 10 and expanded in Windows 11, System Guard also anchors the “Secured-core” certification, envisioned for PCs that integrate advanced firmware security by default. According to official Microsoft documentation and independent reviews, ideal deployment scenarios range from high-value enterprise endpoints to servers hosting sensitive workloads, with requirements including TPM 2.0, Secure Boot, and support for hardware-based virtualization technologies (VT-x for Intel, AMD-V for AMD, and ARM virtualization for Snapdragon platforms).

Understanding “Enabled But Not Running”: Diagnostic Realities​

Despite System Guard being marked as “enabled” via group policy or registry settings, some users find—especially after firmware upgrades or hardware refreshes—that the status remains stubbornly “not running.” Reports on various forums and Microsoft’s own support pages confirm that this condition typically signals a misalignment between hardware configuration, firmware feature support, and Windows’ own system expectations.
Troubleshooting this issue should always begin with a methodical validation of prerequisites, not assumptions. It is unwise to infer compliance based solely on vendor data or prior experience. Instead, careful verification against Microsoft’s official documentation must guide each step.

Step 1: Confirming Hardware and Firmware Baseline​

A crucial discovery from Microsoft and industry analysts is that not all modern hardware, even among recent server or workstation classes, inherently supports all System Guard prerequisites. The CPU’s capabilities are especially central to support for Secured-core functionality. Specifically:

• Intel: vPro-class processors, eighth-generation (Coffee Lake/Whiskey Lake) or newer.
• AMD: Zen 2 generation and newer (Ryzen 3000 series, EPYC 7002 or later).
• Qualcomm: Snapdragon SD850 and newer.

Just as critical: the system must be operating in UEFI mode (not Legacy or CSM), with Secure Boot and TPM 2.0 enabled in firmware. Many servers, notably older models, may lack DRTM (Dynamic Root of Trust for Measurement) firmware extensions—and absence of DRTM is a known, sometimes unfixable reason why System Guard will not fully activate on capable hardware.
Key verification steps:

• Enter BIOS/UEFI settings and locate options for UEFI mode, Secure Boot, TPM 2.0, Intel VT-x/AMD-V, and Kernel DMA Protection. Each must be explicitly enabled.
• Consult manufacturer release notes regarding Secured-core PC compatibility and firmware updates that may introduce necessary support.

Step 2: Registry and Policy Configuration​

With hardware validated, attention turns to software. It is vital to corroborate that the correct system registry keys and group policy settings are applied—not only once, but persistently, as Windows Updates or GPO overrides may reset these values in certain enterprise environments.

• Registry Path Validation:
• Launch regedit.exe and navigate to:
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\SystemGuard
• Ensure the Enabled DWORD exists with a value of 1. If not present, it must be created manually.
• VBS Activation in Group Policy:
• Open the Local Group Policy Editor (gpedit.msc).
• Drill down to:
  Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security
• Enable the policy, select the “Secure Boot” platform security level, and choose “Enabled with UEFI lock” under Credential Guard Configuration. Restarting is essential for full effect.

Failure to maintain these configs will result in the System Guard core services being disabled (even if the feature is “enabled” at a high level), and users may face the persistent “not running” status.

Step 3: Ensuring VBS and Hypervisor Activation​

System Guard relies inherently on VBS (Virtualization-Based Security), which partitions portions of system memory using Hyper-V to contain malware and protect sensitive OS components from exploitation. If VBS is not fully functional—often due to disabled Hyper-V hypervisor, third-party hypervisors, or conflicts with system firmware—then System Guard will not engage.
To verify and enable:

• In an Administrator Command Prompt, enter:
  bcdedit /set hypervisorlaunchtype auto
• This instructs Windows to always load the Hyper-V hypervisor at boot. A system restart is required.

A note of caution: Some virtualization platforms (notably VMware Workstation or Oracle VirtualBox) may conflict with VBS and Hyper-V. When present, users must decide which function is non-negotiable for their use case.

Step 4: BIOS/UEFI Configuration for Maximum Compatibility​

System Guard’s deepest protections are available only when firmware features align perfectly. The required BIOS/UEFI features are:

• UEFI Boot Mode (disable Legacy/CMS)
• Secure Boot
• TPM 2.0 (firmware or discrete module)
• Intel VT-x/AMD-V
• Kernel DMA Protection

After enabling these options, it is prudent to update the system firmware (BIOS/UEFI) to the latest stable revision, as manufacturers regularly add new Secured-core and security features through updates. On older systems, missing features—especially DRTM—cannot typically be “patched in” via software.

Step 5: Identifying Persistent Limitations​

If steps one through four are followed and System Guard still shows “Enabled but not running,” users must acknowledge several scenarios where full functionality is out of reach:

• Lack of DRTM: Many servers and PCs shipped prior to Secured-core initiatives do not support DRTM (Dynamic Root of Trust for Measurement). Even if labeled “enabled,” System Guard may remain inactive without this hardware function.
• OEM Firmware Restrictions: Firmware may restrict or incompletely implement Device Guard and related controls, particularly on white-box or budget hardware.
• Virtualization Conflicts: Third-party hypervisors or security solutions that interfere with Hyper-V or kernel-level virtualization will prevent VBS and System Guard from launching.

Case Study: Dell PowerEdge with Windows Server 2022 Core​

The Dell PowerEdge 360, popular among small and medium business deployments, has been highlighted in online discussions as susceptible to the “Enabled but not running” warning. Investigation reveals that, even with full BIOS configuration—UEFI, Secure Boot, TPM, virtualization—the absence of DRTM support or outdated firmware is often to blame. Dell’s own documentation suggests that only select hardware revisions and firmware builds achieve true Secured-core readiness.
Administrators are advised to:

• Verify their specific PowerEdge model and hardware revision on Dell’s support site against Secured-core compatibility listings.
• Apply all recommended BIOS and firmware updates.
• If “System Guard” remains inert despite full compliance, consult Microsoft’s hardware compatibility program for alternative hardware, or accept the limitation while providing alternate endpoint defenses.

Disabling System Guard: Risks and Methods​

While not commonly advised, some scenarios require temporarily disabling System Guard, typically for diagnostic or compatibility reasons.
Process:

• In Group Policy Editor (gpedit.msc), navigate to Device Guard and set “Turn On Virtualization Based Security” to Disabled.
• Reboot the system.

Critically, disabling System Guard simultaneously weakens protections provided by VBS and associated integrity mechanisms. Risk analysis must balance necessary operational requirements against a potentially expanded threat surface. Any deviation from recommended security posture should be documented and tracked for compliance impact.

Credential Guard & System Guard: Verifying Protection Status​

Windows System Information (msinfo32.exe) remains the quickest interface to audit VBS features:

• Under System Summary, locate the “Virtualization-based Security Services Running” line. Both Credential Guard and System Guard should be listed if fully operational.

Alternatively, PowerShell scripts (provided by Microsoft) and dedicated security audit tools can provide granular VBS and System Guard status feedback. Falsely reporting either feature as active is exceedingly rare, but signature tampering or unsupported configuration can theoretically result in incorrect status displays—always cross-reference using multiple tools if mission-critical systems are at stake.

Security Impact: The Stakes of an Inactive System Guard​

The threat landscape for Windows endpoints continues to evolve, growing increasingly hostile at firmware and boot layers. According to studies by Microsoft’s own threat intelligence teams and external analysts, systems lacking operational System Guard are materially more susceptible to the following:

• Bootkits and Rootkits: Malicious code that initiates before the OS, often undetectable by traditional AV.
• Credential Theft: Exploitation of trust boundaries set during system startup, leading to the theft of credentials or lateral movement within a network.
• Kernel Vulnerabilities: Attackers leveraging the absence of VBS/Hyper-V isolation to inject exploits or escalate privileges.

The latest MITRE ATT&CK reports confirm a tangible difference in successful exploit rates correlating directly with whether System Guard and Secure Launch are actively running. Devices relying solely on Secure Boot or TPM—without hardware-measured boot chains enforced by System Guard—remain vulnerable to advanced adversaries.

Notable Strengths and Remaining Limitations​

System Guard and related Secured-core initiatives offer the following confirmed advantages:

• Defense-in-depth architecture: Tightly integrated with hardware, making circumvention orders of magnitude more complex for attackers.
• Minimal performance impact: Modern CPUs are architected for low-overhead support of virtualization, with negligible hit to user workloads, according to Microsoft and third-party testing.
• Ongoing updates and support: Microsoft continues to invest in new safeguards, regularly expanding coverage in Windows 11 releases.

However, several challenges persist:

• Hardware lock-in: Full System Guard protections remain unavailable on a wide array of legacy hardware, including many server-grade systems.
• Vendor inertia: Not all OEMs deliver timely firmware or BIOS updates to enable features such as DRTM, creating uncertainty for buyers and admins.
• Compatibility friction: VBS and Hyper-V requirements may conflict with some third-party virtualization products and specialized drivers, necessitating difficult trade-offs.

Conclusion: Best Practices for a Secure Boot Chain​

Achieving a state where System Guard is both enabled and running demands strict adherence to hardware, firmware, and software specifications verified directly against trusted sources. Windows admins and security officers should:

• Cross-reference their hardware against Microsoft’s and OEM’s Secured-core support matrices before purchase.
• Apply the most current BIOS/UEFI and system firmware.
• Methodically configure all required options in both firmware and OS/GPO/registry.
• Validate outcomes using built-in and third-party security audit tools, not relying on a single method.
• Weigh, document, and monitor any exceptions to the full Secured-core stack.

While the promise of bulletproof boot-time security is technically within reach, real-world success depends on holistic, sustained attention to detail—from hardware vetting to the last registry bit. Windows 11 and the evolving Secured-core ecosystem continue to raise the bar, but vigilance, not assumption, remains the key to truly secure endpoints in the modern age.

---

Source: The Windows Club System Guard Enabled but not running in Windows 11