Configure Credential Guard in Windows step by step

Credential Guard has become a key piece to strengthen credential security in environments Windows Modern systems are particularly important in organizations where a credential theft attack can pose a serious problem. Instead of leaving authentication secrets exposed in system memory, this feature isolates them using virtualization-based security, significantly reducing the attack surface.

In the following lines you will see how to configure Credential Guard Using different methods (Intune/MDM, Group Policy, and Registry), we'll cover the requirements your device must meet, the limitations it introduces, how to verify that it's actually active, and how to disable it in necessary scenarios, including virtual machines and UEFI-locked devices. Everything is explained in detail, but in clear, user-friendly language so you can easily apply it.

What is Credential Guard and how does it protect credentials?

Credential Guard is a Windows security feature which uses virtualization-based security (VBS) to isolate credentials and other authentication-related secrets. Instead of everything being stored directly in the local security authority process (lsass.exe), sensitive data is stored in an isolated component called LSA isolated o isolated LSA.

This isolated LSA runs in a protected environment, separated from the main operating system by means of the hypervisor (safe mode virtual or VSM). Only a very small set of binaries, signed with trusted certificates, can be loaded into that environment. Communication with the rest of the system is done via RPC, which prevents the malware that runs on the system, however privileged it may be, can directly read the protected secrets.

Credential Guard specifically protects three types of credentialsNTLM password hashes, Kerberos Ticket Granting (TGT) records, and credentials stored by applications as domain credentials are all mitigated. This helps to address classic attacks such as pass-the-hash o pass-the-ticket, very common in lateral movements within corporate networks.

It's important to understand that Credential Guard doesn't protect everything.It does not cover, for example, credentials handled by third-party software outside of standard Windows mechanisms, local and Microsoft accounts, nor does it protect against physical attacks or keyloggers. Even so, it greatly reduces the risk associated with domain credentials.

Credential Guard enabled by default

From Windows 11 22H2 and Windows Server 2025Virtualization-based security (VBS) and Credential Guard are enabled by default on devices that meet Microsoft's defined hardware, firmware, and software requirements. This means that on many modern computers, it comes pre-configured and active without any administrator intervention.

The default enabling mode is “UEFI unlocked”In other words, without the lock that prevents remote deactivation. This approach makes it easier for administrators to disable Credential Guard via policies or remote configuration if a critical application is incompatible or performance issues are detected.

When Credential Guard is enabled by defaultThe VBS itself is also enabled automatically. No separate VBS configuration is required for Credential Guard to function, although there are additional parameters to strengthen the platform's protection level (for example, requiring DMA protection in addition to the standard). Boot sure).

There is an important nuance in updated equipmentIf a device had Credential Guard explicitly disabled before upgrading to a version of Windows where it is enabled by default, it will remain disabled after the upgrade. In other words, the administrator's explicit setting takes precedence over the default behavior.

System, hardware, firmware and licensing requirements

For Credential Guard to provide real protectionThe device must meet a series of minimum hardware, firmware, and software requirements. Devices that exceed these minimums and have additional features, such as IOMMU or TPM 2.0, can benefit from higher levels of security against DMA attacks and advanced threats.

Hardware and firmware requirements

The main hardware requirements for Credential Guard They include a 64-bit CPU with virtualization extensions (Intel VT-x or AMD-V) and support for second-level address translation (SLAT, also known as Extended Page Tables). Without these virtualization capabilities, VBS and virtual safe mode will not be able to properly isolate memory.

At the firmware level, it is mandatory to have UEFI Version 2.3.1 or higher with Secure Boot support and a secure firmware update process. Additionally, features such as securely implemented Memory Overwrite Request (MOR), boot configuration protection, and firmware upgrade capability via [unclear - possibly "software upgrade" or "software upgrade"] are recommended. Windows Update.

The use of an input/output memory management unit (IOMMU)Using a VM such as Intel VT-d or AMD-Vi is highly recommended, as it allows you to enable DMA protection in conjunction with VBS. This protection prevents malicious devices connected to the bus from directly accessing memory and extracting secrets.

The Trusted Platform Module (TPM) is another key componentpreferably in version TPM 2.0although TPM 1.2 is also supported. The TPM provides a hardware security anchor to protect the VSM master key and ensure that data protected by Credential Guard can only be accessed in a trusted environment.

VSM protections and the role of TPM

Secrets protected by Credential Guard are isolated in memory through virtual secure mode (VSM). On recent hardware with TPM 2.0, persistent data in the VSM environment is encrypted with a VSM master key protected by the TPM itself and by the device's secure boot mechanisms.

Although NTLM and Kerberos TGTs are regenerated on each login and since they are not usually retained between reboots, the existence of the VSM master key allows for the protection of data that can be kept in place. ThereThe TPM ensures that the key cannot be extracted from the device and that the protected secrets cannot be accessed outside of a validated environment.

Windows edition requirements and licenses

Credential Guard is not available in all editions of WindowsIn client systems, it is supported in Windows Enterprise and in Windows Education, but not in Windows Pro or Windows Pro Education/SE. In other words, a computer with Windows Pro would need an upgrade to Enterprise to use this functionality.

Credential Guard usage rights are granted through licenses such as Windows Enterprise E3 and E5 or the educational licenses A3 and A5. In business environments, this is usually obtained through volume licensing agreements, while OEMs typically deliver Windows Pro and the customer then upgrades to Enterprise.

Credential Guard on Hyper-V virtual machines

Credential Guard can also protect secrets within virtual machines executed in Hyper-V, similarly to how it works on physical machines. The main requirements are that the Hyper-V host has IOMMU and that the virtual machines are Generation 2.

It is important to understand the protection boundary in these scenariosCredential Guard protects against attacks originating within the virtual machine itself, but not against threats from the host with elevated privileges. If the host is compromised, it can still access the guest machines.

Application requirements and compatibility

Activating Credential Guard blocks certain authentication featuresTherefore, some applications may stop working if they rely on outdated or insecure methods. Before mass deployment, it's advisable to test critical applications to ensure they remain operational.

Applications that require DES encryption for KerberosUnrestricted Kerberos delegation, TGT extraction, and NTLMv1 usage will be disrupted because these options are directly disabled when Credential Guard is active. This is a strict security measure, but necessary to prevent serious vulnerabilities.

Other features, such as implicit authenticationCredential delegation, MS-CHAPv2, or CredSSP expose credentials to additional risks even when Credential Guard is active. Applications that insist on using them may continue to function, but they leave credentials more vulnerable, so reviewing them is also recommended.

There may also be performance impacts if certain applications attempt to interact directly with the isolated process LsaIso.exeIn general, services that use Kerberos in a standard way (for example, file shares or Remote Desktop) continue to function normally without noticing any changes.

How to enable Credential Guard correctly

Microsoft's general recommendation is to enable Credential Guard This must be done before the device joins a domain or before a domain user logs on for the first time. If activated later, user or computer secrets may already be exposed in unprotected memory.

There are three main methods for setting up this feature.This can be done via Microsoft Intune/MDM, using Group Policy, or through the Windows Registry. The choice depends on the type of environment, available management tools, and desired level of automation.

Enable Credential Guard using Microsoft Intune / MDM

In environments managed with Intune or other MDM solutionsCredential Guard can be enabled by creating a device configuration policy that first activates virtualization-based security and then defines the specific behavior of Credential Guard.

Custom policies can be created using the DeviceGuard CSP. with the following key OMA-URI parameters:

• Activate VBS: OMA-URI ./Device/Vendor/MSFT/Policy/Config/DeviceGuard/EnableVirtualizationBasedSecuritydata type int, value 1 to enable virtualization-based security.
• Configure Credential Guard: OMA-URI ./Device/Vendor/MSFT/Policy/Config/DeviceGuard/LsaCfgFlags, type int, value 1 to enable with UEFI lock or 2 to enable without blocking.

Once the policy is created, it is assigned to the device or user group. that you want to protect. After applying the policy, you need to restart the device for Credential Guard to take effect.

Configure Credential Guard using Group Policy (GPO)

In Active Directory domains, the most convenient method is usually the GPO.You can use the Local Group Policy Editor for a single computer or create a Group Policy Object linked to domains or organizational units to cover many devices.

The specific path of the group policy isDevice Configuration → Administrative Templates → System → Device Guard. Within that section, there is a setting called "Enable virtualization-based security."

When enabling this policy, you must select the Credential Guard option. in the "Credential Guard Settings" drop-down list:

• Enabled with UEFI lock: prevents remotely disabling Credential Guard; it can only be changed through physical access to the firmware/BIOS.
• Enabled without blocking: allows you to disable Credential Guard later via GPO or remote configuration.

GPOs can be filtered using security groups or WMI filtersThis allows you to apply this protection only to certain types of devices or user profiles. After applying the policy, a restart is also required for the changes to take effect.

Configure Credential Guard using the Windows Registry

When more granular control is needed or script personalisedCredential Guard can be enabled directly through the Registry. This method is typically used in advanced scenarios or automations where GPO or MDM is not available.

To activate virtualization-based security (VBS)The following keys must be configured:

• Key path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
  Name EnableVirtualizationBasedSecurity, type REG_DWORD, value 1.
• Key path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
  Name RequirePlatformSecurityFeatures, type REG_DWORD, value 1 for safe starting or 3 for secure boot with DMA protection.

For specific Credential Guard configuration The key is used:

• Key path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  Name LsaCfgFlags, type REG_DWORDPossible values:
  0 to disable Credential Guard,
  1 to enable it with UEFI lock,
  2 to enable it without blocking.

After adjusting these keys in the RegistryYou need to restart the computer so that VBS and Credential Guard initialize correctly and begin protecting credentials.

Check if Credential Guard is enabled

Although it may seem tempting to look at whether the process LsaIso.exe It is in progress from the Task ManagerMicrosoft does not recommend this method as a reliable check. Instead, three main mechanisms are proposed: System Information, PowerShell and Event Viewer.

Verification with System Information (msinfo32)

The simplest way for many administrators It involves using the Windows "System Information" tool:

1. Select Start and type msinfo32.exeThen open the "System Information" application.
2. In the left panel, go to System overview.
3. In the right panel, look for the section "Virtualization-based security services in operation" and check that "Credential Guard" appears among the listed services.

If Credential Guard is listed as a running service In this section, it means that it is correctly enabled and active on the computer.

Verification using PowerShell

In managed environments, using PowerShell is very practical. To perform a bulk check of Credential Guard status, you can run the following command from an elevated PowerShell console:

(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

This command returns a set of numeric values which indicate which virtualization-based security services are active. In the specific case of Credential Guard, they are interpreted as follows:

• 0: Credential Guard disabled (not running).
• 1: Credential Guard enabled (running).

In addition to this general queryMicrosoft offers the DG_Readiness_Tool script (for example, DG_Readiness_Tool_v2.0.ps1), which allows you to check if the system is capable of running Credential Guard, enable it, disable it, and validate its status using options such as -Capable, -Enable, -Disable y -Ready.

Using the Event Viewer

Another verification method more oriented towards auditing It's to use the Event Viewer. From eventvwr.exe You can access "Windows Logs" → "System" and filter the events whose origin is "WinInit".

Among those events are entries related to the start-up of virtualization-based security services, including those that indicate whether Credential Guard has been successfully initialized during the startup process.

Disable Credential Guard and UEFI lock management

Although normally you'd want to keep Credential Guard enabledThere are scenarios where it may be necessary to disable it: application incompatibilities, laboratory testing, security architecture changes, etc. The procedure for disabling it will depend on how it was enabled and whether UEFI locking was used.

In general terms, disabling Credential Guard This involves reverting the settings applied via Intune/MDM, Group Policy, or the Registry, and then restarting the computer. However, when enabled with UEFI locking, there are additional steps because some of the settings are stored in firmware EFI variables.

Disabling Credential Guard with UEFI Lock

If Credential Guard was enabled with UEFI lockIt's not enough to change the GPO or the Registry. You also need to remove the EFI variables associated with the isolated LSA configuration using bcdedit and a small special startup process.

From a symbol of the system with elevated privileges a sequence is executed commands to:

1. Install a temporary EFI unit with mountvol and copy SecConfig.efi to the Microsoft boot path.
2. Create a system charger entry with bcdedit /create pointing to that SecConfig.efi.
3. Configure the bootsequence of the boot manager so that it boots once with that special loader.
4. Add the charging option DISABLE-LSA-ISO to disable the isolated LSA configuration stored in UEFI.
5. Remove the temporary EFI unit again.

After performing these steps, the device restarts.Before the operating system starts, a message will appear indicating that the UEFI settings have been modified and will ask for confirmation. It is essential to accept this message for the deactivation changes to take effect.

Disable Credential Guard on virtual machines

In the case of virtual machines connected to a Hyper-V hostIt is possible to prevent the VM from using VBS and Credential Guard even if the guest operating system would be prepared for it.

From the host, using PowerShell, you can run The following command will exclude a virtual machine from virtualization-based security:

Set-VMSecurity -VMName <VMName> -VirtualizationBasedSecurityOptOut $true

By activating this exclusion optionThe VM will run without VBS protections and, by extension, without Credential Guard, which can be useful in test environments or when running legacy systems within virtual machines.

Integrating Credential Guard into AWS Nitro and other scenarios

Credential Guard is also available in cloud environments such as Amazon EC2, leveraging the secure architecture of the AWS Nitro system. In this context, VBS and Credential Guard rely on Nitro to prevent Windows login credentials from being extracted from the guest operating system's memory.

To use Credential Guard on a Windows instance in EC2To launch a compatible instance, you need to select a supported instance type and a preconfigured Windows AMI that includes virtual TPM and VBS support. This can be done from the Amazon EC2 console or from the AWS CLI using run-instances or with PowerShell using New-EC2Instancespecifying, for example, an image of the style TPM-Windows_Server-2022-English-Full-Base.

In some scenarios it will be necessary to disable memory integrity (HVCI) before enabling Credential Guard, by adjusting group policies related to "Virtualization-based protection of code integrity". Once these adjustments are made and the instance is restarted, Credential Guard can be enabled and validated, as on any other Windows machine, with msinfo32.exe.

Protection limits and aspects that Credential Guard does not cover

Although Credential Guard represents a huge leap forward in credential protectionIt's not a silver bullet that solves everything. There are specific cases that fall outside its scope, and it's important to be aware of these to avoid a false sense of security.

Some examples of what it does not protect are:

• Third party software that manages credentials outside of standard Windows mechanisms.
• Local accounts and Microsoft accounts configured on the computer itself.
• Active Directory database on Windows Server domain controllers.
• Credential inbound channels such as Remote Desktop gateway servers.
• Keystroke recorders and direct physical attacks on the team.

It also does not prevent an attacker with malware on the computer from It makes use of privileges already granted to an active credential. That is, if a user with elevated permissions connects to a compromised system, the attacker can exploit those permissions for the duration of the session, even though they cannot steal the hash from the protected memory.

In environments with high-value users or accounts (domain administrators, IT staff with access to critical resources, etc.), it is still advisable to use dedicated equipment and other additional layers of security, such as multi-factor authentication, network segmentation, and anti-keylogger measures.

Device Guard, VBS and relationship with Credential Guard

Device Guard and Credential Guard are often mentioned together because both take advantage of virtualization-based security to strengthen system protection, although they solve different problems.

Credential Guard focuses on protecting credentials (NTLM, Kerberos, Credential Manager) isolating them in the protected LSA. It does not depend on Device Guard, although both share the use of the hypervisor and hardware features such as TPM, secure boot, and IOMMU.

Device Guard, for its part, is a set of features Hardware and software solutions allow you to lock the device so that it can only run trusted applications defined in code integrity policies. This changes the traditional model (where everything runs unless blocked by antivirus software) to one where only explicitly authorized applications are executed.

Both features are part of the Windows Enterprise arsenal. To protect against advanced threats, Device Guard relies on VBS and requires drivers to be HVCI-compliant, while Credential Guard uses VBS to isolate authentication secrets. Together, they offer a powerful combination: more reliable code and better-protected credentials.

Have Credential Guard properly configured This involves securing one of the most sensitive aspects of any Windows environment: user and computer credentials. Understanding its requirements, knowing how to activate it with Intune, GPO, or the Registry, knowing its limitations, and having clear procedures to verify its status and disable it in exceptional cases allows you to take full advantage of this technology without encountering surprises in production.