Application Allowlisting vs Blocklisting: Choosing Default Deny or Known Bad on Endpoints

Every endpoint runs on one of two execution models, whether anyone chose it or not: everything runs unless it is known to be bad, or nothing runs unless it is known to be approved. Blocklisting (deny by exception) is the model most estates inherit from antivirus and hash indicators. Application allowlisting (allow by exception, or default deny) is the model ransomware guidance and the Australian Essential Eight keep pushing organisations towards. This guide is a decision page for endpoint, security architecture and SOC leads: what each model actually stops, what it costs to run, why living-off-the-land binaries force you to use both, how Essential Eight application control is staged, and how to move from audit to enforcement without breaking the business. It covers endpoint application control only. For allow and deny lists in input validation, network filtering and email, see the Allowlist vs Denylist guide, and for building policies rule by rule, the Application Allowlisting Guide.

Key takeaways

• The short answer is default deny where software is stable, known bad everywhere. A blocklist is a cheap, always-on safety net; an allowlist is the control that stops code nobody has seen before, which is what most initial payloads are.
• They are not mirror images. NIST SP 800-53 separates them as CM-7(4) deny by exception and CM-7(5) allow by exception, and the two fail in opposite directions: a blocklist fails open on anything new, an allowlist fails closed on anything forgotten.
• Maintenance cost moves, it does not disappear. Blocklisting puts the work on threat intelligence and indicator hygiene; allowlisting puts it on software packaging, change control and exception handling. Budget the hours before picking a model.
• LOLBins make every allowlist a hybrid. Trusted, signed system binaries can run attacker code, so a strong allowlist always carries a blocklist inside it, such as Microsoft's recommended block rules.
• Audit mode is how you buy the switch. Run the allowlist in audit for a fixed period, build rules from the events, enforce in rings and keep the blocklist enforcing throughout so protection never drops during the change.

The two models in plain terms

NIST SP 800-167, the Guide to Application Whitelisting, describes an allowlist as the set of software an organisation permits, enforced by technology that controls which programs may run on a host so that malware, unlicensed and other unauthorised software cannot. A blocklist inverts the question: it names files, publishers or certificates that may not run and allows everything else.

• Blocklisting (known bad, deny by exception): antivirus signatures, file hash indicators, certificate indicators and named-binary deny rules. Microsoft Defender for Endpoint file indicators, for example, accept SHA-256, SHA-1 or MD5 hashes with the actions Allow, Audit and block, or Block and remediate, and on Windows apply to portable executables (.exe and .dll) only. Microsoft states blocks are typically enforced within 15 minutes and can take up to two hours.
• Allowlisting (default deny, allow by exception): a policy that names what may run, by hash, signer, publisher and version, or protected path, and blocks everything else. Microsoft describes App Control for Business as changing Windows from running all code unless antivirus predicts it is bad to running only code the policy allows, covering scripts, MSI files and interactive PowerShell, which runs in Constrained Language Mode.

MITRE D3FEND models the two as separate countermeasures, D3-EAL Executable Allowlisting and D3-EDL Executable Denylisting, which is a useful reminder that they answer different questions rather than being two settings of one control.

Side-by-side comparison

Threat model: what each model stops

• User-run payloads: a user opening a dropped file (ATT&CK T1204.002 Malicious File) is the textbook allowlisting win. An unsigned executable in a downloads folder never starts, whatever its reputation. A blocklist only stops it if someone has already seen and named that exact file or family.
• Repacked and custom code: recompiling or padding a file changes its hash, so hash blocklists are blind to it. Default deny does not care whether the file is new; unapproved is enough.
• Signed system binaries: proxy execution through trusted binaries (T1218 System Binary Proxy Execution, including T1218.005 Mshta and T1127.001 MSBuild) defeats a naive allowlist that trusts all of Windows. Here a targeted blocklist is the fix, which is why the two models meet in practice.
• Script interpreters: PowerShell (T1059.001) and similar hosts run code that never touches disk as an executable. Allowlisting helps only where the interpreter is "enlightened" to enforce policy, as PowerShell is with Constrained Language Mode; blocklists rarely help at all.
• Stolen or abused signing: code signed with a stolen or fraudulently obtained certificate (T1553.002 Code Signing) passes publisher-level allow rules. Certificate indicators on the blocklist side, and narrower FilePublisher rules on the allow side, close the gap from both ends.

CISA's #StopRansomware Guide puts the conclusion plainly: use allowlisting rather than attempting to list and deny every possible permutation of applications, and run allowlisting and/or EDR on all assets.

Architecture in words

Blocklisting

A blocklist lives in the antimalware engine or EDR agent. Indicators are pushed from a central console or API, cached on the endpoint and checked at file access or process creation. The weak points are latency (minutes to hours to propagate), coverage (Windows file indicators cover PE files, not scripts) and lifecycle, because indicators are rarely expired and lists grow until they slow evaluation or collide with legitimate files.

Allowlisting

An allowlist is a policy evaluated by the operating system or an agent before code loads. On Windows, App Control for Business enforces code integrity policies in user and kernel mode; on Linux, tools such as fapolicyd check against the package database and a trust file (see the fapolicyd and Linux Application Allowlisting Guide). The weak points are rule breadth (a publisher rule trusts every tool that publisher signs), user-writable paths, and the people process that must approve new software quickly enough that users do not route around it.

How the two combine

Mature estates run both in one evaluation chain. Microsoft documents the order for Defender for Endpoint: anything not allowed by App Control or AppLocker in enforce mode is blocked first, then antivirus exclusions, then block file indicators, SmartScreen, allow file indicators and finally attack surface reduction and antivirus detections. Two consequences follow. An allow indicator cannot rescue a file the allowlist blocks, and an over-broad antivirus exclusion can let a blocklisted file through, so exclusions deserve the same review as allow rules.

Maintenance cost: where the hours go

Both models cost people time; the difference is when and who.

• Rule level is the biggest lever: hash rules break on every update; FilePublisher rules survive updates for a named file; broader publisher rules cost almost nothing but trust the vendor's whole catalogue. The Application Allowlisting Guide covers each rule level in depth.
• Exception turnaround is the hidden cost: if approving new software takes days, users and admins look for bypasses or lobby to stay in audit mode. A same-day request path is worth more than a perfect rule set.

LOLBins: where the models meet

The LOLBAS project catalogues legitimate, Microsoft-signed binaries, scripts and libraries that can be misused, mapped to ATT&CK and grouped by function, including execute, download, compile and an explicit "AWL bypass" category for files that defeat application allowlisting. GTFOBins and LOLDrivers do the same for Unix binaries and drivers. See the Living off the Land Guide and, for Apple estates, macOS LOOBins.

An allowlist that trusts everything signed by the operating system vendor also trusts these. That is why Microsoft publishes recommended block rules for App Control: a deny list of binaries and DLLs that can bypass an allow policy, including mshta.exe, wscript.exe, cscript.exe, msbuild.exe, wmic.exe, InstallUtil.exe, dotnet.exe, wsl.exe and debuggers such as windbg.exe and cdb.exe. Points that matter when you adopt it:

• It ships safe to deploy alone: the published policy contains "allow all" rules for kernel and user mode and the audit mode option, so it can run as a standalone blocklist on devices that are not yet allowlisted.
• Remove the allow-all rules before merging: Microsoft warns that when merging into a base policy with an explicit allowlist, the two allow-all rules and their references must be removed first, or the merge quietly allows everything.
• Business exceptions are explicit: msbuild.exe is needed on build systems, for example. Grant the exception through a supplemental policy for that device group, not by deleting the deny rule estate-wide.
• It changes over time: Microsoft updates the list as new bypasses are found and advises adding deny rules for older vulnerable versions when an application is patched. Assign an owner to check for updates on a schedule.

The practical model is an allowlist with an embedded blocklist; where you cannot yet enforce an allowlist, a blocklist plus recommended block rules is the interim state.

Essential Eight application control by maturity level

The Australian Signals Directorate's Essential Eight treats application control as default deny and stages it by maturity level. The table follows Microsoft's published mapping of the requirements to the Information Security Manual (ISM) March 2025 controls. Confirm the current wording against ASD before an assessment. See the Essential Eight Guide for the wider framework.

Two details are decisive for the model choice. Microsoft notes that reputation-based trust (App Control's Intelligent Security Graph option) does not satisfy ISM-1657 or ISM-1582, so a "signed and reputable" policy cannot carry an organisation past Maturity Level One. And Maturity Level Two explicitly requires the recommended blocklist inside the allowlist, which is the hybrid model described above written into a framework. Microsoft also notes path rules are acceptable for ISM-1657 only where file system permissions prevent unauthorised changes.

Decision criteria

• Small organisations: start with the blocklist you already have, add the recommended block rules, remove local admin rights, and allowlist servers and admin workstations first. These carry the most risk and the least software diversity.
• Large organisations: invest in a base policy plus supplemental policies per business unit, policy as code in version control, and a request process linked to the service desk. Allowlisting at scale is a software supply process, not a security project.

Pairing allowlisting with detection is a separate decision covered in Application Allowlisting vs EDR; for product selection see the Application Control and Endpoint Prevention Buyer's Guide.

Moving from known bad to default deny

1. Keep the blocklist enforcing. Do not relax antivirus or indicators during the change; they are your protection while the allowlist is in audit.
2. Deploy the recommended block rules first. As a standalone policy in audit, then enforce once events show no business use. This delivers LOLBin coverage before any allowlist exists.
3. Inventory and assign owners. List software per endpoint class with publisher, business purpose and who installs it (CIS Controls safeguard 2.1, NIST CSF 2.0 ID.AM-02).
4. Remove standing local admin on the pilot ring. Administrators, and malware running as one, can tamper with unsigned policies and installer trust.
5. Run the allowlist in audit for a fixed period. Cover month-end and quarterly jobs, then stop. On Windows collect App Control audit events (3076 for executables, 8028 for scripts) centrally.
6. Build rules from events and review them. Prefer FilePublisher with hash fallback; reject rules that trust user-writable paths or whole publishers you do not need.
7. Enforce in rings. IT first, then a small percentage of users, then business units, keeping the next ring in audit so you see what will break before it does.
8. Keep a tested rollback. An audit-mode policy ready to replace the enforced one, and a documented way to deploy it when devices cannot reach management. Sign policies only once they are stable.

Worked scenario: one estate, two models

A 3,000-seat organisation runs EDR with antivirus and around 400 custom hash indicators accumulated from past incidents, half of them older than two years. A phishing payload recompiled for the campaign ran on a finance laptop because no indicator matched it. The review reached these decisions:

• Blocklist hygiene: indicators older than 12 months without a match were expired after confirming no active campaign used them; new indicators get a review date.
• Interim LOLBin coverage: the recommended block rules went to every Windows device in audit for three weeks, exposing msbuild.exe on 40 developer machines and wmic.exe in two legacy scripts. Developers received a supplemental exception; the scripts were rewritten; the policy was enforced estate-wide.
• Default deny where it pays: 180 servers and 60 admin workstations moved to enforced allowlists within a quarter. Finance and HR desktops, which run a small fixed application set, followed under managed installer trust.
• Developers stayed hybrid: blocklist plus an allowlist covering user profile and temporary paths, scripts and drivers, matching the Essential Eight Maturity Level One locations without blocking compilers in project folders.

Where identity fits

Both models assume the person or process on the device cannot simply change the rules. Local administrators can disable antivirus, add exclusions or replace unsigned allowlist policies, so remove standing local admin rights before or with enforcement. Service accounts used by deployment tools deserve particular care: an account that can push software through the managed installer can, in effect, write allow rules. Treat it as privileged. See the Privileged Access Management Guide.

Detection and measurement

• Collect both models' events in one pipeline: allowlist blocks and audits, indicator hits and antivirus detections, so analysts see when a blocklist miss was caught by the allowlist, or the reverse (NIST CSF 2.0 DE.CM-09).
• Alert on policy tampering: policy removal, switches back to audit mode, new antivirus exclusions and new broad allow rules.

Framework mapping

Common failure patterns

• Calling a blocklist application control: a list of banned tools is reported as "application control in place", and auditors or insurers take it at face value. Name the model in every report.
• Allowlist that trusts all of Windows and nothing else: the LOLBins stay open. Merge the recommended block rules, and remove their allow-all rules before merging.
• Audit mode for ever: the policy logs blocks that never happen, and coverage dashboards count it as deployed. Put an end date on every audit ring.
• Exclusions that undo both models: wide antivirus exclusions on folders or processes let blocklisted files run, and in the documented evaluation order they are checked before block indicators.
• Reputation mistaken for approval: a reputation-based allowlist runs on servers that should have a strict organisational policy, and it cannot meet Essential Eight Maturity Level Two.

Practitioner checklist

• Record, per endpoint class, which execution model is enforced, and report blocklists and allowlists separately.
• Deploy Microsoft's recommended block rules everywhere, standalone where no allowlist exists yet, and assign an owner to track list updates.
• Enforce default deny on servers, admin workstations, kiosks and OT first.
• Remove standing local admin rights before or with enforcement, and treat deployment service accounts as privileged.
• Run audit mode for a fixed period per ring, build rules from events, and keep a tested rollback policy.
• Give every custom indicator an owner and review date, and expire stale ones.
• Centrally log allowed and blocked events, protect the logs, and validate rulesets at least annually.

Standards and references

• NIST: SP 800-167 Guide to Application Whitelisting
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• CISA: #StopRansomware Guide
• Microsoft: Essential Eight application control
• Microsoft: Applications that can bypass App Control and how to block them
• Microsoft: Application Control for Windows
• Microsoft: Create indicators for files
• LOLBAS Project: Living Off The Land Binaries, Scripts and Libraries

Related NHI Mgmt Group resources: Application Allowlisting Guide · Application Allowlisting vs EDR · Allowlist vs Denylist · App Control for Business (WDAC) · Application Control and Endpoint Prevention Buyer's Guide