Microsoft Defender Credential Guard hardware requirements

  • Article

Microsoft Defender Credential Guard uses virtualization-based security to isolate and protect secrets (e.g., NTLM password hashes and Kerberos ticket-granting tickets) to block pass-the-hash or pass-the-ticket (PtH) attacks. When Microsoft Defender Credential Guard is enabled, NTLMv1, MS-CHAPv2, Digest, and CredSSP cannot use the signed-in credentials. Thus, single sign-on does not work with these protocols. However, applications can prompt for credentials or use credentials stored in the Windows Vault which are not protected by Microsoft Defender Credential Guard with any of these protocols.

It is strongly recommended that valuable credentials, such as the sign-in credentials, not be used with any of these protocols. If these protocols must be used by domain or Azure AD users, secondary credentials should be provisioned for these use cases.

When Microsoft Defender Credential Guard is enabled, Kerberos does not allow unconstrained Kerberos delegation or DES encryption, not only for signed-in credentials, but also prompted or saved credentials.

Note: Beginning with Windows 10 version 1709 and Windows Server version 1709, when Intel TXT or SGX are enabled in a platform via the BIOS, Hypervisor-Protected Code Integrity (HCVI) and Credential Guard are not impacted and will function as expected. HVCI and Credential Guard are not supported on earlier versions of Windows when Intel TXT or SGX are enabled in a platform via the BIOS.

For a better understanding of what Microsoft Defender Credential Guard is and what attacks it protects againt, see Deep Dive into Credential Guard.

IT Professionals: To learn how to deploy Microsoft Defender Credential Guard in your enterprise, see Protect derived domain credentials with Credential Guard.

For a device to support Microsoft Defender Credential Guard as specified in the Windows Hardware Compatibility Requirements (WHCR), you as the OEM must provide the following hardware, software, or firmware features.

Requirement Details
Secure Boot Hardware-based Secure Boot must be supported. To learn more, see Secure Boot.
Secure Boot configuration and management
  • You must be able to add ISV, OEM, or Enterprise Certificate to the Secure Boot database at manufacturing time.
  • Microsoft UEFI CA must be removed from the Secure Boot database. Support for 3rd-party UEFI modules is permitted but should leverage ISV-provided certificates or OEM certificate for the specific UEFI software.
Secure firmware update process Like UEFI software, UEFI firmware can have security vulnerabilities. It is essential to have the capability to immediately patch such vulnerabilities when found through firmware updates. UEFI firmware must support secure firmware update following Hardware Compatibility Specification for Systems for Windows 10 under System.Fundamentals.Firmware.UEFISecureBoot.
United Extensible Firmware Interface (UEFI) To lern more, see United Extensible Firmware Interface (UEFI) firmware requirements.
Virtualization-based security (VBS) Hypervisor-Protected Code Integrity requires VBS. You can learn more about VBS by reading Virtualization-based Security (VBS).

Hypervisor-Protected Code Integrity and Credential Guard Readiness Tool

To determine if a device is able to run HVCI and Credential Guard, download the HVCI and Credential Guard hardware readiness tool.