Application Control

Application control — also called allowlisting — inverts the default trust model of most endpoints. Instead of allowing everything to run except what a signature or heuristic flags as bad (the traditional antivirus model), application control denies everything by default and only permits code that has been explicitly approved. It is one of the highest-value controls against malware, ransomware, and living-off-the-land techniques, because it stops unapproved code from ever executing rather than trying to detect it once it has.

This article covers application control as a platform-agnostic discipline: the trust models, what needs to be controlled beyond just .exe files, a deployment methodology, common bypass techniques, and alignment with the ACSC Essential Eight and NIST SP 800-53. For the Windows-specific implementation detail (WDAC and AppLocker configuration), see Windows Workstation Hardening. Application control is a preventive complement to, not a replacement for, the detective and response capabilities covered in Endpoint Detection and Response (EDR) — a determined attacker who finds a gap in the allowlist still needs to be caught by behavioural detection.

Default-Deny vs Default-Allow

Model	Approach	Failure Mode
Default-allow (traditional AV)	Everything runs unless it matches a known-bad signature or heuristic	Fails against anything novel — zero-days, custom malware, or legitimate tools repurposed maliciously (living-off-the-land)
Default-deny (application control)	Nothing runs unless it matches an approved rule	Fails toward availability, not security — an unapproved but legitimate program is blocked, which is a support ticket, not a breach

This asymmetry is the entire case for application control: a default-deny failure is an inconvenience; a default-allow failure is a compromise. The tradeoff is operational overhead — every legitimate piece of software an organisation runs has to be identified, approved, and kept current in the rule set. This is what makes application control disproportionately effective on tightly-scoped populations (servers running a fixed set of known applications) and harder, though still worthwhile, on general-purpose workstations with a long tail of user-installed software.

Trust Models (Rule Types)

Every application control implementation, regardless of platform, builds its allow rules from some combination of these mechanisms:

Rule Type	How It Works	Strength	Weakness
Hash-based	Allow a specific file by its cryptographic hash (SHA-256)	Strongest per-file guarantee — cannot be spoofed	Breaks on every update; unmanageable at scale without automation
Publisher / code-signing certificate	Allow anything signed by a specific, trusted certificate	Survives version updates; scales well	Trusts the entire publisher — a compromised vendor build pipeline or leaked signing key is trusted implicitly
Path-based	Allow anything located in a specific directory (e.g. `Program Files`, `/usr/bin`)	Simple to configure	Weakest model — any location a standard user can write to (including many "trusted" paths misconfigured with weak ACLs) becomes a bypass
Attribute / metadata-based	Allow based on product name, internal name, or version metadata embedded in the file	Flexible for managing families of related binaries	Metadata is trivially editable and must never be trusted without a signature backing it
Reputation-based	Cloud reputation/prevalence scoring — allow files seen widely and long enough to be considered safe	Low administrative overhead	Non-deterministic; a targeted or low-prevalence attack tool won't yet have an established reputation either way, and the decision depends on a third party's telemetry
Managed installer / provenance-based	Trust anything installed by an approved software deployment tool (e.g. a patch/software management system), rather than the binary itself	Practical for enterprise-managed software rollout at scale	Only as strong as the deployment tool's own access controls — compromise of the deployment pipeline grants broad execution trust

Practical guidance: default to hash or publisher rules for anything security-sensitive; treat path-based rules as the weakest acceptable option and only where the directory's write permissions are verified as administrator-only; use reputation and managed-installer mechanisms to reduce administrative burden for low-risk, high-volume software categories, not for anything privileged.

What Must Be Controlled

Application control is frequently under-scoped to "block unapproved .exe files." Effective coverage extends to every category of code that can execute on the system:

Category	Examples	Why It's Often Missed
Executables	`.exe`, ELF binaries, Mach-O binaries	The obvious case, usually covered first
Software libraries	DLLs, shared objects (`.so`), dynamic libraries (`.dylib`)	Executable-only rules are bypassed via DLL sideloading/hijacking — a trusted, signed executable loads an attacker-planted malicious library
Scripts	PowerShell, Bash, Python, VBScript, JScript	Script interpreters (e.g. `powershell.exe`, `python.exe`) are themselves signed and trusted, so unsigned malicious scripts they execute are missed unless script content itself is enforced
Installers	MSI, PKG, DEB, RPM	Installers can execute arbitrary embedded logic during install, outside the normal execution rule set
Browser extensions / email client add-ins	Malicious or compromised extensions	Extensions execute with the privileges of the browser/mail client and are rarely covered by endpoint-level application control
Legacy dual-use file formats	Compiled HTML Help (`.chm`), HTML Applications (`.hta`), Control Panel applets (`.cpl`)	Long-standing living-off-the-land vectors that are frequently forgotten because they aren't traditional executables
Drivers / kernel modules	`.sys` drivers, kernel extensions	Highest privilege, highest impact — a malicious or vulnerable driver executes at kernel level, below most other endpoint controls

Scoping to executables only and ignoring libraries, scripts, and drivers leaves the most commonly abused bypass paths wide open.

Deployment Methodology

Application control is not a switch to flip — a premature enforce-mode rollout on an unbaselined fleet generates enough business disruption that it gets rolled back, often permanently. Deploy in phases:

1. Inventory and Discovery

Before writing any rules, establish what software is actually running across the target population. Pull from software deployment tooling, endpoint telemetry, and a manual audit of business-critical applications. This baseline determines the initial rule set and surfaces unmanaged/shadow software early, while it's still cheap to address.

2. Audit / Log-Only Mode

Run in a non-blocking, log-only mode for a period (commonly 2–4 weeks, longer for populations with infrequent business cycles such as month-end finance processes). Every execution that would have been blocked is logged, not stopped. Review the logs to:

Identify legitimate software missing from the initial rule set
Identify unexpected or unauthorised software that needs a business decision (approve, replace, or remove)
Tune out rules that are too broad or too narrow before they affect production

3. Staged Enforcement

Move to enforcing (blocking) mode on a small pilot ring first — a team that can tolerate and quickly report friction, not a production-critical group. Expand in rings (pilot → early adopters → general population → high-sensitivity/critical systems last, once the rule set is proven). Define the exception-request process (see below) before wide rollout, not after the first blocked legitimate use case generates a fire drill.

4. Full Enforcement and Ongoing Maintenance

Application control is not "set and forget." Every software update, every new business application, and every patch cycle can introduce binaries, libraries, or scripts that don't match the existing rule set. Establish a recurring process to:

Onboard new approved software into the rule set as part of the standard software request/approval workflow
Re-baseline periodically to catch drift
Review and retire rules for software that has been decommissioned (a stale allow rule is unnecessary attack surface)

Platform Implementation Reference

The concepts above apply across platforms; the enforcement mechanism differs:

Platform	Native Mechanism	Notes
Windows	Windows Defender Application Control (WDAC), AppLocker	WDAC operates at the kernel level and cannot be bypassed by a local administrator; AppLocker is a user-mode legacy alternative. See Windows Workstation Hardening for configuration detail
macOS	Gatekeeper, code signing and notarization enforcement, MDM-managed allowed-team-identifier policies	Built around Apple's code-signing and notarization pipeline rather than a locally authored rule set
Linux	`fapolicyd`, SELinux type enforcement, AppArmor profiles, integrity measurement (IMA/EVM)	Typically requires more manual policy authoring than the commercial-OS equivalents; SELinux/AppArmor provide mandatory access control alongside execution control
Cross-platform / EPP-EDR-integrated	Unified application control modules bundled into endpoint protection platforms	Convenient for a single policy model across a mixed fleet, but confirm the underlying rule types (hash/publisher/path) actually match the guidance above rather than trusting the vendor's default posture

Handling Exceptions

Every application control deployment accumulates exception requests — a business-critical tool that doesn't fit the standard rule set, a vendor tool that only ships unsigned, a legacy application nobody wants to re-certify. Handle exceptions deliberately:

Require a documented business justification and an accountable owner for every exception — not just the requester, but someone who will be asked to re-justify it at review time.
Scope exceptions as narrowly as possible. A hash rule for one specific file is a far smaller risk than a path or publisher exception that trusts an entire directory or vendor.
Time-box exceptions with a mandatory review/recertification date rather than granting them permanently.
Track exceptions centrally so the security team has a live view of every deviation from the default-deny baseline, not a set of one-off changes scattered across individual device configurations.
Periodically recertify — software that needed an exception two years ago may have since shipped a signed release, been replaced, or been decommissioned entirely.

Common Bypass Techniques and Mitigations

Understanding how application control is bypassed sets realistic expectations for what it achieves on its own:

Bypass Technique	Description	Mitigation
Living-off-the-land binaries (LOLBins)	Abusing signed, trusted system binaries (e.g. script hosts, registration utilities, certificate tools) to execute malicious logic indirectly	Explicitly deny known dual-use binaries that have no legitimate business use case, even though they are signed and would otherwise be trusted
DLL sideloading / hijacking	Placing a malicious library where a trusted, signed executable will load it	Extend rules to cover libraries, not just executables (see "What Must Be Controlled" above)
Script interpreter abuse	Running unsigned malicious script content through a trusted, signed interpreter	Enforce script-level controls (constrained execution modes, script signing requirements) in addition to interpreter-level trust
Weak path-rule bypass	Writing a malicious binary into a directory trusted by an overly broad path rule	Verify that any path-trusted directory is writable only by administrators; prefer hash/publisher rules for anything sensitive
Renaming / masquerading	Renaming a blocked binary to evade filename- or path-based detection	Hash and publisher rules are immune to renaming; filename-only rules are not — avoid relying on filename alone
Bring-your-own-vulnerable-driver (BYOVD)	Loading a legitimately signed but vulnerable driver to gain kernel-level code execution, bypassing the intent of the allow rule	Maintain and enforce a vulnerable/blocklisted driver list alongside the driver allowlist — a driver being signed and "approved" historically doesn't mean it's safe today

Implication: application control substantially raises the cost and skill required for an attacker to execute arbitrary code, but a sophisticated adversary who studies the specific rule set can often find a gap. Pair it with the behavioural detection covered in Endpoint Detection and Response (EDR) to catch what the allowlist alone doesn't.

Alignment with the ACSC Essential Eight

Application control is one of the eight mitigation strategies in the ACSC Essential Eight, and its maturity levels scale both the scope of systems covered and the categories of code restricted:

Requirement	ML1	ML2	ML3
Applied to workstations	✓	✓	✓
Applied to internet-facing servers		✓	✓
Applied to internal (non-internet-facing) servers			✓
Restricts executables, libraries, scripts, installers, compiled HTML, HTML applications, and Control Panel applets to an organisation-approved set	✓	✓	✓
Applied to user profiles and temp folders used by the OS, browsers, and email clients	✓	✓	✓
Restricts drivers to an organisation-approved set			✓
A vulnerable/blocklisted driver list is enforced			✓
Allowed and blocked application control events centrally logged		✓	✓
Event logs analysed in a timely manner (workstations / internet-facing servers / internal servers)		partial	✓

Practical implication: an organisation that has application control on workstations only, covering executables but not scripts or libraries, has not met even ML1 in substance — the ML1 requirement already covers the full category list (executables, libraries, scripts, installers, compiled HTML/HTML apps, Control Panel applets), including user profile and temp-folder paths specifically because they're the most common malware drop location. Reaching ML3 additionally requires extending coverage to every server (not just internet-facing ones) and bringing drivers under the same default-deny model — directly relevant to BYOVD attacks.

Alignment with NIST SP 800-53

Application control maps most directly to CM-7(5) — Least Functionality: Authorized Software / Allow-by-Exception, which requires organisations to:

Identify the software programs authorised to execute on the system
Employ a deny-all, permit-by-exception policy for execution — the same default-deny model this article is built around
Review and update the authorised software list at an organisation-defined frequency

NIST's guidance explicitly notes that comprehensive coverage extends beyond top-level applications to application modules, scripts, system processes, system services, kernel functions, registries, drivers, and dynamic link libraries — the same expanded scope covered in "What Must Be Controlled" above — and recommends verifying the integrity of allowlisted software via cryptographic checksums, digital signatures, or hash functions, either before execution or at system startup.

Supporting controls: CM-8 (System Component Inventory — the discovery/baseline step depends on an accurate inventory) and SI-7 (Software, Firmware, and Information Integrity — verifying that allowlisted software hasn't been tampered with).

Hardening Checklist

Control	Priority	Notes
Default-deny application control deployed on all workstations	Critical	The baseline Essential Eight ML1 / NIST CM-7(5) requirement
Coverage extends to libraries, scripts, installers, and legacy dual-use formats — not executables only	Critical	The most common source of under-scoped, bypassable deployments
Hash or publisher rules preferred over path-based rules for sensitive software	High	Path rules are the weakest trust model and depend entirely on directory ACLs
User profile and temp-folder paths explicitly covered	Critical	The most common malware drop and execution location
Driver execution restricted to an approved set, with a vulnerable-driver blocklist enforced	High	Directly mitigates BYOVD kernel-level attacks; required for Essential Eight ML3
Deployment phased: inventory → audit/log-only → staged enforcement → full enforcement	High	Prevents a premature enforce-mode rollout from being rolled back
Exception requests require documented justification, an accountable owner, and a review date	High	Prevents exceptions from silently accumulating as permanent, unscoped trust
Exceptions scoped as narrowly as possible (hash over path/publisher where feasible)	High	Limits the blast radius of any single exception
Allowed and blocked execution events centrally logged	High	Required for Essential Eight ML2+; feeds detection of both attacks and misconfigured rules
Known LOLBins and dual-use signed binaries explicitly denied where no legitimate use exists	Medium	Signed and trusted does not mean safe to leave unrestricted
Rule set reviewed and re-baselined on a recurring cadence, aligned to patch/software release cycles	Medium	Application control decays as software updates outpace the rule set
Application control paired with EDR behavioural detection, not deployed as a sole control	Medium	Mitigates the residual risk from bypass techniques a rule set alone won't catch