Introduction
Of the eight mitigation strategies in the Australian Signals Directorate's (ASD) Essential Eight, application control is consistently one of the hardest for organisations to mature. It requires detailed knowledge of what software runs across the environment, a defensible allow-listing approach, and ongoing maintenance as applications, drivers and updates change. Many organisations report Maturity Level One on paper but cannot evidence it under audit. For Australian IT and security leaders planning Essential Eight uplift, understanding why application control stalls, and how to sequence a realistic path forward, is essential to setting an achievable target and business case.
Why Application Control Is Different From the Other Seven
Most Essential Eight controls, such as patching or multi-factor authentication, can be rolled out with a defined technical configuration and a clear go-live date. Application control is different because it is not a single control but an ongoing discipline. Every legitimate application, script, installer and driver that an organisation relies on must be identified and explicitly permitted, and every change to that inventory (a vendor update, a new line-of-business tool, a script used by an admin) has to be assessed and incorporated without breaking business operations.
This creates two distinct organisational risks. First, if application control is deployed too aggressively without adequate discovery and testing, it can block legitimate business activity, generating help desk load and pressure to weaken the policy or grant broad exceptions that erode the control's value. Second, if it is deployed too loosely, or scoped only to a subset of the estate, it leaves execution paths open that attackers actively use, including living-off-the-land techniques where legitimate system binaries are repurposed to run malicious code. Both outcomes are common in organisations that treat application control as a one-off project rather than an ongoing capability with an owner, a change process and a review cycle.
What Maturity Uplift Actually Requires
ASD's Essential Eight maturity model sets out escalating expectations for application control as organisations move from Maturity Level One toward Maturity Level Three, broadly moving from restricting execution on workstations, to extending coverage across servers and additional locations, to tightening the rule set further and addressing higher-risk execution paths such as vulnerable drivers. Organisations should treat the ASD's published maturity model as the authoritative reference for the exact requirements at each level, since the specific scope and rule expectations are periodically refined and should not be assumed from memory or from a prior audit.
A practical uplift program typically works through the following sequence:
- Discovery before enforcement. Run application control in audit or "allow with logging" mode first, across representative device groups, to build an accurate inventory of what actually executes before committing to an enforced policy.
- Segment by risk and function. Standard user workstations, privileged workstations and servers carry different risk profiles and should be scoped and tested separately rather than as one policy.
- Use a managed rule authority where possible. Rather than building and maintaining a fully custom rule set from scratch, organisations using Microsoft endpoint management can build on Microsoft's supported application control mechanisms for Windows, which provide a structured way to define trusted publishers, managed installers and rule refinement over time, reducing the maintenance burden compared with a fully bespoke allow-list.
- Establish a change process, not just an initial policy. New software and updates need an intake and approval path into the rule set, owned by a named team, so the control does not decay or attract informal exceptions.
- Extend beyond executables. Mature application control should also address scripts, installers, DLLs and drivers, not only .exe files, since these are common execution paths for malicious activity.
Common Failure Modes and Evidence of Success
The most common failure mode is scope creep in exceptions: broad "allow all for this group" rules introduced to resolve a business complaint, left in place indefinitely, and never reviewed. A second common failure is treating audit mode as the end state; audit logging demonstrates visibility, not enforcement, and does not meet maturity expectations on its own. A third is inconsistent coverage, where workstations are controlled but servers, contractor devices or high-privilege administrative endpoints are excluded.
Useful evidence of a maturing capability includes a documented and current application inventory, a named process and owner for rule changes, a record of exceptions with justification and expiry dates, and reporting that shows enforcement coverage across the full estate rather than a subset. Boards and audit committees should expect this evidence, not just a statement that "application control is in place."
Key Takeaway
Application control fails to mature not because the technology is unavailable, but because organisations underestimate the ongoing discovery, testing and change management it requires. Treat it as a managed capability with a named owner, a documented exception process and staged rollout by device risk profile, rather than a single deployment project. The most useful next step for most organisations is to run a discovery/audit-mode pass across a representative sample of the estate to establish an accurate baseline before committing to an enforced policy, and to check current scope and rule expectations directly against ASD's published Essential Eight Maturity Model.