Nano Solutions

Application control

Application control is a security control that permits only an organisation-approved set of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to execute. Under the Essential Eight Maturity Model it is one of eight baseline mitigation strategies, mapped to ISM control ISM-1657.

Last checked against cyber.gov.au on . Current model: Essential Eight Maturity Model (November 2023).

On this page 5 sections
  1. What ASD requires
  2. What application control is not
  3. Why ASD rates application control highly
  4. How assessors verify application control
  5. If you build software

Application control at a glance

What each maturity level requires

Requirements are cumulative: Level Three means everything in Levels One and Two as well. Each level links to that requirement on the matrix.

  1. ML1 Maturity Level One

    Application control, Maturity Level One: Implemented on workstations (ISM-0843)
  2. ML2 Maturity Level Two

    Application control, Maturity Level Two: Implemented on internet-facing servers
  3. ML3 Maturity Level Three

    Application control, Maturity Level Three: Implemented on non-internet-facing servers
New requirements start here Carries the level below Score yourself with the self-assessment, or look a term up in the glossary.

Application control prevents unapproved executables, libraries, scripts and other covered file types from running. ASD describes it as one of the most effective ways to prevent malicious code from executing.

What ASD requires

At Maturity Level One, application control runs on workstations. It restricts execution to an organisation-approved set in user profiles and temporary folders used by the operating system, web browsers and email clients. Those locations are where downloaded and email-delivered files commonly arrive.

At Maturity Level Two, coverage extends to internet-facing servers and to all other locations. Microsoft's recommended application blocklist is applied, and rulesets are validated at least annually. Both allowed and blocked execution events are centrally logged; the logs are protected, and internet-facing server logs are analysed.

Level Two also requires identified incidents to be reported to the chief information security officer (CISO) and ASD, and the incident response plan to be enacted.

At Maturity Level Three, coverage reaches non-internet-facing servers, extends to drivers, adds Microsoft's vulnerable driver blocklist, and expands log analysis to non-internet-facing servers and workstations.

See the requirements matrix for every control at each maturity level.

Level Two requires logging of allowed executions as well as blocked ones. Recording blocked executions alone does not satisfy the requirement.

What application control is not

ASD spells out what does not count. From Implementing application control, the following do not constitute application control:

  • providing a portal or other means of installation for approved applications
  • using web or email content filtering to prevent users from downloading applications from the internet
  • checking the reputation of an application using a cloud-based service before it is executed
  • using a next-generation firewall to identify whether network traffic is generated by an approved application

Each can reduce exposure, but none restricts execution to an organisation-approved set. The strategy is about execution, not acquisition.

Why ASD rates application control highly

Application control is the first of the 37 strategies in ASD's 2017 Strategies to Mitigate Cyber Security Incidents. It carries the highest "essential" rating for preventing malware delivery and execution. When the rules cover the required locations and file types, the control blocks payloads outside the approved set regardless of how they arrived.

ASD's Commonwealth Cyber Security Posture in 2025 puts application control at 48% of Commonwealth entities reaching Maturity Level Two or above in 2024–25. The result was 36% in 2023–24, after the November 2023 update moved the recommended application blocklist and annual ruleset review into Level Two.

How assessors verify application control

ASD publishes an Application Control Verification Tool (ACVT) alongside the Essential Eight Maturity Verification Tool. Both are available through the ASD Partner Portal. ASD recommends tool-based assessment, stating that interviews, reports and screenshots are inferior to scripts and tools for verifying controls.

There is no ASD-approved application control product. The Essential Eight maturity model FAQ answers the question directly: "Does ASD provide a list of approved products for implementing the Essential Eight? No. Organisations should determine the suitability of particular products based on their own requirements."

If you build software

Application control governs what runs in a managed environment. It says nothing about the software an organisation develops. Development controls live elsewhere in the Information Security Manual (ISM); see what the Essential Eight means if you build software.

It does, however, shape how your software gets deployed into a client's environment. Unsigned executables and runtime scripts may need explicit hash or secured-path rules, while signed releases can use publisher rules. Packaging and update behaviour are therefore worth discussing before installation day.

Sources

All ASD source documents →

Common questions

Is application control the same as application whitelisting?

It is the same core idea under a name ASD no longer uses for this strategy. Older documents called it application whitelisting; the current maturity model calls it application control. Where a guide uses the older name, check which model version its requirements come from.

Does antivirus or a next-generation firewall satisfy application control?

No. A portal for approved installations and web or email filtering do not restrict execution. Neither do cloud-based reputation checks or a next-generation firewall identifying traffic by application. These measures may complement application control, but they do not satisfy it.

Which file types have to be covered?

ASD's list covers executables (.exe, .com), software libraries (.dll, .ocx), scripts (.ps1, .bat, .cmd, .vbs, .js) and installers (.msi, .msp, .mst). It also covers compiled HTML (.chm), HTML applications (.hta) and control panel applets (.cpl). Drivers are added at Maturity Level Three.

Do we need application control on servers?

Not at Maturity Level One, which covers workstations only. Internet-facing servers come in at Level Two, and non-internet-facing servers at Level Three.

  • Essential Eight requirements matrix

    What each Essential Eight strategy requires at Maturity Levels One, Two and Three: timeframes, scanning intervals and controls introduced at higher levels. Sourced line by line from the November 2023 maturity model.

  • Restrict administrative privileges

    This strategy limits who receives privileged access, what privileged accounts can reach, how administrators use them, and when access expires.

  • User application hardening

    ASD's user application hardening covers browsers, Office, PDF readers and PowerShell. It does not describe how to harden software an organisation develops.

Essential Eight

Need this assessed rather than explained?

We assess your maturity across all eight strategies, show you where you actually stand, and do the remediation. We are not an ASD-endorsed assessor — nobody is, because no such endorsement exists.