Complete guide to configuring Credential Guard and Device Guard in Windows

In modern corporate environments, protect credentials and strictly control what code is executed On Windows systems, it's no longer optional. With the arrival of Windows 10, Windows 11, and Windows Server 2016 and later, Microsoft has made a strong commitment to virtualization-based security, resulting in technologies like Credential Guard, Device Guard, and Application Guard. Check out our Complete guide to security in Windows 11 for businesses.

If you manage a network of computers, you'll want to know in detail how Configure Credential Guard and Device Guard correctly, how they integrate with other measures such as BitLocker, Exploit Guard or Remote Credential Guard, and what role Microsoft Defender Endpoint Security Baselines play (especially when working with traditional Intune or GPOs).

Fundamentals: VBS, VSM and the role of Credential Guard and Device Guard

To understand why Credential Guard and Device Guard are so effective, you first need to understand the concept of virtualization-based security (VBS)VBS utilizes the processor's virtualization capabilities (Intel VT-x or AMD-V) to create an isolated environment within the machine itself, logically separate from the main operating system. This approach is complemented by techniques such as kernel isolation in Windows 11, which reinforce the separation between the core and the rest of the system.

The VBS is built upon Virtual Secure Mode (VSM)A subsystem stores and processes particularly sensitive information. The "normal" operating system does not access this content directly, but rather interacts with it through very limited and controlled interfaces, reducing the attack surface.

Within this context, Credential Guard appears, which uses the VSM to safeguard user credentials and authentication secrets (such as NTLM hashes or Kerberos tickets). Because they are isolated from the rest of the system, even if an attacker gains high privileges, it is much more difficult for them to extract those credentials.

Device Guard, on the other hand, focuses on code control. Its goal is that Only run signed and trusted applicationsblocking unknown or potentially malicious binaries. In practice, Device Guard is implemented using various technologies, the most well-known being the use of Code Integrity policies and whitelist-based configuration.

Both solutions rely on the same pillar: a secure environment isolated using VBS/VSM, with reinforced support through hardware such as TPM (Trusted Platform Module), which helps to protect cryptographic keys and verify the integrity of the system boot.

Microsoft Defender Endpoint Security Baselines

If you manage your devices with Microsoft Intune or the Microsoft Defender Endpoint Security Console, the safety baselines They are your best ally for deploying complex configurations (such as Credential Guard and Device Guard) without going crazy with each individual setting.

A safety baseline is nothing more than a set of preconfigured parameters For Windows, these are grouped and recommended by Microsoft security teams. When you create a baseline profile in Intune, you're actually generating a template with a multitude of device settings: credential policies, application controls, VBS options, Defender parameters, and more.

The Microsoft Defender for Endpoint documentation publishes different versions of this baseline, for example: 24:1The December 2020 baseline (version 6), the September 2020 baseline (version 5), and earlier versions such as those from April and March 2020. Each of these includes a detailed list of options, with their default state and, where possible, links to configuration service providers (CSPs) specifics or extended documentation of the same group of products.

When a new version of the baseline is released, automatically reverts to the previous versionProfiles you created with an older version are now in read-only mode: you can still assign them, change their name, description, or target groups, but you cannot modify their internal parameters.

To adapt the configuration to the new standards, Intune allows update those profiles to the current baseline versionOnce the profile is updated, you will be able to edit the settings and adjust, for example, the status of Credential Guard, Device Guard, BitLocker, or any other included option.

Microsoft insists that this Defender endpoint baseline is optimized for physical devicesIt is not recommended to use it as is in virtual machines or VDI environments, as certain options may interfere with interactive remote sessions or with certain virtualization architectures. For VDI environments, it is important to review the specific documentation on how to increase baseline compliance without breaking the user experience.

Prerequisites and system compatibility

To implement Credential Guard and Device Guard, and even more so if you want to integrate them with other technologies (Remote Credential Guard, Application Guard, Citrix solutions, etc.), it is key to verify hardware requirements, operating system, and software versions.

Generally speaking, you will need:

• CPU with virtualization support (Intel VT-x or AMD-V) and virtualization enabled in BIOS/UEFI.
• Support for Virtualization-based Security (VBS) enabled from the system security settings.
• TPM (preferably TPM 2.0) to reinforce key storage and system boot integrity.
• Compatible versions of Windows 10/11 Enterprise o Windows Server from 2016 onwards to take advantage of VSM.

In the area of ​​virtual desktops and remote applications, Citrix documents specific requirements for its role of enhanced domain transfer for SSO (single sign-on), which relies precisely on Remote Credential Guard:

• Virtual Delivery Agent (VDA) version 2308 or higher; if you are using Windows 11 on the session host or client, VDA 2407 or 2402 LTSR CU2 or later is required.
• Citrix Workspace application version 2309 or higher and, in Windows 11 environments, at least 2405.10 or 2402 LTSR CU2.
• Windows 10/11 64-bit clients, joined to an Active Directory domain and with direct connectivity with domain controllers (No connection, no SSO).
• Single session hosts with Windows 10 22H2 or Windows 11 22H2 or later.

This Citrix feature replaces legacy handoff authentication based on the old SSO service (ssonsvr.exe) and It is not compatible with 32-bit systemsAdditionally, you cannot simultaneously use legacy domain transfer and the new enhanced domain transfer on the same host.

Credential Guard configuration and deployment

Credential Guard is one of the central components of the VBS ecosystem. Its mission is clear: prevent the credentials stored in the system (such as LSASS process memory hashes) are stolen using dump tools or lateral movement attacks.

To enable Credential Guard using traditional Group Policy settings, the key setting is located within Windows virtualization-based security options. In more recent versions, these policies are typically grouped within... Device Guard in the GPO templateSpecifically, in “Activate virtualization-based security”.

When this policy is properly configured, the system boots with VBS and Activate Credential GuardInternally, this translates into changes in the registry, especially in the key:

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa

That's where the value lies. LsaCfgFlagsThis setting controls the behavior of Credential Guard. A value of 0 disables the functionality, while other values ​​(depending on the Windows version) enable it in different modes. If you are going to modify these keys, it is advisable to follow best practices. work with the Windows registry safely and, where appropriate, perform prior backups.

In some scenarios, especially when incompatibilities arise, it may be necessary Temporarily disable Windows Defender Credential GuardFor example, Citrix documents a known issue where, if Credential Guard is active on the client, SSO to virtual sessions may fail, displaying the Windows security message: "Your credentials didn't work. Windows Defender Credential Guard does not allow the use of Windows logon credentials."

In these cases, there are two main ways to disable it:

• Through Group Policy, by modifying the "Enable virtualization-based security" option within Computer Configuration > Administrative Templates > System > Device Guard.
• Through registration, establishing LsaCfgFlags = 0 on the route indicated above.

It is important to understand that this limitation also affects the use of Remote Credential Guard via RDPIf you need to use enhanced domain transfer with SSO along with Credential Guard, the official recommendation is to submit a request to Microsoft for support of this scenario.

Device Guard and code control: whitelists and operating modes

While Credential Guard focuses on credentials, Device Guard focuses on the control of which software can be run on the team. The idea is to move from a classic model based on malware signatures to a preventative model that only allows what the administrator has defined as trusted.

In practice, Device Guard is primarily implemented through:

• Code Integrity Policies, which specify which binaries, certificates, and publishers are considered trusted.
• Secure Boot configuration and VBS to prevent malicious code loads in early stages of the System.
• Integration with deployment and management tools (such as Intune, GPO, SCCM) to distribute signed policies.

Device Guard's behavior can be more or less strict depending on the mode chosen:

• Standalone user mode (similar to a test or custom mode), where the user maintains a certain degree of control and restrictions are less rigid. In business environments, this is not ideal because it allows for human error.
• Organization-managed mode (Enterprise-managed or Enterprise-enabled), where the administrator defines white, grey, and black lists to precisely control what is allowed.

In this business approach, policies typically handle three types of domains or sites:

• Trusted site (Trusted sites): equivalent to whitelists. These are well-known domains where the risk is considered low, so the browser or application Upload the content directly to the device with fewer additional restrictions.
• Neutral sites (Neutral sites): Domains that may contain sensitive information (corporate or personal) and whose handling depends on the context. If accessed from a secure environment, that protection will be maintained; if accessed from a completely trusted site, the behavior can be more permissive.
• Untrusted sites (Untrusted sites): equivalent to blacklists. Any content originating from these domains is opened within an isolated environment, leveraging virtualization technology to minimize risks.

In parallel, Device Guard is often used in conjunction with other layers such as Application Guard and Exploit Guardwhich monitor the downloading and execution of potentially dangerous files, as well as the exploitation of known vulnerabilities, generating alerts and blocks when necessary.

Application Guard and Exploit Guard: additional reinforcement

In addition to Credential Guard and Device Guard, Windows integrates technologies such as Application Guard (focused especially on the browser and critical applications) and Exploit Guard, which extend the concept of insulation and hardening.

Application Guard creates a virtualized environment for running websites or applications potentially dangerous. When accessing domains marked as untrusted, the system forces them to be loaded within this VBS-based "isolated box," preventing malicious content from affecting the main system or stealing data.

This solution works in conjunction with the previously mentioned site lists (trusted, neutral, and untrusted) and Device Guard policies. This creates a model in which The browser and certain key applications work in an encapsulated way. when they access risky resources.

Exploit Guard, on the other hand, brings together a set of measures to mitigate vulnerabilities in the system and applications, hardening elements such as:

• Memory protection to prevent arbitrary executions.
• Blocking suspicious behaviors typical of exploits.
• Controlled Folder Access to defend against ransomware.

The combination of Credential Guard, Device Guard, Application Guard, and Exploit Guard provides a layered armor which makes modern attacks much more difficult, especially those that seek to move laterally through the network or hijack credentials.

Corporate use: Windows 10/11, Windows Server 2016 and related new features

In the server arena, Windows Server 2016 introduced many of the capabilities already seen in Windows 10, but adapted to the data center environment. Regarding security, in addition to the integration of Windows Defender as the default antivirusDevice Guard and Credential Guard stand out as key tools for hardening the operating system. For more details on these improvements and new features, see [link to relevant documentation]. Advanced security and key new features in Windows Server.

Thanks to these technologies, it is possible Protect domain controllers, application servers, and file servers against credential theft and the execution of unauthorized binaries. This becomes especially relevant when combined with other new features of the Windows Server 2016 ecosystem:

• Support of nested virtualizationwhich allows Hyper-V to run within virtual machines, facilitating complex laboratories and testing environments.
• Additional tools such as performance analyzers or deployment systems for equipment that will not join a domain.
• New capabilities in PowerShell 5.1, including DSC (Desired State Configuration), PackageManagement/OneGet, and PowerShell Direct for managing virtual machines or containers without the need for traditional network connectivity.

In the area of ​​infrastructure, Windows Server 2016 also incorporates improvements in roles such as DNS (DNS policies for conditional responses), IPAM (centralized IP addressing management), IIS 10 with HTTP/2 supportas well as storage technologies such as ReFS, NTFS deduplication, Storage Replica and Storage Spaces, which, while not a direct part of Credential Guard or Device Guard, are part of the security and availability ecosystem.

Remote Credential Guard, Citrix, and credential delegation

Remote Credential Guard expands the Credential Guard philosophy to remote connections scenarioespecially with RDP and desktop virtualization solutions. The idea is that user credentials are not transmitted unprotected to the remote host, but rather that Kerberos is used securely and supported within the client's isolated environment.

Citrix relies on this approach for its functionality of Enhanced domain transfer for SSO in the Citrix Workspace application and in virtual desktop and application sessions, provided that the client devices are joined to Active Directory and Citrix StoreFront is used.

Some key points of this function are:

• It is not supported on 32-bit operating systems.
• It replaces the legacy transfer authentication based on ssonsvr.exe.
• It cannot be enabled simultaneously with legacy transfer authentication on the same session host.
• Whereas legacy authentication required enabling the "Enable MPR notifications for system" policy, enhanced transfer allows SSO without that policy.
• For cross-domain authentication, a bidirectional transitive trust to obtain service tickets across domain boundaries; otherwise, Kerberos delegation will not work.

In terms of configuration, integration with Remote Credential Guard requires a series of steps in StoreFront, Citrix policies, session hosts, and client computers.

StoreFront and Citrix: Setting up SSO with Remote Credential Guard

For enhanced domain transfer to work correctly, StoreFront must be configured to accept domain transfer authentication both in the warehouse and on the associated website.

The general steps are:

• Open the StoreFront administration console.
• go to section Warehouse > Manage authentication methods, where the window corresponding to the website is displayed.
• Check the “Domain Transfer” box and accept.

For the website:

• In the same StoreFront console, access the tab Storage > Receiver for Web > Manage Receiver for Web sites > Configure > Auth methods.
• In the site modification window, select the “Domain Transfer” checkbox.
• Apply the changes.

Subsequently, the Citrix policy for enhanced domain transfer:

• From Citrix Studio or the web console, go to Policies and create a new one.
• Look for the setting “Enhanced domain transfer for single sign-on”.
• Set it as “Allowed”.
• Save and apply.

In addition, on session hosts it is necessary to configure a Windows policy that allows the delegation of non-exportable credentials:

• Ir a Computer Configuration\Policies\Administrative Templates\System\Credentials Delegation.
• Enable the option “The remote host allows delegation of non-exportable credentials”.
• Restart the session host.

In Windows Server 2016, this specific setting does not appear in the local policy, so if you need to set it locally instead of via GPO, you will have to adjust it through the registry. HKLM\SYSTEM\CurrentControlSet\Control\Lsacreating/modifying the DWORD value DisableRestrictedAdmin with data at 0.

Client device configuration and trusted sites

On the client device side, there's also work to be done. For an enhanced domain transfer SSO experience to be seamless, it's essential to... Enable the feature on the client and trust the StoreFront site.

The enhanced domain transfer feature can be enabled via local policy or GPO:

• Navigate to Computer Configuration\Policies\Administrative Templates\Citrix Components\Citrix Workspace\User Authentication.
• Enable the "Enhanced domain transfer for single sign-on" setting.
• Restart the Citrix Workspace application for the adjustment to take effect.

In parallel, it's necessary to ensure that customers consider the StoreFront URL as part of a local intranet site or trusted siteIf the URL does not belong to an already trusted domain, it can be added using a directive:

• Ir a Computer Configuration\Policies\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security.
• Enable “Site to Zone Assignment List” and add the relevant URLs with your zone (e.g., local intranet or trusted sites).
• Enable the “Login options” option and set it to “Automatic login with current username and password”.

With this set of settings, the customer can Take advantage of Remote Credential Guard and enhanced domain transfer For SSO, provided there are no limitations due to the presence of Windows Defender Credential Guard, as discussed in the known issues section.

Restricted sites zone, ActiveX, and browser hardening

Another important piece of the Windows security puzzle is the configuration of Internet Explorer security zones (which, although in retreat, still influences many components of the system) and, by extension, the way ActiveX controls, scripting, and downloads are handled.

The most stringent policies are found in the restricted areas. Common options that can be adjusted via Group Policy include:

• To allow or not cross-domain data source access.
• Enable or disable active scripts and binary and script behaviors.
• Check if it is allowed drag and drop files or copy/paste between sites and windows.
• Allow or block file downloads and automatic downloads.
• Control the loading of XAML files and the use of META REFRESH.
• Limit the use of ActiveX to explicitly approved domains, both for TDC control and for other controls.
• Restrict script-started windows without size or position limits.
• Manage the use of VBScript, Java, applets, and .NET-dependent components.
• Decide whether to They run antivirus against ActiveX or its use is permitted without antimalware.
• Activate filters like the Cross-Site Scripting (XSS) Filter, Protected Mode or SmartScreen filter.

This entire set of policies is part of a defense-in-depth approach where, in addition to Credential Guard and Device Guard, the aim is to... reduce the attack surface from the browserwhich is usually one of the most common entry points.

ACLs, access control, and PACs: additional security context

Beyond VBS, VSM, and Windows "Guards," system security relies heavily on the Access Control Lists (ACL)In Windows, ACLs define who can access which resources and with what permissions, both at the file system level and in other internal components.

ACLs allow configuration very specific permissions on objects (Object Permissions), beyond the typical read/write. For example, a user can be allowed to read the contents of a file but not change its permissions, or a service can be allowed to modify a record but not delete it.

ACL inheritance also plays a key role, as it facilitates the permissions propagate to subfolders and files without needing to configure them one by one. This needs to be handled carefully: a bad inheritance of permissions can open up more than intended, or conversely, block legitimate processes.

In more advanced scenarios, Windows supports models of policy-based access control (PAC) which allow for the application of more dynamic and contextual rules. All of this is integrated with the logging system, which, although not described in detail here, is another critical component for security and auditing; you can consult our entry on Windows security audit to see how to register and review relevant events.

The relationship with VSM is direct: VSM relies on ACLs and the Windows security model to isolate sensitive parts of the systemensuring that only validated code with the appropriate privileges can interact with the protected components.

With the correct deployment of Credential Guard, Device Guard, Application Guard, Exploit Guard, browser policies, well-designed ACLs, and the use of security baselines, it is possible to build a Windows environment where The credentials are secure, malicious code is very difficult to execute, and common attack vectors are heavily fortified.always maintaining a reasonable balance between security and usability for end users.