Device Guard and Windows Defender Application Control (WDAC) are enterprise-level security technologies that enforce a Zero Trust model where only authorized apps can run. For small to medium-sized businesses (SMBs), deploying these capabilities via Intune offers a scalable, cloud-managed solution to harden endpoints against lateral movement and shadow IT threats.
This guide provides a comprehensive walkthrough for configuring Application Control policies and Device Guard in Intune, from understanding components to deployment strategies and validation techniques.
Steps to configure Device Guard and Application Control Policies via Intune
Here are the requirements you need to have in place to configure Device Guard and Application Control Policies via Intune:
📌 General prerequisites:
- Microsoft Intune (Microsoft Endpoint Manager)
- Windows 10/11 Pro, Enterprise, or Education edition
- Device Guard and WDAC-capable hardware (UEFI, virtualization extensions)
- Administrative access to endpoints and the Intune portal
- Optional: NinjaOne RMM access for monitoring and supplemental enforcement
Step 1: Understand Device Guard and WDAC components
Before you set anything up, it’s crucial to understand what Device Guard and WDAC are and how they work together to keep your systems secure:
What is Device Guard in Intune?
Device Guard is a built-in set of security technologies in Windows that locks down devices so they can run only trusted applications. It combines several powerful components under one umbrella:
- Credential guard – Protects credentials from attacks using Virtualization-Based Security (VBS).
- Code Integrity (CI) – Ensures only signed, trusted code executes.
- Application control (WDAC) – Defines which apps, executables, scripts, and DLLs can run on the device.
Together, these technologies enforce a Zero Trust execution model, where nothing runs unless explicitly allowed.
How are policies configured?
Device Guard and WDAC policies are configured via XML or Configuration Service Provider (CSP) and applied using Intune or local script enforcement.
Step 2: Choose a deployment method
With the core concepts in place, it’s time to choose a deployment method that aligns with your infrastructure (Intune-managed, on-prem AD, or hybrid).
Method A: Create a WDAC policy using PowerShell
This method gives you full control over what’s allowed to run, based on what’s already present on your reference system.
📌 Use Cases:
- You want a custom allowlist for high-security environments
- You’re testing WDAC on a limited device group
📌 Prerequisites:
- You must run PowerShell as Administrator
- PowerShell 5.1+ for local policy creation
Step-by-step:
- Press Win + S and search for PowerShell.
- Right-click Windows PowerShell in the results and select Run as Administrator. (Check #2 in ⚠️ Things to look out for.)
- Create a default WDAC policy (audit mode):
$policyPath = "C:\Policies\WDAC_Policy.xml"New-CIPolicy -Level Publisher -Fallback Hash -FilePath $policyPath -UserPEs
- Convert XML to binary:
ConvertFrom-CIPolicy -XmlFilePath $policyPath -BinaryFilePath "C:\Policies\WDAC_Policy.bin"
- Optional: Enable audit mode only: (Check #1 in ⚠️ Things to look out for.)
Set-RuleOption -FilePath $policyPath -Option 3 # 3 = Audit Mode
You can now use this policy in Intune as a custom OMA-URI configuration, or deploy it manually on test machines.
Method B: Deploy Device Guard/WDAC via Intune
This method uses Intune’s Endpoint Security blade to create and deploy WDAC rules. This is the most scalable way to deploy WDAC policies across multiple devices.
📌 Use Cases: Best for cloud-first SMBs and enterprises
📌 Prerequisites:
- Devices must be Azure AD-joined or Hybrid AAD-joined and Intune-enrolled
- Proper licensing for Intune (Microsoft 365 Business Premium, E3+, etc.)
Step-by-step:
- Navigate to Microsoft Intune Admin Center > Endpoint Security > Attack surface reduction > Create policy.
- Choose platform and profile:
- Platform: Windows 10 and later
- Profile: Windows Defender Application Control
- Configure the policy:
- Use audit mode initially. This means blocked activity will be logged without actually blocking it. (Check #1 in ⚠️ Things to look out for.)
- Enforce rules after testing (signed Microsoft apps, Windows components only).
- Enable Intelligent Security Graph integration.
- Assign the policy to a test group or subset of endpoints. (Check #3 in ⚠️ Things to look out for.)
- Once validated, switch to Enforcement mode. This time, only trusted apps will run, and untrusted apps will be blocked.
Method C: Enforce via Group Policy (optional/hybrid)
This method is best for hybrid or on-premises AD where Intune isn’t fully in use or Group Policy remains the main configuration mechanism.
📌 Use Cases: Best for organizations transitioning from on-prem to cloud.
📌 Prerequisites: Devices must be AD-joined (on-prem or hybrid)
Step-by-step:
- Press Win + R, type gpedit.msc, and click Enter to launch the Group Policy Editor.
- Navigate to:
Computer Configuration > Administrative Templates > System > Device Guard
- Enable:
- Turn on Virtualization-Based Security
- Turn on Credential Guard
- Deploy Windows Defender Application Control
Use GPOs for on-premises or hybrid domain-joined devices when Intune is not available.
Step 3: Validate application control with PowerShell and event logs
After deployment, confirm that the policy is active and working.
📌 Use Cases: Use this for compliance/audits or to avoid service disruption from false positives.
📌 Prerequisites: PowerShell 5.1+ for local policy verification
Check via PowerShell
- Open PowerShell.
- Run the following command to confirm WDAC status:
Get-CIPolicy | Format-List
- Check audit logs: (Check #4 in ⚠️ Things to look out for.)
Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" | Format-Table TimeCreated, Id, Message -AutoSize
- Verify Credential Guard:
Get-CimInstance -ClassName Win32_DeviceGuard
Expect output showing VirtualizationBasedSecurityStatus = 2 for active status.
Check via Event Viewer
- Press Win + R, type eventvwr.msc, and click Enter to open the Event Viewer.
- Navigate to Applications and Service Logs > Microsoft > CodeIntegrity > Operational.
- Look for:
- Event ID 3033 – WDAC policy successfully loaded
- Event ID 3076 – App blocked by WDAC (enforced mode)
- Event ID 3099 – App would have been blocked (audit mode)
These events confirm whether the WDAC policy was successfully applied and whether apps were blocked or would have been blocked.
Step 4: Use Registry to confirm or enforce settings
This method pushes WDAC policies to devices and monitors if Device Guard, Credential Guard, or VBS are enabled.
📌 Use Cases: Use this if you’re validating settings enforcement post-deployment.
📌 Prerequisites:
- Administrator privileges required (Check #2 in ⚠️ Things to look out for.)
- Device Guard settings deployed (GPO or Intune)
⚠️ Warning: Editing the registry can cause system issues. Create a backup before proceeding.
Step-by-step:
- Press Win + R, type regedit, and click Enter to launch the Registry Editor.
- Navigate to the WDAC and Device Guard registry keys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
EnableVirtualizationBasedSecurity (DWORD) = 1RequirePlatformSecurityFeatures (DWORD) = 1
- Credential Guard registry validation:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
LsaCfgFlags (DWORD) = 1
Use PowerShell or NinjaOne custom fields to read and report these values at scale.
⚠️ Things to look out for
| Risks | Potential Consequences | Reversals |
| 1. Skipping audit mode | May block critical business tools and cause user lockout or service disruptions. | Switch the policy back to audit mode or disable enforcement. |
| 2. Running scripts or tools without elevated privileges | Registry changes may fail, or policies may not apply. | Always run scripts or tools with Administrator privileges. |
| 3. Deploying Intune policy to the wrong target | The policy may not apply or may fail silently. | Reassign the policy to the right device groups and confirm the assignment scope. |
| 4. Lack of visibility into policy behavior | Missed blocks, no audit trail, and blind enforcement. | Enable CodeIntegrity logging; collect logs with Intune or NinjaOne. |
Why Device Guard and WDAC matter for SMBs
Small to Medium-sized Businesses (SMBs) are generally defined by their workforce size and revenue. They operate with leaner teams and fewer on-premises resources compared to large enterprises, yet they face the same security threats. This means they need solutions that aren’t overly complex but still effective.
Device Guard and WDAC deliver that balance for SMBs. Here’s how they help:
- Intune lowers administrative overhead by streamlining deployment and monitoring.
- With cloud-first management, policies are delivered and enforced without relying on on-premises infrastructure.
- Enhanced endpoint security comes from WDAC’s ability to block untrusted or malicious applications.
- Intune and WDAC deliver enterprise-grade protection at scale with security controls applied consistently across devices.
- Application control reduces the attack surface by limiting entry point for threats and lateral movement.
Additional considerations
Here are key points to keep in mind when deploying Windows Defender Application Control (WDAC):
Test in audit mode first
Before enforcing WDAC in production, start by testing in Audit Mode. This mode logs applications that would have been blocked without actually preventing them from running, allowing you to assess the impact of your policy safely.
Policy signing
In some environments, WDAC policies must be digitally signed with a code-signing certificate to be enforced under Secure Boot. Signed policies ensure integrity and trust, while unsigned policies may be ignored or run only in audit mode.
Update compatibility
Each Windows update may introduce new system files or drivers or change existing ones, which may be inadvertently blocked by WDAC. Always validate your policy after major updates. You may also temporarily switch to audit mode post-update to log any new blocks and identify files requiring exceptions.
Exception handling
SMBs often rely on third-party tools, scripts, or automation agents that may not be signed and could be blocked by WDAC. Use allow rules based on file path, hash, or publisher in this case.
💡 Tip: Maintain a list of trusted tools that must be allowlisted and regularly review and update exception rules to avoid disruptions.
Troubleshooting
Below are common problems encountered when configuring WDAC, and how to resolve them:
Blocked apps
Blocked apps indicate that WDAC is functioning correctly by blocking an application that doesn’t match the allowlist. In this case, check CodeIntegrity logs for executable hashes:
- Press Win + R, type eventvwr.msc, and click Enter to open the Event Viewer.
- Navigate to:
Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational
- Look for Event ID 3076 and Event ID 3099 to see blocked executables and their hashes.
- Use the file hash or path from the event to create an exception rule.
Policy not applying
If a device isn’t receiving or applying the policy, here’s what you can do:
- Force a sync on the endpoint:
- Open Settings (Win + I) > Accounts > Access work or school > Info > Sync
- Verify Intune policy deployment status:
- Navigate to Microsoft Intune Admin Center > Devices > [Device name] > Device configuration
- Review the policy status (Pending, Succeeded, or Failed)
- Verify targeting:
Confirm that the device is in the correct group assignment and that the policy applies to devices, not just users.
Credential guard fails
Remember that Credential Guard requires certain hardware features, including Virtualization support and Secure Boot. Here’s how you can check if they are supported on the device:
- Reboot into BIOS/UEFI and verify:
- Secure Boot is enabled
- Virtualization support is turned on
Registry not updating
If registry changes aren’t applying, here’s what you can do:
- Ensure scripts or queries are run with administrator privileges.
- Confirm the registry path and keys exist:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
NinjaOne Services
NinjaOne supports the secure rollout of Device Guard and WDAC policies by:
| Capability | What NinjaOne enables |
| Endpoint hardening automation | Remotely deploy registry and PowerShell-based hardening scripts to endpoints. |
| Registry monitoring and alerting | Track and alert on registry key status related to Device Guard readiness. |
| WDAC policy validation | Automatically collect and review CodeIntegrity logs to verify WDAC policy effectiveness. |
| Compliance-based device tagging | Tag devices by compliance status and policy enforcement outcome. |
| Remediation and audit automation | Automate follow-up remediation or audit reporting based on enforcement gaps. |
With NinjaOne, MSPs can extend and monitor Microsoft security hardening features across clients with minimal overhead.
Configure Device Guard and WDAC for SMBs to strengthen endpoint security and application control
Device Guard and Windows Defender Application Control (WDAC) are powerful tools for securing SMB endpoints by limiting which apps and scripts can run. This guide explored both solutions’ core components and benefits, focusing on how they support a zero-trust execution.
It also provided a detailed guide on deploying, auditing, and enforcing policies using Microsoft Intune, alongside methods using PowerShell, registry, CMD, and GPO for testing and compliance. Finally, the guide showed how NinjaOne helps scale and audit policy deployment across clients for strengthened endpoint security and overall application control.
Related topics:
