What Is Application Whitelisting (Allowlisting)?

Antivirus asks "is this file known to be bad?" and blocks it if the answer is yes. Application whitelisting asks the opposite question: "is this file on my approved list?" and blocks it if the answer is no. That inversion is the whole idea. Instead of chasing an infinite list of bad things, you define a finite list of good things and refuse everything else.

The payoff lands exactly where signature defenses leak. A brand-new malware sample with a hash no scanner has ever seen still has to execute to do damage, and on a whitelisted host it cannot, because it is not on the list. The same logic stops an attacker living off the land with a renamed binary, a dropped script, or an unsigned tool. This guide is for the people who build and run that control: blue team engineers hardening a fleet, SOC analysts who own the alerts it generates, and DFIR responders who trace an intrusion back to the one execution that should never have been allowed.

It covers what application whitelisting is and why the industry now calls it allowlisting, the default-deny model, the methods used to identify trusted code, the Windows tools that enforce it (AppLocker and App Control for Business), what NIST SP 800-167 recommends, the deployment challenges that sink most rollouts, and how it neutralizes malware and living-off-the-land techniques.

What is application whitelisting?

Application whitelisting is a security control that allows only explicitly approved applications, scripts, and executables to run on a system and blocks everything else by default. It is the inverse of the antivirus model. Antivirus maintains a blocklist of known-bad code and permits everything not on it. A whitelist maintains a list of known-good code and denies everything not on it.

That single design choice changes the threat math. A blocklist can only stop what it already knows about, so every novel sample, every repacked payload, every freshly compiled tool gets a free first run. A whitelist does not care whether the code is known-bad, novel, or never seen before. If it is not approved, it does not execute. The defender no longer has to enumerate every possible threat, only the much smaller, knowable set of software the business actually needs.

This is a preventive control, not a detective one. It does not watch for malicious behavior and alert on it the way endpoint detection and response does. It stops the unapproved code from running at all, before any behavior happens. That makes it one of the strongest controls on the prevention side of the stack, and a natural complement to detection rather than a replacement for it.

The cost is the mirror image of the benefit. A blocklist is easy to run and weak by design. A whitelist is strong by design and hard to run, because someone has to define, approve, and maintain the list of everything allowed to execute across a changing fleet. Most of this guide is about managing that cost.

Whitelisting, allowlisting, and the terminology shift

The control has not changed, but its name has. The industry is moving from "whitelisting" and "blacklisting" to allowlisting and blocklisting. The newer terms are also clearer: "allowlist" and "blocklist" say what the list does, while "whitelist" and "blacklist" carry no inherent meaning and rely on a good-versus-bad color association.

Major bodies have made the switch. The UK National Cyber Security Centre moved to allow list and deny list in 2020. NIST adopted allowlist and denylist as preferred terms. Vendors including Microsoft and CrowdStrike now use allowlisting in their current documentation. The older terms are still widely understood and still appear in product names, certification syllabi, and search queries, which is why this article uses both: "application whitelisting" is what most people still search for, and "application allowlisting" is what the same control is increasingly called.

For the rest of this guide the two terms are interchangeable. The mechanism, default-deny on a list of approved code, is identical regardless of which label you use.

The default-deny model

Default-deny is the principle underneath the whole control: anything not explicitly permitted is forbidden. It is the opposite of the default-allow posture most systems ship with, where anything not explicitly blocked is permitted.

The distinction is not academic. It decides who has to be exhaustive. Under default-allow, the defender has to anticipate and block every bad thing, and any gap is an opening. Under default-deny, the attacker has to get their code onto an approved list, and any gap closes against them. Default-deny shifts the burden of completeness from the defender, who can never enumerate all threats, to the attacker, who now has to defeat the approval mechanism itself.

Default-deny is also the execution-control expression of zero trust: nothing is trusted by default, and trust has to be established explicitly before anything runs. Applied to application execution, that means a binary earns the right to run by being on the list, not by appearing harmless.

The failure mode is the catch. A default-deny control that is too aggressive or poorly maintained blocks legitimate software a user needs, which is why every serious deployment runs in an audit-first mode before it enforces. More on that below.

How application whitelisting identifies trusted code

A whitelist has to answer one question for every execution: is this the approved thing, or something pretending to be it? The answer depends on which attribute the rule keys on. NIST SP 800-167, *Guide to Application Whitelisting*, lays out the common attributes, and they trade off strictness against maintenance in a predictable way.

A few practitioner notes on the trade-offs:

• Hash rules are the strictest and the most brittle. A hash binds the rule to one exact binary, so nothing else can impersonate it. But every patch changes the hash, so a pure hash policy demands an update for every software update across the fleet. It is right for code that rarely changes, painful for code that updates weekly.
• Publisher rules are the practical default. Keying on the code-signing certificate lets a vendor ship updates without breaking the policy, because the new version is still signed by the same publisher. The risk is that you now trust everything that publisher signs, including any signed tool an attacker can abuse. Scope publisher rules to specific products where you can.
• Path rules are cheap and weak on their own. Allowing a directory is low-effort, but if a user or attacker can write an executable into an allowed path, it runs. NIST is explicit that filename and file size are unreliable and should only be used in combination with stronger attributes.
• Real policies combine attributes. The workable pattern is publisher rules for the bulk of trusted vendors, hash or path rules for the exceptions, and tight write permissions so allowed paths cannot be hijacked. NIST SP 800-167 recommends combining attributes rather than relying on any single one.

The choice is not abstract. It determines how often the policy breaks under normal IT operations, which is the single biggest reason whitelisting projects stall.

Application whitelisting tools on Windows

On Windows, two native technologies enforce application control, and their relationship is the part practitioners get wrong most often. Microsoft documents both and is explicit about which to prefer.

AppLocker was introduced with Windows 7. It controls which apps and files users can run, with rules based on publisher (code-signing certificate), file attributes (original filename, version, hash), and path. AppLocker rules can apply to specific users and groups, which makes it useful on shared machines. Microsoft's current position is that AppLocker does not meet its servicing criteria for a security feature, and while it continues to receive security fixes, it is not getting new feature investment. Treat AppLocker as stable and supported, but legacy.

App Control for Business is the successor, and the name itself is a fact-check trap. It was originally Windows Defender Application Control (WDAC), and before that part of Device Guard under the name configurable code integrity. Microsoft renamed it to App Control for Business, and that is the current name as of 2026. It was introduced with Windows 10, applies to the whole device including administrators, and can govern what runs in the kernel, not just user-mode apps. Its rules can key on the signing certificate, signed file metadata such as original filename and version, the file hash, the file path (from Windows 10 version 1903 onward), an app's reputation via Microsoft's Intelligent Security Graph, and the identity of a managed installer.

Microsoft's recommendation is direct: customers who can implement application control with App Control for Business should do so, because it is under continual development and applies to all users including administrators, whereas AppLocker by default targets standard users. AppLocker still has a place in mixed-OS environments and for per-user rules on shared devices, and Microsoft suggests using App Control at the most restrictive level you can, then layering AppLocker for user-specific fine-tuning.

Outside Windows, application control is enforced differently: Linux shops lean on tools like SELinux, AppArmor, or fapolicyd, and macOS uses Gatekeeper and signed-code policies. The principle is the same everywhere; only the enforcement engine changes.

What NIST SP 800-167 recommends

NIST published *Guide to Application Whitelisting* as Special Publication 800-167 in October 2015, authored by Adam Sedgewick, Murugiah Souppaya, and Karen Scarfone. It is the standing reference for planning and running an allowlisting program, and its guidance has held up despite its age because the model has not changed.

Three points from it carry the most operational weight:

• Match the method to the environment. SP 800-167 walks through the attributes above and is clear that no single one is sufficient. Filename and size are unreliable on their own; path is broad but weak; hash is precise but high-maintenance; publisher balances strength against update friction. The guidance is to combine attributes deliberately based on what you are protecting.
• Run it through a deployment lifecycle, not a flip of a switch. NIST frames whitelisting as a lifecycle: plan and initiate, design, implement and test, operate and maintain, and eventually retire. The test phase is where most of the risk lives, because that is where you discover the legitimate software your policy would have blocked.
• Audit before you enforce. The guide stresses testing in a monitor-only mode that logs what would be blocked without actually blocking it, so you can build the policy against real usage before it can break anything. This maps directly to AppLocker's audit-only mode and App Control's audit mode.

The takeaway from NIST is not a product recommendation. It is a discipline: pick attributes intentionally, build the policy from observed reality, and never enforce a list you have not first watched in audit mode.

Deployment challenges

Application whitelisting fails in practice far more often from operational friction than from a technical gap. The control works; running it is the hard part.

• Building the initial list is the heavy lift. You have to inventory every legitimate application, script, and executable across the fleet, which on a real estate means thousands of binaries across departments, contractors, and one-off tools nobody documented. Audit mode is how you do this honestly: watch what actually runs for weeks, then build the list from evidence rather than from a hopeful guess.
• Updates and patching break rules constantly. Hash-based rules break on every update by definition. Even publisher rules can break when a vendor changes its signing certificate. Without a managed-installer mechanism or an update process tied into the policy, routine patching turns into a stream of false blocks.
• Enforcing too early floods the help desk. Flip a half-built policy to enforce and you block the payroll macro on a Friday and the developer's compiler on Monday. This is the single most common way a hardening project gets rolled back. Audit first, add exceptions for the legitimate software it trips, then enforce.
• Maintenance never ends. New software, new versions, new contractors, and shadow IT all change the legitimate set continuously. A whitelist is a living policy, not a one-time project, and it decays the moment maintenance stops.
• Scope and user friction. Lock down developer or power-user machines too hard and you block legitimate work; leave writable allowed paths and you open a hole. The balance is per-environment, which is why NIST pushes designing for the specific systems you are protecting.

None of these is a reason to skip the control. They are the reasons to deploy it the way NIST and Microsoft both describe: inventory, audit, exception, enforce, maintain. Skipping the audit step is what turns a strong control into an outage.

How application whitelisting stops malware and LOLBins

The reason allowlisting earns its operational cost is what it does to two attack classes that signature defenses struggle with.

Novel and fileless malware. A blocklist needs to have seen a sample, or something like it, to stop it. A zero-day dropper, a freshly packed malware build, or a custom tool compiled for one target all sail past a scanner that has no signature for them. On a whitelisted host none of that matters. An unapproved executable does not run regardless of how novel it is, so the attacker's "never seen before" advantage evaporates. This is also why allowlisting is one of the few controls effective against fileless and script-based payloads when paired with script enforcement, because the script interpreter itself only runs approved code.

Living off the land (LOLBins). Sophisticated intrusions increasingly avoid dropping custom malware at all. They abuse legitimate, signed system binaries already present on Windows, the so-called living-off-the-land binaries: powershell.exe, certutil.exe, mshta.exe, regsvr32.exe, rundll32.exe, and dozens more catalogued in the LOLBAS project. A behavior-blind blocklist cannot stop these because every one of them is a trusted Microsoft binary doing something it is technically allowed to do.

Application whitelisting attacks this from a different angle. By constraining which scripts and binaries are allowed to execute, and through App Control's ability to govern the script host and constrained-language mode, an allowlisting policy can stop a LOLBin chain even though every program in it is signed and legitimate. It does not need to recognize the attack. It only needs the unapproved script or the unexpected execution path to fall outside the list.

That is the same coverage gap that drives attack surface reduction programs to put application allowlisting near the top of their control list. It removes an entire category of "trusted binary, untrusted use" that detection alone has to chase after the fact.

Allowlisting does not replace EDR or monitoring. An attacker who compromises an already-approved application, or finds a writable allowed path, still gets through, and that is where detection earns its place. The two are layers: allowlisting shrinks what can execute, and detection watches what executes anyway.

The bottom line

Application whitelisting flips the default. Instead of blocking known-bad code and hoping the list is complete, it permits only known-good code and refuses everything else. That default-deny posture is what lets it stop novel malware a scanner has never seen and break living-off-the-land chains built entirely from signed, legitimate binaries.

The model is well documented. NIST SP 800-167 lays out the attributes and the deployment lifecycle, and on Windows the choice is App Control for Business as the primary control, formerly WDAC, with AppLocker for per-user rules and mixed-OS fleets. The hard part is never the technology; it is the discipline. Inventory what runs, watch it in audit mode, add exceptions for the legitimate software the policy trips, then enforce, and keep maintaining the list as the environment changes. Run it that way and allowlisting is one of the strongest preventive controls available. Skip the audit step and it becomes an outage with a security label.