Windows 10 Security: Device Guard and Credential Guard – Part 1

Device Guard is a new feature for Windows 10 and Server 2016. It’s actually a combination of several other components, including Credential Guard, that when implemented, will only allow trusted applications that are defined in your code integrity policies. We’re going to look at how it’s implemented, and look at Credential Guard by itself.

In Part 1, we will enable Device Guard and Credential Guard. In part 2, we will publish Device Guard rules.

Device Guard (and its components) are only available in the Enterprise and Education SKUs of Windows 10. It is available on all SKUs on Server 2016.


First, to fully deploy Device Guard, you need to have a certain standard of hardware. Because Device Guard relies on a hypervisor (in this case, Hyper-V), you need hardware that is capable of running virtualization. Requirements are a 64-bit CPU, CPU virtualization extensions (such as VT-x for Intel and AMD-V for AMD processors) when extended page tables, UEFI firmware version 2.3.1.c or higher, HVCI compatible drivers, and Secure Boot enabled. A full list of requirements broken down by version of Windows 10 is available here:

Device Guard can also be deployed in Hyper-V virtual machines, as long as the physical host is running Server 2016 or Windows 10 v1607. The VM itself must be a generation 2 VM.

With compatible hardware, the code integrity service will run alongside the Windows kernel in a hypervisor-protected container, making it nearly impossible for a bad actor to execute malicious code, even if they have control of the Windows kernel.

If you are on Windows 10 v1607, Server 2016, or higher, Hyper-V will automatically be enabled when you turn on Device Guard. If you’re not on at least Windows 10 v1607, you will be enable the Hyper-V and Isolated User Mode Windows Features.


Activating Device Guard and Credential Guard

Turning on Device Guard is really simple – it’s one Group Policy. I recommend making a separate Group Policy for this, as you will likely be linking it several OUs in your environment. Do NOT add it to Default Domain Policy, as you do not want code integrity applied to your domain controllers (more on that in Credential Guard section).

In your new GPO, navigate to Computer Configuration > Administrative Templates > System > Device Guard. Edit the policy “Turn On Virtualization Based Security”. To turn on Device Guard, I recommend these settings:


To only turn on Credential Guard, use these settings:


You can read about the various settings in the Help box. To summarize, the first box has two options – Secure Boot and Secure Boot with DMA. Keeping this at Secure Boot ensures that this policy will apply to all machines. If you set it Secure Boot with DMA, this policy will only apply to computers that can handle DMA, so you’ll likely miss some things. If you leave it at Secure Boot, machines that support DMA will use Secure Boot with DMA.

If you want Device Guard, set the next two boxes to Enabled without lock. The different between “without lock” and “UEFI lock” is that if you lock this, you cannot modify it remotely. You will only be able to disable it going forward with a GPO. This could create support issues, so outside highly secure environments, it’s probably best to keep it “without lock”.

If you only want Credential Guard, set the “Credential Guard Configuration” box to “Enabled without Lock”.

After a restart, you can check that Device Guard or Credential Guard is enabled by running msinfo32.exe and looking at the bottom of the System Summary page. You should see these six entries:


If all you want is Credential Guard, stop here and do not proceed to Part 2. This is enough to enable Credential Guard by itself. To get all of Device Guard, look for Part 2 soon.


All content provided on this blog is for information purposes only. Windows Management Experts, Inc makes no representation as to accuracy or completeness of any information on this site. Windows Management Experts, Inc will not be liable for any errors or omission in this information nor for the availability of this information. It is highly recommended that you consult one of our technical consultants, should you need any further assistance.



Contact Us

On Key

More Posts

WME Security Briefing 27 May 2024

Kinsing Hacker Group Exploits Docker Vulnerabilities Overview Recent investigations have shown that the hacker group Kinsing is actively exploiting Docker vulnerabilities to gain unauthorized access to systems. The modified hacker group targets misconfigured Docker API ports deployed with cryptocurrency mining malware.

Read More »
WME Cybersecurity Briefings No. 010
Cyber Security

WME Security Briefing 20 May 2024

Advanced Persistent Threats: North Korean Hackers Launch Golang Malware Overview A new malware strain, called Titan Stealer, is currently actively circulating in the threat landscape, targeting a variety of personal data and linked to North Korean state-sponsored cyber espionage

Read More »
WME Cybersecurity Briefings No. 009
Cyber Security

WME Security Briefing 08 May 2024

Exploitable vulnerability in Microsoft Internet Explorer, used to deploy VBA Malware Overview Cybersecurity researchers discovered a severe exploitation targeting a bug that had already been patched in the Microsoft Internet Explorer browser. Their report added that

Read More »
WME Cybersecurity Briefings No. 008
Cyber Security

WME Security Briefing 03 May 2024

Security Bulletin: MITRE Corporation Targeted by Nation-State Cyber Attack Overview The MITRE Corporation, a prominent security and cybersecurity researcher in the USA, has fallen prey to compromise in its environment because of a sophisticated cyberattack from

Read More »
Be assured of everything

Get WME Services

Stay ahead of the competition with our Professional IT offerings.