Application Control Under the Essential Eight: A Practical Guide

Of all eight mitigation strategies in the Australian Cyber Security Centre’s framework, application control is the one that delivers the most protection and provokes the most anxiety. When it is implemented well it stops the overwhelming majority of malware, ransomware loaders and living-off-the-land tooling from ever executing. When it is implemented carelessly it breaks legitimate software, frustrates users and gets rolled back. This guide is about getting it right.

Application control is one of eight strategies, and it works best alongside the others. For the wider context, see our Essential Eight explained guide. Here we focus specifically on what application control is, what each maturity level requires, and how to deploy it without disrupting the business.

What application control actually does

Application control is allowlisting. Instead of trying to recognise and block bad files, it permits only a defined set of approved code to run and blocks everything else by default. That inversion is what makes it so effective. Antivirus has to know a file is malicious to stop it; application control does not care whether a file is good or bad, only whether it is on the approved list. An attacker who drops a brand-new, never-seen-before tool onto a machine finds it simply will not run.

This is why the ACSC ranks application control so highly. It directly counters the most common attack pattern, which is getting unauthorised code to execute on an endpoint, whether that code arrives by email attachment, malicious download, removable media or lateral movement from another host.

What the Essential Eight requires at each maturity level

Application control scales with maturity, and the scope broadens at every step:

• Maturity Level One: Application control is implemented on workstations and prevents the execution of unapproved executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets in standard user profile folders and temporary folders. This targets the writable locations malware most often uses.
• Maturity Level Two: The same controls apply across workstations, and allowed and blocked execution events are centrally logged. The set of restricted file types is enforced more comprehensively, not just in user-writable folders.
• Maturity Level Three: Application control extends to internet-facing servers as well as workstations and applies across the whole filesystem. Microsoft’s recommended driver and application blocklist is implemented, allowlist rulesets are validated at least annually, and execution logging is centrally collected, protected and monitored.

If you are targeting a specific tier, our companion articles on Maturity Level Two and Maturity Level Three set out how application control fits alongside the other strategies at each level.

Choosing your tooling

On Windows, the two native options are Windows Defender Application Control and AppLocker. AppLocker is policy-based, relatively quick to deploy and manage through Group Policy or Intune, and well suited to organisations building their first allowlist. Windows Defender Application Control offers stronger, kernel-enforced protection and finer control over drivers and code integrity, but it is more demanding to configure and maintain. Many organisations use AppLocker as a stepping stone and migrate to WDAC as maturity increases. Third-party endpoint protection platforms also provide allowlisting, which can suit mixed environments.

The right choice depends on your management stack, the maturity level you are pursuing and how strictly you need to govern libraries, scripts and drivers. There is no single correct answer, but whatever you pick must be capable of meeting the logging and scope requirements of your target level.

Building the allowlist without breaking the business

The most common failure is switching application control straight into enforcement and discovering that a payroll tool, a CAD plugin or a finance team’s quarterly macro-driven workflow no longer runs. The disciplined approach avoids this entirely:

1. Inventory first. Understand what software is genuinely in use, including departmental tools that IT may not formally support.
2. Deploy in audit mode. Run the policy in monitoring mode so it logs what would have been blocked without actually blocking anything.
3. Run audit mode long enough. Capture a full business cycle, including monthly close, quarterly reporting and any seasonal processes, so rare-but-legitimate applications are not missed.
4. Build rules from publisher and path data. Prefer rules based on a trusted publisher’s digital signature over simple file paths, because path rules in user-writable locations can be bypassed.
5. Pilot before broad enforcement. Enforce on a small, representative group first and resolve issues before fleet-wide rollout.
6. Keep an exception process ready. A fast, governed way to add a legitimately needed application is essential, or users will route around the control or escalate constantly.

Allowlisting methods and which to trust

Not all allowlist rules are equally robust, and understanding the hierarchy is essential to building a policy that actually holds. The common methods, from strongest to weakest, are:

• Cryptographic hash rules identify a file by its exact contents. They are extremely precise but brittle, because every patch changes the hash and requires a new rule. They suit a small set of critical, rarely changing binaries.
• Publisher rules trust files signed by a particular software vendor’s certificate. These are the workhorse of a maintainable allowlist, because they survive version updates from a trusted publisher without constant rule changes.
• Path rules allow execution from a specific folder. They are the most convenient and the most dangerous, because if users can write to that path, an attacker can place a payload there and have it run. Path rules should only ever point at locations users cannot write to.

A well-built allowlist leans heavily on publisher rules, reserves hash rules for a handful of unsigned but essential applications, and uses path rules sparingly and only over protected directories. Getting this balance right is the difference between an allowlist that is both secure and sustainable and one that is either full of holes or impossible to maintain.

How application control supports the other strategies

Application control does not work in isolation, and its value compounds when paired with the rest of the Essential Eight. It backstops macro restrictions by blocking the executables a malicious macro tries to launch. It reinforces user application hardening by stopping unapproved interpreters and tools. And it limits the blast radius of a missed patch, because even if an attacker exploits an unpatched vulnerability, the tooling they try to run next may be blocked. Thinking of application control as one layer in a defence-in-depth stack, rather than a silver bullet, leads to better design decisions and more realistic expectations.

Common pitfalls to avoid

Several mistakes recur across deployments. Relying on path-based rules in folders that users can write to undermines the whole control, because an attacker can place a payload there. Forgetting to cover scripts means PowerShell and similar interpreters become an open door, which is exactly the living-off-the-land technique modern attackers favour. Allowing entire directories rather than specific signed publishers makes the allowlist far too permissive. And neglecting maintenance means the ruleset gradually accumulates broad exceptions until it protects very little.

Logging is another frequently missed requirement. At Maturity Level Two and above, blocked and allowed execution events must be captured and, at ML3, centrally collected and monitored. An allowlist that silently blocks things without producing reviewable evidence will not satisfy an assessment and leaves you blind to attempted execution of unapproved code.

Maintaining application control over time

Application control is not a project that finishes; it is a control that lives. New software versions need new rules. Retired applications should be removed from the allowlist. Annual validation, required at ML3, is good practice at any level because it catches the broad temporary exceptions that always creep in. Treat every loosening of the policy as a risk decision with an owner and a review date, and the allowlist will keep its protective value.

Application control is genuinely the strongest single control in the Essential Eight, but it rewards careful planning and steady maintenance. If you want help scoping a rollout, choosing between AppLocker and WDAC, or designing an exception and logging process that will pass assessment, CISO Advisory can guide the programme through our virtual CISO service. Call 07 2112 8502 or get in touch via our contact page.