WDAC vs AppLocker Allowlist Rules: Hash, Publisher, Path

On Windows systems, allowlisting for CM.L2-3.4.8 is usually enforced with Microsoft's own tools. WDAC, now documented by Microsoft as App Control for Business, and AppLocker both let you define which executables, installers, scripts and libraries may run. The harder question is not which tool to use but which rule type to write for each approved application. This guide compares the rule types and explains when to use each. Check Microsoft's comparison of the two technologies for current status, because it changes between Windows releases.

WDAC and AppLocker in one paragraph

App Control for Business, also known as Windows Defender Application Control (WDAC), is the option Microsoft recommends when the goal is robust protection. Microsoft states that AppLocker continues to receive security fixes but not new feature improvements, and that it does not meet the servicing criteria for a security feature. Microsoft also describes AppLocker as a complement that can add user- or group-specific rules on top of App Control. Many environments run one or the other, and some combine them. Whichever you choose, the rule types below are conceptually the same, and the approval record for each application should state which one applies.

Rule types compared

Rule type	Matches on	Survives updates	Main risk
Hash	The exact file contents (a SHA-256 based hash)	No, every new build needs a new rule	High maintenance, but the most precise identity
Publisher	The code-signing certificate, often combined with product name, file name and version	Yes, within the signed product line	Trusts everything signed by that publisher unless narrowed
Path	The file location	Yes, as long as the location is unchanged	Unsafe if standard users can write to the location

WDAC offers finer rule levels than these three headings suggest, including levels that combine publisher with file name and version, and levels based on the certificate chain. The principle holds: the more specific the rule, the less it trusts, and the more maintenance it needs.

Choosing a rule type for each application

Signed enterprise software from an established publisher. Use a publisher rule narrowed to the product and, where practical, a minimum version. This survives routine updates and does not let unrelated software from the same publisher run. Avoid rules that trust the publisher's entire certificate for vendors with broad product lines.

Unsigned or rarely updated software. Use hash rules. An unsigned binary has no publisher to match, and a hash proves that the executable running is the one you reviewed. Expect to add a new rule with each version, which is a feature: every new build needs a review.

Software in protected locations. Path rules are reasonable for directories only administrators can modify, such as the system and program files locations. Microsoft notes that path rules do not give the same guarantees as signer rules because they depend on mutable access permissions, and App Control by default checks at runtime that the path is writable only by administrators. Do not use them for user-writable paths like downloads, temporary folders or user profiles.

Software that updates itself. Prefer publisher rules narrowed by product, and make sure the update mechanism is part of what you reviewed. A self-updating application can change behavior without a new approval, so set a review trigger on version changes.

Cover the whole execution surface

Installers, scripts and libraries matter as much as the main executable. AppLocker controls executable files, scripts, Windows Installer files, DLLs, packaged apps and packaged app installers, and by default its policy applies only to code launched in a user's context, so check whether processes running as SYSTEM need coverage in your environment. App Control also covers drivers, scripts and MSI installers. An allowlist that covers only the main executable leaves other routes open.

Audit mode is not enforcement

Both tools can run in an audit mode that logs what would be blocked without blocking it. Audit mode is the right way to build a policy and see the effect before turning it on. It does not satisfy the objective that the allowlisting be implemented as specified. Keep a record of the date you moved to enforcement and of any machines still in audit mode.

Link the rule to the approval

Each entry in your approved software list should say which rule type enforces it and carry the identifiers: the hash, or the publisher, product and minimum version. The observed behavior from a sandbox analysis tells you whether a narrow rule will break the application, for example when it drops helper executables that also need a rule. How the policy fits the broader requirement is covered in the CM.L2-3.4.8 guide.

Where DigVel fits

DigVel's reports record the hashes, signature chain, dropped files and observed behavior you need to write accurate rules, together with a recommendation for the approval decision. See what the report contains and the service. Your team writes and deploys the rules.