Complete guide to Windows Defender Application Control WDAC

Windows Defender Application Control (WDAC) It has become one of the key pieces of the Windows hardening strategy for companies that want to go beyond simple antivirus and implement a Smart App Control in Windows 11We're not just talking about "not running malware," but about deciding with pinpoint accuracy which binaries, scripts, drivers, and applications are authorized to run on each machine. Properly configured, WDAC can thwart many modern attack techniques, but it can also cause serious problems if implemented without careful planning.

In the following lines you will find a very complete guide about What is WDAC, how does it work, how does it differ from AppLocker, what are its policy formats, how is it signed and deployed, and what typical problems does it present? and how it's used in both traditional Windows scenarios and specific devices like HoloLens 2. We'll weave together all the concepts you've seen scattered across different Microsoft and community sources, but explained in different terms and with a practical approach, so you can decide if WDAC fits your environment and, if so, how to get started without breaking anything.

What is Windows Defender Application Control (WDAC)?

WDAC is an application control technology Introduced with Windows 10, this feature is designed to define exactly what code can run on a device. The rules are applied at the system level, not the user level, so they affect anyone who logs into the machine. The underlying idea is simple: anything not explicitly allowed is blocked.

To decide whether something is allowed or denied, WDAC may rely on multiple file or context attributes:

• Characteristics of the code signing certificate (issuing CA, subject, etc.).
• Signed binary metadata (original filename, version) or directly the file hash.
• Reputation of the archive according to the Microsoft Intelligent Security Graph (ISG).
• Origin of the installationusing the concept of “managed installer” (e.g., software deployed by Intune or SCCM).
• Launch path of the executable or DLL, available since Windows 10 1903.
• Parent process that has launched the binary.

WDAC policies operate both in user mode (UMCI) as in kernel modeTherefore, they can control not only EXEs and scripts, but also drivers and some very sensitive system components. This depth is precisely what makes WDAC much more robust than purely surface-level approaches like AppLocker.

Differences between WDAC and AppLocker

AppLocker has been around for many years And it remains useful, but Microsoft considers it more of an additional layer of defense than the primary solution for application control. WDAC is intended as a "hard" security barrier, while AppLocker is more flexible and permissive.

The key differences between WDAC and AppLocker are:

• Area of ​​applicationWDAC applies to the entire device; AppLocker allows different policies per user or group.
• Depth of controlWDAC can affect drivers, DLLs, and kernel components; AppLocker focuses on EXEs, scripts, installers, and little else.
• Trust modelWDAC is intended for a "zero trust" whitelisting approach (unauthorized activity is blocked), whereas AppLocker is often used as a blacklist.
• CompatibilityAppLocker is useful if you have a mixed environment with older versions of Windows; WDAC shines on modern Windows 10/11 and Server.

Microsoft recommends WDAC as the primary solution of application control, but it doesn't suggest that AppLocker will disappear. In fact, a very common combination in mature companies is to use WDAC as a hard security foundation and add AppLocker to refine restrictions per user or to control specific behaviors (for example, blocking PowerShell (for standard users).

WDAC policy formats: single vs. multiple

A WDAC policy is nothing more than an XML file which is then compiled into a signed binary (.cip or .p7b) that Windows interprets at startup or when refreshing policies. The way these policies are structured has evolved, and today two formats coexist:

1. Single Policy Format

In this model there are only an active policy per deviceIt is the oldest approach and the one that offers the best compatibility:

• It works on any Windows 10 version and on Windows Server 2016 and 2019.
• The final file is called SiPolicy.p7b and is stored in:
  <EFI System Partition>\Microsoft\Boot\SiPolicy.p7b
<OS Volume>\Windows\System32\CodeIntegrity\SiPolicy.p7b
• It is the format that Group Policy uses natively.

2. Multiple Policy Format

With this model you can have several simultaneous policies which combine to form the effective rule set. It offers much greater granularity, but requires modern systems:

• Requires Windows 10/11 version 1903 or later.
• Before the April 2024 update, there was a practical limit of about 32 active policies; from that date onwards, the limit is raised.
• The files are saved as {PolicyId GUID}.cip is available at:
  <OS Volume>\Windows\System32\CodeIntegrity\CiPolicies\Active\
<EFI System Partition>\Microsoft\Boot\CiPolicies\Active\

In this scheme there are two types of policies:

• Base policiesThey are the "foundation" on which everything else is built. They define the general framework (for example, only Windows + Store + signed drivers).
• Supplemental policiesThey extend or refine a base policy without modifying it. They are used to add exceptions, specific rules for a department, etc.

The logic is that the most restrictive policy always wins.If a base allows something but a supplementary layer denies it, a lock is created. This makes it possible to build very flexible architectures, but also architectures that are more complex to maintain.

Basic WDAC templates and trust modes

To avoid starting from scratch, Windows includes several policy templates in the route %windir%\schemas\CodeIntegrity\ExamplePoliciesTools like the WDAC Wizard also allow you to select them visually. The most commonly used ones are:

• Default Windows ModeAuthorizes operating system binaries, Microsoft Store apps, Office 365, OneDrive, Teams, and Windows-compatible drivers Hardware.
• Allow Microsoft Mode: includes all of the above and more all software signed by Microsoft.
• Signed and Reputable Mode: add to the above the files with a good reputation according to the ISG from Microsoft.

Depending on the level of security you require, you can choose a stricter template (Default Windows Mode) or a more user-friendly one (Signed and Reputable). In highly sensitive business environments, it's often preferable to start with Default Windows Mode in audit mode and add trust rules as real needs are identified.

WDAC on HoloLens 2 and package family names

HoloLens 2 uses WDAC in a way very similar to a traditional Windows 10.But with nuances. One of the key points is that many controls are based on the Package Family Name (PFN) of the installed UWP apps.

In HoloLens, WDAC is used, for example, to block the launch of specific applications keeping them visible in the interface. Unlike kiosk mode, where the UI hides prohibited apps, in WDAC you can still see their icons, but when you try to run them they simply won't launch.

App Lists and Package Family Names in HoloLens 2

In many corporate deployments, policies such as newPolicy.xml to add PFN-based rules for applications that exist only on HoloLens. Some typical examples of integrated apps are:

• 3D Viewer: Microsoft.Microsoft3DViewer_8wekyb3d8bbwe
• App Installer: Microsoft.DesktopAppInstaller_8wekyb3d8bbwe (blocking it only prevents the use of that app, not installations from the Store or MDM)
• Calendar and Mail: microsoft.windowscommunicationsapps_8wekyb3d8bbwe
• Camera: HoloCamera_cw5n1h2txyewy
• Cortana: Microsoft.549981C3F5F10_8wekyb3d8bbwe
• Dynamics 365 Guides: Microsoft.Dynamics365.Guides_8wekyb3d8bbwe
• Dynamics 365 Remote Assist: Microsoft.MicrosoftRemoteAssist_8wekyb3d8bbwe
• Feedback Hub: Microsoft.WindowsFeedbackHub_8wekyb3d8bbwe
• File Browser: c5e2524a-ea46-4f67-841f-6a9465d9d515_cw5n1h2txyewy
• Microsoft Store: Microsoft.WindowsStore_8wekyb3d8bbwe
• Photos: Microsoft.Windows.Photos_8wekyb3d8bbwe
• Configuration: HolographicSystemSettings_cw5n1h2txyewy
• Tips: Microsoft.HoloLensTips_8wekyb3d8bbwe

These strings are used within the WDAC policy To create rules for authorizing or denying UWP apps on HoloLens. In an Intune-managed environment, it's common to export these PFNs from a test device and then apply them across the board.

How to find the Package Family Name of an app

If an application is not listed in the reference lists, you can obtain its PFN by Windows Device Portal connected to a HoloLens 2 with the app installed:

1. Install the app in the HoloLens 2 test.
2. On the device, go to Settings > Updates and Security > For Developers tab and activate Developer mode y device portal.
3. Connect to the Device Portal from a browser on the same network and enter the section Views > Apps.
4. In the installed apps panel, choose the application from the dropdown menu.
5. Locate the field PackageRelativeID.
6. Copy everything that appears before the “!” characterThat portion is the Package Family Name that you will use in the WDAC policy.

Using PowerShell to locate packages and processes

PowerShell is the Swiss Army knife for preparing WDAC policiesespecially when you need to find UWP package names on a "normal" Windows 10 PC. A common pattern for locating apps is:

Example command: $package1 = Get-AppxPackage -name *<NombreApp>*

If you don't remember the exact package name, you can try with jokers until we find him. For example, to locate Microsoft Edge modern:

Command: Get-AppxPackage -name *edge*

The command can return several results, but among them you will see the full package name which you can then reuse in WDAC rules or audit scripts.

Specific application blocking: example with Microsoft Edge

Sometimes, the goal is not to define an entire whitelisting strategy, but block a specific executable that you consider problematicA typical example is the new Microsoft Edge in environments where the use of another corporate browser is to be enforced.

In those cases, and to avoid errors with untested applications, one can be added direct denial rule about binary, for example:

Example XML rule: <Deny FriendlyName="C:\Data\Programs FileRule" PackageVersion="65535.65535.65535.65535" FileName="msedge.exe" />

This instruction, embedded in the policy's XML, indicates that any file named msedge.exe Any permission that matches the context of that rule will be blocked, regardless of any other permissions that may be derived from other more generic rules.

Signing WDAC policies: when and why

Sign a WDAC policy This is the step that makes it "almost untouchable." Once a signed policy has been applied and is protected by Secure Boot, simply deleting the file from the disk is not enough to disable it. That's good for security, but dangerous if you don't have a very well-defined update and rollback procedure.

By signing, you ensure that:

• The policy cannot be modified without using an authorized certificate in the policy itself (UpdatePolicySigners).
• Only policy binaries that Windows can cryptographically validate are loaded.
• An attacker with local administrator privileges has a much harder time disabling WDAC.

In return, if a serious error occurs (for example, the signed policy of the EFI partition is deleted), you can end up with computers that do not boot until a valid policy is manually reinjectedThat's why there's so much emphasis on testing it in a laboratory first.

Prerequisites for signing

Previous requirements to sign WDAC policies:

• Equipment configured with UEFI and Secure Boot enabled.
• Un code signing certificate (acquired from a public CA or issued by your internal PKI).
• Define rules in policy that authorize that certificate to sign new versions of the policy.
• Tools like SignTool.exe and the WDAC cmdlets in PowerShell (ConvertFrom-CIPolicy, Add-SignerRule, etc.).

The typical workflow is: create the XML, adjust rules, add the signer in UpdatePolicySigner, remove the unsigned policy option, convert to binary, sign with SignTool and rename the result to {GUID}.cip using the PolicyId from the XML.

WDAC Deployment: GPO, Intune, Scripts and Tools

Deploying WDAC is almost as important as designing a good policy.The same policy can be managed in different ways depending on your management tools.

Group Policy Objects (GPO)

If you use classic Active Directory, the most direct way is a team GPO pointing to a policy file in a unique format:

• Directive route: Equipo > Plantillas administrativas > Sistema > Device Guard > Deploy Windows Defender Application Control.
• There you enable the option and specify the path to the policy file (it will be converted to SiPolicy.p7b automatically).
• After applying the GPO, a reboot is required so that politics can be activated.

The downside is that It only supports single policy formatFor architectures with multiple policies, you have to resort to specific scripts or tools.

Intune and the use of CSPs

In modern environments, the most common practice is to deploy WDAC via Intuneeither with Endpoint Protection profiles or through the CSP ApplicationControlThe most flexible option is the latter:

• A custom configuration policy is created with an OMA-URI like this:
  ./Vendor/MSFT/ApplicationControl/Policies//Policy
• The .bin/.cip file generated from the XML.
• It is recommended that the policy include the option “Update Policy without rebooting” (Option 16) to avoid forced restarts in future updates.

Intune's Endpoint Protection template also allows you to quickly enable WDAC by activating "Application Control Code Integrity policy" and, optionally, "Trust apps with good reputation." This configuration relies on the ISG, but it has two drawbacks: it forces a restart and often generates many unexpected crashes if not supplemented with additional rules.

Scripts, CiTool and other methods

When you don't have MDM or GPO available, or when you want to make highly customized deployments, You always have the scripts and specific tools:

• CiTool.exe (Windows 11 22H2+): Allows applying and removing WDAC policies by GUID from the command line commands.
• WMI: can be used to apply policies in a single format on older systems.
• Direct copies to the CodeIntegrity paths and the EFI partition: more manual method, usually wrapped in PowerShell scripts.

Monitoring, testing, and troubleshooting

Before forcing WDAC into lock mode, you must living in audit mode and oversee conflictive processes such as compattelrunner.exeThis is not a "soft" recommendation: deploying a strict policy without first observing what breaks can crash critical applications... or even prevent the machine from starting.

Check if WDAC is active

There are several ways to check the status of WDAC:

• MSINFO32In “System Information” there is a field called “Windows Defender Application Control status” indicating whether it is disabled, in audit mode or applied.
• CodeIntegrity Folder: in C:\Windows\System32\CodeIntegrity\ You can see if there is a SiPolicy.p7b (single policy) or files .cip with CiPolicies\Active.
• Event log: the log Microsoft-Windows-CodeIntegrity/Operational centralizes WDAC events.
• PowerShell: With
  Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | FL *codeintegrity*
  You can check, among other things, UserModeCodeIntegrityPolicyEnforcementStatus (value 2 = applied).

Key events in the event viewer

The CodeIntegrity log It's your best friend for knowing what's going on. The most important IDs are:

• 3076The file would have been blocked, but it has been allowed because the policy is in audit mode.
• 3077The file has been locked in application mode.
• 3089 and other codes: they report policy load, errors, etc.

Filter by 3076 When you're testing in an audit, it's a very efficient way to see what you would break if you switched to enforcement mode at that moment.

Tests with signed and internal executables

In many scenarios, it is desired that internal applications signed with a corporate CA are permitted by WDAC. The typical flow would be:

• Generate a code signing certificate internal (and keep it safe).
• Sign the executable with SignTool.exe or equivalent tools.
• In the WDAC Wizard, add a rule of type Publisher using that binary as a reference and selecting attributes such as Issuer and Publisher.
• If the wizard warns that it cannot obtain some attributes, it allows you to create a rule for hash as fallback.
• Generate the policy in audit mode, deploy it, verify in the log that the signed EXE is allowed and its unsigned version would be logged as a potential block.

Custom policy creation: baseline, scans and “golden image”

It's not always a good idea to start only from the Microsoft templatesIn environments with a lot of legacy or very specific software, it may be more practical to build a policy from a "golden image": a reference machine with all the corporate software installed.

A very common approach is

• Prepare a clean team with all the necessary apps already installed.
• Execute commands such as:
  New-CIPolicy -MultiplePolicy -FilePath C:\temp\wdacpolicybaseline.xml -ScanPath C: -Level FilePublisher -UserPEs -Fallback Hash
• Wait (it may take a while, depending on the volume of files).
• Open the resulting XML with the WDAC Wizard, review the options (make sure you have Audit Mode at the beginning and Update without reboot activated) and clean up duplicate or absurd rules.

These types of policies tend to be very large and somewhat "dirty"Therefore, in many cases it ends up being more practical to rely on official templates (Default Windows Mode, etc.) and add specific trust rules or partial scans of Program Files y Program Files (x86):

Commands: New-CIPolicy -FilePath .\ProgramFiles.xml -ScanPath $env:ProgramFiles -Level Publisher -UserPEs -Fallback Hash
New-CIPolicy -FilePath .\ProgramFiles86.xml -ScanPath ${env:ProgramFiles(x86)} -Level Publisher -UserPEs -Fallback Hash

Then you can merge XML (e.g., Microsoft baseline + locked driver rules + internal app rules) using the WDAC Wizard itself or specific cmdlets.

Combined use of Managed Installer, ISG, and AppLocker

WDAC He doesn't live on an islandIdeally, you should take advantage of integration with other Windows components to avoid becoming a slave to constant manual updates and to integrate strategies for Application Security Posture Management.

• Managed Installer (option 13)If you select this option and correctly define a "managed installer" (for example, the Intune Management Extension service accompanied by an associated AppLocker policy), WDAC will automatically allow what that installer deploys.
• Intelligent Security Graph (option 14)This allows WDAC to check file reputation. Anything the ISG considers "known and good" can be executed even without an explicit rule, reducing friction but also slightly lowering the security bar.
• AppLockerIt can be used in parallel to refine user behavior, blocking specific UWP apps such as Netflix o Spotify, or limit PowerShell to administrators.

It's important to note that while Microsoft's sample templates allow Store Apps by default, completely blocking the Microsoft Store or specific Store apps using pure WDAC can be tricky and easily compromised. In practice, AppLocker or specific Store policies are typically used for this type of fine-grained control.

Revert and delete WDAC policies

Removing poorly installed WDAC can be just as tricky as installing it. especially if the policies are signedMicrosoft's recommendation is always:

• First deploy a replacement policy (for example, based on AllowAll.xml) what activate the “Unsigned System Integrity Policy” option and put the mode in audit mode.
• Verify that the new policy has been correctly implemented before removing the original one.
• Remove the policy from the deployment mechanism (GPO, MDM, scripts) afterward, preventing it from being applied to the computers again.

To unsigned policies, from Windows 11 22H2 onwards it can be used CiTool.exe To uninstall by GUID, or manually delete the files:

• Multiple format:
  <EFI System Partition>\Microsoft\Boot\CiPolicies\Active\{PolicyId}.cip
<OS Volume>\Windows\System32\CodeIntegrity\CiPolicies\Active\{PolicyId}.cip
• Single format:
  <EFI System Partition>\Microsoft\Boot\SiPolicy.p7b
<OS Volume>\Windows\System32\CodeIntegrity\SiPolicy.p7b

In all cases, It is mandatory to restart so that the team stops applying the removed policy. In many environments, the policy is first "disabled" (allowing everything, audit mode) and then calmly removed.

WDAC is a very powerful tool To control what runs on Windows, from HoloLens to advanced workstations, it's a powerful tool, but it's also demanding: it requires a thorough understanding of the environment, audit testing, maintaining a policy lifecycle (signed or unsigned), and combining it with other components like AppLocker, ISG, or Managed Installer. If used judiciously, it drastically reduces the attack surface; if activated haphazardly, the one who rebels isn't the attacker. malware but your users… and your own IT team.