What Is Application Allowlisting and Why Is It the ASD's Hardest Control?

The Australian Signals Directorate's Essential Eight lists application allowlisting as the first mitigation strategy, and there is a reason for that ordering. Of all the controls in the framework, none does more to stop the execution of malicious code than preventing unauthorised applications from running in the first place. If a piece of malware cannot execute, it cannot do anything else.

And yet, application allowlisting is consistently the control that organisations implement last, or not at all. Most organisations at Maturity Level 2 across the Essential Eight have still not properly addressed allowlisting. This article explains what the control actually involves and why implementation is harder than it looks.

What Application Allowlisting Does

Allowlisting is a default-deny model for software execution. Instead of trying to identify and block malicious software, you define a list of trusted executables, scripts, and libraries, and block everything else. Only applications on the approved list can run. An attacker who gets access to a machine and tries to execute a tool they brought with them will find it blocked, because that tool is not on the approved list.

The control extends beyond executables. Effective allowlisting covers scripts, macros, installer packages, drivers, and browser plugins. It also controls which users or groups can install or run specific applications. This breadth is what makes it powerful and what makes it operationally intensive. Getting a list of every approved application is one thing. Keeping that list accurate as software changes, updates, and is added over time is a continuous operational commitment.

Why Maturity Level 3 Is Genuinely Difficult

The ASD's Essential Eight Maturity Model specifies that at Maturity Level 3, allowlisting must be applied across all workstations, servers, and network devices, must cover all application types including scripts and installers, and must be actively maintained. Exceptions must go through a formal approval process. Unauthorised execution attempts must be logged and reviewed.

Each of those requirements sounds straightforward until you try to implement them across a real environment. Organisations typically have hundreds of applications in use across workstations, including tools installed years ago by users who have since left. Legacy software may have no support path for updating when new versions are released. Shadow IT, departmental tools, and vendor-supplied utilities all need to be catalogued before they can be approved. Discovery alone is a significant project, and that is before the policy and governance work begins.

Where Implementations Break Down

The most common failure mode is incomplete discovery. Organisations build an initial allowlist from what IT knows about, deploy the control, and immediately generate exceptions because applications they did not know existed cannot run. If exception handling is slow or frustrating, users find workarounds. If exception handling is too permissive, the allowlist becomes meaningless over time as approvals pile up without review.

The second common failure is not covering scripts. Many organisations implement executable allowlisting but leave scripting engines open. PowerShell, Windows Script Host, and macro execution in productivity applications are all vectors that bypass executable allowlisting if not addressed separately. Threat actors know this and specifically target interpreted languages and macros when binary execution is blocked. Partial allowlisting creates a false sense of coverage that is arguably worse than no allowlisting at all.

How to Approach Implementation Without Disrupting Operations

A phased approach reduces operational risk. Start with audit mode, where the control logs what would be blocked without actually blocking it. This gives you a realistic picture of the software estate before enforcement begins. Use the audit period to work through the application catalogue, seek approvals, and establish a sustainable exception process. Move to enforcement in stages, starting with lower-risk user populations and expanding as confidence in the allowlist grows.

Ongoing maintenance needs to be owned explicitly. Allowlisting degrades without active management. Someone needs to review exception requests, approve updates as software versions change, and remove applications that are no longer in use. This is not a set-and-forget control. It is a programme that requires governance, tooling to support the exception workflow, and periodic review of the allowlist against actual application usage.

To discuss application allowlisting implementation for your organisation, contact Cyberlinx at info@cyberlinx.com.au.