Application control with default deny means a computer runs only the software you have approved, and refuses everything else. Instead of trying to recognize every piece of malware, you describe the small set of programs the business needs, and the operating system blocks the rest. A downloaded installer, a renamed executable in a temp folder, a tool an employee found online, an unsigned script: none of them start. This article explains how application control works on Windows, where most rollouts go wrong, what a good policy looks like, and how to get there without stopping people from doing their jobs.
Why application control beats a blocklist
Antivirus is a blocklist. It keeps a long list of known-bad files and checks each file against it. The list is always behind, because attackers only need to change a file enough that it no longer matches. Many ransomware incidents that started with "the user ran an attachment" are cases where a blocklist lost.
Application control is the opposite. It keeps a short list of known-good software and blocks everything else. A new strain of malware was never approved, so it does not run. Neither does the remote access tool an attacker drops after phishing. The question is no longer "is this file bad?" but "did we say this file may run?".
This is why the Australian Signals Directorate's Essential Eight lists application control as the first of its eight controls: https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/essential-eight. Microsoft's documentation for Windows Defender Application Control (WDAC) is at https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/.
The catch: default deny is easy to describe and hard to run. If the allowlist is wrong, work stops. That is why many organizations that try it stay in audit mode forever, logging what would have been blocked and never blocking anything.
What Windows gives you: WDAC and AppLocker
Windows has two built-in mechanisms.
AppLocker is the older one. It is a Group Policy feature that rules on executables, scripts, installers and packaged apps by publisher, path or hash. It is easier to set up, but it was never designed as a security boundary. Microsoft now points new deployments at WDAC.
Windows Defender Application Control, now also called App Control for Business, enforces at the kernel level. A WDAC policy is an XML document compiled to a binary and loaded at boot. It can allow or deny by signer certificate, file hash, file path and file attributes such as original filename and version. It also covers drivers, which AppLocker does not.
A WDAC policy has two modes:
| Mode | What happens when an unapproved file runs | Use it for |
|---|---|---|
| Audit | The file runs. Event 3076 is written to the Code Integrity log. | Learning what the estate actually runs |
| Enforced | The file is blocked. Event 3077 is written. | Production |
Both modes write events, so the audit log is the source of truth for whether your policy is complete. If you cannot read those events from every machine in one place, you cannot run enforced mode with confidence.
The rule types and which to prefer
The order of preference below follows Microsoft's guidance.
- Publisher (signer) rules. Allow anything signed by this certificate, optionally restricted to a product name or a minimum version. One rule covers every update of that product. This is the rule you want for Microsoft, your line-of-business vendors and your own code-signing certificate.
- File attribute rules. Match on the original filename, product name or internal name from the version resource, with a minimum version. Useful for signed binaries from a vendor whose certificate changes too often, or when a publisher rule would be too broad.
- Hash rules. Match the exact SHA-256 of the file. Precise and fragile. Every update of the file breaks the rule. Use hashes only for unsigned, rarely changing tools, and plan to revisit them.
- Path rules. Allow anything under a folder. Only safe if standard users cannot write to that folder.
C:\Program Filesqualifies.C:\Users\...\AppDatadoes not, and WDAC will refuse to honor path rules on user-writable locations for that reason.
A good policy is mostly signer rules with a short tail of attribute and hash rules. Hundreds of hash rules will not survive the next patch Tuesday.
Where rollouts go wrong
The failure modes are repetitive.
Audit mode without a reader. The policy is deployed in audit mode, nobody collects the 3076 events, and six months later nobody knows whether the policy is ready. Collect the events centrally from day one.
Rules written against the wrong name. A deny rule is written against the filename on disk. The user renames the file and it runs. Signer and original-filename rules do not have this problem.
Supplemental policies nobody tracks. WDAC supports a base policy plus supplemental policies. The set on each machine drifts, and a laptop that missed one update behaves differently from its neighbor. Whatever manages the policy must tell you which version each endpoint is actually enforcing.
The schema rejects the rule and nobody notices. A policy XML that does not validate against the WDAC schema is silently ignored. Everything appears deployed. Nothing is enforced. Validate before you push, and read the state back from the endpoint.
No path for exceptions. A user needs a tool today and the only route is a ticket and a policy change. After the third time, someone turns the policy off "temporarily". A fast, audited exception path is what keeps enforced mode enforced.
Local admin undoes everything. If users are local administrators, they can disable or replace the policy. Application control and the removal of standing admin rights go together. See just-in-time admin rights for how to give people elevation when they need it without leaving it on.
What a good deployment looks like
Start from Microsoft's published base templates rather than a blank file. The "Allow Microsoft" template permits Windows and anything Microsoft-signed; the "Default Windows" template is tighter. Add your own signer rules on top.
Group the estate. Developers, finance and the warehouse scanners do not run the same software, and one policy for all of them will be too loose or too tight. Build a base policy for everyone and a supplemental policy per group, and let membership follow a rule (department, OU, hostname pattern) so a new laptop lands in the right policy without a ticket.
Run audit for a bounded period, then review the events. Every 3076 is software you forgot, software you want to forbid, or noise from an installer writing to a temp folder. Decide each one. When a week of audit produces no new unknowns in a group, move that group to enforced.
Roll out enforced mode in rings. The same canary, pilot, everyone pattern used for patch management works here. If the canary ring cannot print on Monday morning, you have found a missed rule before the whole company has.
Keep a reversal ready: a policy version you can roll back from the console in minutes, per group, without touching each machine.
Treat the policy as code. Version it, review changes, and keep a record of who added which rule and why.
Checklist: before you flip to enforced
- Code Integrity events (3076 and 3077) are collected from every endpoint into one place you can search.
- The policy validates against the WDAC schema and the endpoint reports the policy version it is actually running.
- Most rules are signer or file-attribute rules; hash rules are listed with an owner and a review date.
- No path rules point at folders standard users can write to.
- Every line-of-business application has been launched, updated and uninstalled under audit without an event.
- Each group (base plus supplemental) has run clean in audit for a defined period.
- Standing local admin has been removed, or is on the way out, for the groups going enforced.
- There is a documented exception path with a target response time, and exceptions are time-boxed and logged.
- The rollout runs in rings with a tested rollback per ring.
- Someone owns the policy, and the owner is named in the change record.
How Tracemark does it
Tracemark's Endpoint Control product manages Windows Defender Application Control from the console, as one of nine products delivered by the single Tracemark agent on every endpoint.
The policy is default deny: anything not covered by an allow rule does not run. The WDAC rules are managed in the console and delivered to endpoints by the agent. Endpoints are grouped by rule, using dynamic endpoint groups, so a policy for finance follows finance machines.
Application control sits next to the other endpoint controls in the same console. Device Control denies USB storage by default and trusts drives by serial number. Users who need something outside policy can raise an access request that an admin approves from the console for a limited time, for example one hour, after which it expires on its own. When an application needs administrator rights, Tracemark can run that one named application elevated without granting the user local admin, which removes one common reason for handing out admin rights in the first place. Browser policies for Chrome and Edge are managed from the same place.
The agent works offline: policies are cached on the device, so a laptop on a plane enforces the same rules as in the office, and events are queued until it reconnects. Agent updates are signed and rolled out in rings with rollback.
Every change an admin makes to a policy is recorded in the admin trail (who, what, when), and role-based access means only the roles that manage endpoint policy see those screens. For the wider context of how application control fits with data protection on the same agent, see what is data loss prevention and security hardening baselines and drift enforcement.
Frequently asked questions
Does application control replace antivirus?
No. It removes a whole class of problems (unknown executables running) but does not inspect what approved programs do. Keep endpoint protection for the behavior of allowed software, and use application control so that unapproved software never gets the chance to run at all.
Will users be able to install anything?
Not from their own downloads. Software arrives through your deployment path, which is covered by signer rules, or through a time-limited, approved exception. The exception path is what makes this workable.
What about scripts and macros?
WDAC applies constrained language mode to PowerShell when a script is not allowed by policy, and it controls which script hosts and DLLs can load. Office macros are a separate control (Office trust settings and attack surface reduction rules), so plan them alongside, not as part of, the WDAC policy.
How long does a rollout take?
It depends on how many distinct applications the estate runs and how clean your software inventory is. A group with a known, deployed set of software can move from audit to enforced in weeks. A group where everyone installs their own tools takes longer.
Try it
Try Tracemark free for three months. Claim it at tracemark.ca