# Device Guard

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/device-guard

## Quick definition

Device Guard is a security tool built into Windows that helps protect your computer from malware and untrusted software. It works by creating a virtual security barrier that checks every program before it runs, blocking anything that hasn't been approved by your IT team. This means even if a virus gets onto your computer, Device Guard can stop it from starting up.

## Simple meaning

Think of Device Guard as a very strict bouncer for your computer. When you try to run a program, the bouncer checks a list of approved apps before letting it in. If the program isn't on the list, it doesn't get to run, no matter how legitimate it looks. This is different from regular antivirus software, which waits for a program to act suspicious before stopping it. Device Guard stops the threat before it even has a chance to start.

How does it do this? It uses a special feature of modern computer processors called virtualization. Virtualization is like creating a separate, mini-computer inside your real computer. This mini-computer acts as a security guard. It checks every program against a policy set by your IT department. Because the security guard runs in its own protected space, even if a virus infects your main operating system, it cannot touch the security guard or change the approval list. The policy can be very simple, like allowing only Microsoft-signed apps, or very specific, like allowing only certain versions of your company's accounting software.

In plain terms, without Device Guard, your computer relies on antivirus to catch bad software after it has started. With Device Guard, the bad software never gets permission to start in the first place. This makes it an incredibly powerful tool for businesses that need to keep their systems secure from advanced malware and ransomware. For example, if an employee receives a fake invoice email with a malicious attachment, Device Guard will block that attachment from running, even if the employee double-clicks on it. The employee never sees a malware infection, because the bouncer never lets it in the door.

## Technical definition

Device Guard is a combination of hardware and software security features in Windows 10 and Windows 11, designed to provide application control and code integrity assurance. It relies on two main components: Hypervisor-Protected Code Integrity (HVCI) and Virtualization-Based Security (VBS). HVCI, also known as Memory Integrity, runs the Kernel Mode Code Integrity (KMCI) service inside a virtual secure mode environment, isolated from the main operating system. This prevents kernel-level malware from tampering with the code integrity checks. VBS uses the Windows Hyper-V hypervisor to create a secure, isolated region of memory, ensuring that critical security processes are protected even if the OS kernel is compromised.

The core of Device Guard is a Code Integrity (CI) policy, which is an XML file that defines which binaries are allowed to execute. These policies can be signed and locked down, preventing any local or remote modification. The CI policy can be applied in two modes: Audit Mode, which logs violations without blocking, and Enforce Mode, which blocks untrusted software. Policies are typically deployed via Group Policy or Mobile Device Management (MDM) like Microsoft Intune. The CI policy can specify trust based on the binary's digital signature, its publisher, its hash, or even its file path (though file paths are less secure).

Device Guard requires specific hardware to operate. It needs a 64-bit processor with second-level address translation (SLAT), virtualization extensions (VT-x or AMD-V), and IOMMU support. The system must have UEFI Secure Boot enabled, and TPM 2.0 is strongly recommended. Once configured, Device Guard integrates with Windows Defender Application Control (WDAC), which replaced the older Device Guard branding in later Windows versions. WDAC provides more granular control and is the current recommended approach. In an MD-102 exam context, you would configure Device Guard policies using Microsoft Intune, deploying a signed policy XML to Windows 10/11 devices enrolled in endpoint management. The policy is applied during boot, and any unapproved driver or executable is blocked from loading, preventing both user-mode and kernel-mode code execution.

## Real-life example

Imagine you are the manager of a private library. The library has a security guard at the front door. But this isn't a normal security guard. This guard has a magic tablet that is physically locked inside a bulletproof glass booth. The guard cannot open the booth, and no one from the library can touch the tablet. The tablet contains a list of approved books. Every time a visitor tries to bring a book into the library, they must show it to the guard through a slot. The guard scans the book's barcode and checks it against the tablet's list. If the book is on the list, the guard releases the door. If the book is not on the list, the guard locks the door and triggers an alarm. The magic tablet is protected because it's in a separate, armored booth.

Now, map this to Device Guard. The library is your Windows computer. The books are applications and drivers. The security guard is the Code Integrity service. The bulletproof glass booth is the virtual secure mode created by VBS. The magic tablet is the CI policy. The separation between the guard and the library is the key: even if a virus (a thief) breaks into the main library and steals all the keys, it cannot get into the glass booth to change the approved book list. The guard continues to enforce the original policy.

This analogy highlights how Device Guard differs from antivirus. A regular antivirus is like a regular guard who walks around the library and watches for people stealing books. But if the guard gets distracted or if the thief is clever, the theft happens. With the magic tablet guard, the theft never begins because the book is not allowed in. This is the power of Device Guard: prevention, not just detection.

## Why it matters

In the real world of IT, Device Guard matters because traditional antivirus solutions are no longer enough to stop sophisticated attacks. Ransomware, zero-day exploits, and fileless malware can bypass signature-based detection. Device Guard provides a hardware-enforced trust boundary that can stop entire classes of attacks. For an organization that manages hundreds or thousands of Windows devices, Device Guard drastically reduces the attack surface. It ensures that users cannot accidentally run malicious software, even if they have local administrative rights in some cases, because the policy is enforced at a level below the operating system.

From a practical management standpoint, Device Guard is a key tool for compliance. Many regulatory frameworks (like HIPAA, GDPR, PCI-DSS) require that only authorized software runs on systems that process sensitive data. Device Guard gives administrators a concrete way to demonstrate that control. It also helps with license compliance and reducing support costs. If only approved applications can run, you eliminate the problem of users installing unlicensed or unsupported software that causes system instability.

However, Device Guard is not a set-it-and-forget-it solution. It requires careful planning. You need to audit all the applications in your environment, create an initial audit-mode policy, monitor logs, and then move to enforcement. If you enforce a policy that blocks a legitimate line-of-business application, you can break critical workflows. Update management becomes more complex, as every new version of an application must be included in the CI policy. Despite these challenges, the security benefits are immense. For the MD-102 exam, understanding how to deploy and manage Device Guard via Intune is directly relevant to the 'Plan and implement endpoint security' objective domain.

## Why it matters in exams

Device Guard is particularly relevant to the Microsoft MD-102 exam, 'Microsoft 365 Endpoint Administrator'. It falls under the objective domain 'Deploy and manage endpoints' and, more specifically, 'Plan and implement endpoint security'. In this exam, you are tested on your ability to manage Windows client security features using Microsoft Intune. You need to know how to create and deploy Windows Defender Application Control (WDAC) policies, which are the modern implementation of Device Guard. The exam expects you to understand the prerequisites: hardware requirements (SLAT, virtualization, TPM 2.0), Secure Boot, and the difference between Device Guard and Credential Guard (which protects secrets, not app execution).

Question types on the MD-102 exam often include scenario-based questions. For example, you might be given a company that has a strict security policy requiring that only Microsoft-signed apps run on finance department workstations. You will need to choose the correct solution: create a WDAC policy, assign it to the finance device group in Intune, and enable HVCI (Memory Integrity). Another question type might ask about troubleshooting failed deployments. You might see a question where a Device Guard policy is configured but not applied because the device doesn't have virtualization enabled in the BIOS. You would need to identify that as the root cause.

The MD-102 exam also tests your understanding of policy scope. You might need to decide between using a base policy (like 'Allow Microsoft store apps and Microsoft signed apps') versus a supplemental policy. You need to know that Device Guard policies can be signed and that signing requires a certificate that you manage. The exam does not ask you to write a CI policy XML from scratch, but you must understand the settings in the Intune UI for WDAC. The exam focus is on planning, deployment, and troubleshooting of Device Guard/WDAC via enterprise management tools like Intune.

## How it appears in exam questions

In the MD-102 exam, Device Guard typically appears in scenario-based multiple-choice questions. A common pattern is: 'Your company wants to prevent users from running unapproved executables on Windows 10 devices. Which feature should you configure?' The correct answer would be Windows Defender Application Control (Device Guard). Distractors might include AppLocker, Windows Defender Firewall, or BitLocker. You need to know that AppLocker is a different technology (it runs in the user context and can be bypassed by administrative users), while Device Guard/WDAC runs in the kernel and is hardware-enforced.

Another frequent pattern involves configuration troubleshooting: 'You deploy a WDAC policy to a device, but it is not enforced. You verify the policy is assigned correctly. What is the most likely cause?' Options might include: the device does not have Secure Boot enabled, the device does not have virtualization enabled, the policy was not rebooted, or the policy was created in audit mode. The correct answer is often that the device requires a reboot after the policy is applied, or that the BIOS setting for virtualization is disabled.

There are also 'best practice' questions: 'You are planning a WDAC deployment for 500 devices. What should you do first?' The correct approach is to create an audit-mode policy, deploy it, review event logs for application blocks, add any legitimate applications to the policy, then switch to enforce mode. Wrong options might include deploying the enforce policy immediately, or using a file path rule for all applications. The exam emphasizes the importance of auditing before enforcement. Finally, you might see a question about hardware prerequisites: 'Which hardware feature is required for Device Guard?' with options like TPM 2.0, Secure Boot, SLAT, or all of the above. The correct answer is all of the above, but SLAT is the most specific requirement.

## Example scenario

Contoso Ltd. is a mid-sized company that provides financial consulting services. They have 200 Windows 11 laptops used by consultants who travel frequently. The IT security team is concerned about the increasing risk of ransomware delivered via email phishing. They want to ensure that even if a consultant accidentally opens a malicious attachment, the ransomware cannot execute. The IT team decides to implement Device Guard using Windows Defender Application Control via Intune. They choose a base policy that allows only Microsoft-signed applications and Microsoft Store apps. They create this policy and assign it to a device group containing all consultant laptops. After deployment and a reboot, the consultants can still use Microsoft Office, Teams, and the web browser without any issues. However, one consultant tries to install a personal PDF editor that he downloaded from the internet. The installation fails silently. The consultant calls the help desk, and the IT team checks the Code Integrity event log (Event ID 3076). They see that the PDF editor binary was blocked because it was not signed by a trusted publisher. The IT team explains to the consultant that only approved applications can run on company devices. This scenario demonstrates how Device Guard proactively prevents malware execution, even when the user is tricked into trying to run the malicious file. The consultant's action was blocked before any harmful code could execute, protecting both the device and potentially sensitive client data.

## Common mistakes

- **Mistake:** Assuming Device Guard is the same as AppLocker and can be used interchangeably.
  - Why it is wrong: AppLocker runs in the context of the user and kernel, but it can be bypassed by a user with administrative rights who can stop the AppLocker service or modify rules. Device Guard runs in a virtual secure mode isolated from the OS, so even an administrator cannot disable it without rebooting and changing the policy, which requires the correct signed policy file.
  - Fix: Use Device Guard (WDAC) for high-security environments where you need to protect against kernel-level threats, and use AppLocker for lighter application control where users are not administrators.
- **Mistake:** Deploying a WDAC policy in enforce mode without first auditing the environment.
  - Why it is wrong: This will likely block legitimate line-of-business applications, causing operational downtime and user frustration. The organization may lose access to critical software that wasn't included in the initial policy.
  - Fix: Always start with an audit-mode policy. Review the event logs over several days to identify all trusted applications. Then, create an enforce-mode policy that includes those trusted binaries.
- **Mistake:** Thinking Device Guard requires no specific hardware and works on any Windows device.
  - Why it is wrong: Device Guard requires specific hardware features: 64-bit CPU with SLAT, virtualization extensions, IOMMU, UEFI Secure Boot, and TPM 2.0. Older hardware or devices with disabled virtualization will fail to apply the policy.
  - Fix: Before planning a Device Guard deployment, verify that all target devices meet the hardware prerequisites. Check BIOS settings for virtualization and Secure Boot status. Use the Windows Defender System Guard validation tool or the HResult check.
- **Mistake:** Believing that once a WDAC policy is applied, it can be easily removed or modified by a local administrator.
  - Why it is wrong: If the WDAC policy is signed and locked down, only a signed replacement policy (or a signed disable policy) can change it. Local admins cannot delete or modify the policy files because they are protected by the hypervisor.
  - Fix: Always keep a backup of the signed policy files. If you need to remove the policy, deploy a signed policy that disables WDAC, or reinstall Windows. Plan for this in your deployment strategy.
- **Mistake:** Confusing Device Guard with Credential Guard and thinking they protect the same thing.
  - Why it is wrong: Device Guard controls which applications can run. Credential Guard protects user credentials (like NTLM hashes) by isolating the Local Security Authority (LSA) process in a virtual secure environment. They serve different security functions.
  - Fix: Remember: Device Guard = app control. Credential Guard = credential protection. They can be used together, but they are not the same.

## Exam trap

{"trap":"The exam may present a scenario where a user has administrative rights on a Windows device and wants to run a self-written script. The question asks which security feature would block this script regardless of the user's admin rights. Many learners choose AppLocker, thinking it can block scripts.","why_learners_choose_it":"Learners often assume that AppLocker is the tool for blocking scripts because they know AppLocker has rules for scripts (e.g., .ps1, .vbs). They may also think that an admin can override AppLocker, but some believe AppLocker is still effective against admin users.","how_to_avoid_it":"Remember that if a user is a local administrator, they can stop the AppLocker service or bypass it. Device Guard, on the other hand, runs in a protected virtual environment and cannot be tampered with even by an admin. So for blocking scripts for administrative users, Device Guard with WDAC is the correct answer, especially if the script is not signed by a trusted publisher."}

## Commonly confused with

- **Device Guard vs AppLocker:** AppLocker is a Windows feature that allows administrators to control which applications users can run. However, AppLocker runs in the user and kernel context and can be disabled by users with administrative privileges. Device Guard runs in a hypervisor-isolated environment, making it much more secure and resistant to tampering. Device Guard is preferred for high-security environments. (Example: A local admin can stop the AppLocker service to run a blocked app, but they cannot stop Device Guard without a signed policy change.)
- **Device Guard vs Credential Guard:** Credential Guard protects user authentication credentials (like password hashes) by isolating the LSA process in a virtual secure environment. Device Guard controls which applications can execute on the system. They both use VBS but serve different purposes. Credential Guard does not block applications, and Device Guard does not protect credentials. (Example: Credential Guard stops Pass-the-Hash attacks by protecting the hash. Device Guard stops ransomware by blocking the ransomware executable.)
- **Device Guard vs BitLocker:** BitLocker encrypts the entire hard drive to protect data at rest. If a device is stolen, BitLocker prevents the thief from reading the data without the decryption key. Device Guard controls what software can run while the system is on. They address different security needs: data protection vs. malware prevention. (Example: BitLocker protects your files if your laptop is stolen. Device Guard protects your system from running a malicious program while you are using it.)
- **Device Guard vs Windows Defender Antivirus (Microsoft Defender Antivirus):** Windows Defender Antivirus is a real-time protection solution that detects and removes malware based on signatures and behavior analysis. Device Guard prevents untrusted code from running at all, often before the antivirus would even scan it. They are complementary: Device Guard blocks the file from execution, and antivirus scans it if it is allowed. (Example: An unknown executable gets downloaded. Device Guard blocks it from running because it's not signed. Antivirus never gets a chance to scan it, because it never runs.)

## Step-by-step breakdown

1. **Step 1: Plan and Audit Your Environment** — Before implementing Device Guard, you must identify all the applications and drivers that are used in your organization. Deploy a WDAC policy in audit mode to a test group. Review event logs (Event ID 3075, 3076, 3077) to capture all blocked binaries. This ensures you do not accidentally block legitimate software.
2. **Step 2: Create the Code Integrity Policy** — Using the Windows Defender Application Control (WDAC) tools or the Intune console, create a base policy. You can choose from templates (e.g., 'Allow Microsoft trusted apps' or 'Allow only signed apps'). The policy is an XML file that contains rules for trusted publishers, file hashes, or signers. You can also create supplemental policies for additional rules.
3. **Step 3: Sign the Policy (Recommended)** — For production environments, sign the policy using a code signing certificate. A signed policy cannot be modified or removed without the signing certificate, providing protection against tampering. The policy file (e.g., SIPolicy.p7b) is then deployed.
4. **Step 4: Deploy the Policy via Intune or Group Policy** — In the MD-102 context, you would deploy the signed WDAC policy using Microsoft Intune. Create a configuration profile for Windows Custom or use the 'Windows Defender Application Control' setting. Assign the profile to the appropriate device group. The policy is applied after a reboot.
5. **Step 5: Enable Virtualization-Based Security (VBS) and Memory Integrity** — Device Guard requires VBS to be enabled. You can enable this through Intune or Group Policy. Ensure that hardware virtualization is on in the BIOS. Enable 'Memory Integrity' (HVCI) in Windows Security or via Intune. This step is critical for the security isolation.
6. **Step 6: Reboot and Test** — After deploying the policy and enabling VBS, reboot the target device. Verify that the policy is enforced using the 'System Information' tool (look for 'Device Guard' line). Attempt to run an unapproved application to confirm it is blocked. Check event logs for successful blocking events.
7. **Step 7: Transition from Audit to Enforce Mode** — After you are confident that your audit-mode policy is not blocking critical apps, you can switch to enforce mode. Update the policy XML to set the enforcement mode, sign it again, and redeploy. Monitor logs continuously to catch any new applications that need to be added.

## Practical mini-lesson

Let's get practical. You are an endpoint administrator for 500 Windows 11 devices. Your task: implement Device Guard using WDAC via Intune. First, you need to understand that Device Guard is not a single setting; it is a combination of technologies. You will be working primarily with the 'Windows Defender Application Control' settings in the Intune console. To begin, create a test group of 10 devices. Enroll them in Intune and confirm they have the required hardware. You can check this by running 'msinfo32' and looking at the 'Device Guard' line at the bottom of the System Summary. If it says 'Running', you are good.

Now, create the WDAC policy. In Intune, go to 'Endpoint security' > 'Application control' and create a new policy. Choose 'Windows 10 and later' and 'Windows Defender Application Control'. You will be presented with options to choose a policy template. For most organizations, the 'Base policy – Allow Microsoft store apps and Microsoft signed apps' is a safe starting point. This allows all Windows and Microsoft Store apps to run, while blocking unsigned and non-Microsoft signed executables. You can then add additional rules for your specific line-of-business apps by adding their signer certificates or file hashes. Do not use file path rules for security-critical deployments, as they are easy to bypass.

A common pitfall: forgetting to enable virtualization in the BIOS. If a device does not have virtualization enabled, Device Guard will not work, and the policy will not be enforced. You can use Intune to deploy a script that warns if virtualization is off. Also, remember that after you deploy the policy, the device must be rebooted for the policy to take effect. The policy is enforced during boot, before any user-mode processes start. After the reboot, test by downloading a small unsigned executable (like a random tool) and try to run it. You should get a block message. Check Event Viewer under 'Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational' for events. If you see Event ID 3076, the block worked.

What can go wrong? Your WDAC policy might block a legitimate driver or update. For example, a printer driver might not be signed by a publisher you trusted. This is why you always start in audit mode. In audit mode, the same events are logged, but the application is allowed to run. You review the logs, identify the missed driver, add its signer to the policy, and then roll out the updated policy. Once you are satisfied, you switch to enforce mode by editing the policy in Intune and setting the enforcement mode to 'Enforce'. Remember to sign the policy if you are using signed policies; otherwise, a local admin could potentially replace the policy file on a compromised machine. In a real enterprise, you would use a certificate from a public CA or an internal PKI for signing.

## Memory tip

Device Guard = Guard the Device: It uses a hypervisor guard to lockdown which apps can run, like a bodyguard for your computer.

## FAQ

**Does Device Guard work on Windows 10 Home edition?**

No, Device Guard requires Windows 10/11 Enterprise or Education editions. It is not available on the Home or Pro editions without additional tools.

**Can I use Device Guard and AppLocker together?**

Yes, they can be used together, but it is generally recommended to use Device Guard (WDAC) for kernel-level control and AppLocker for user-mode scripting control (like .ps1 files) if needed. Be careful not to create conflicting rules.

**What happens if I need to run an unsigned but legitimate application?**

You can add the application's file hash or publisher signer to the WDAC policy. This requires careful management and testing. In audit mode, you can identify such applications and update the policy before enforcing.

**Is Device Guard the same as Hyper-V?**

No, but Device Guard uses the Hyper-V hypervisor to create the isolated environment (VBS). Hyper-V is a full virtualization platform for running VMs, while Device Guard uses a subset of its features for security isolation.

**Does enabling Device Guard affect system performance?**

There can be a minor performance impact due to the overhead of virtualization and HVCI. Modern processors handle this well, but older systems may see a noticeable slowdown. It is usually negligible for typical business workloads.

**Can I disable Device Guard after it is deployed?**

If the policy is signed and locked down, you cannot disable it without a signed disable policy. If it is not signed, local admins with physical access can delete the policy file, but this is not recommended. Plan carefully before deployment.

## Summary

Device Guard is a powerful, hardware-enforced application control feature in Windows that prevents untrusted software from running. Unlike traditional antivirus, it blocks malware before it can execute, providing a critical layer of defense. It works by using virtualization-based security to isolate the code integrity checking process from the main operating system, making it tamper-proof even against administrative users. For IT professionals targeting the MD-102 exam, understanding Device Guard is essential for the endpoint security objective. You need to know the hardware requirements (SLAT, virtualization, TPM), the difference between Device Guard and AppLocker, and how to deploy and manage policies via Intune. 

Real-world implementation requires careful planning: start with audit mode, review logs, and only then enforce. Common mistakes include deploying in enforce mode without auditing, confusing Device Guard with Credential Guard, and ignoring hardware prerequisites. The exam tests you on scenario-based questions where you must choose between security features or troubleshoot deployment issues. By mastering Device Guard, you not only prepare for the exam but also acquire a skill that is highly valued in enterprise security roles. Remember, Device Guard is about prevention: it stops the bad stuff before it even starts. This makes it a cornerstone of modern Windows security.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/device-guard