Ask anyone running an Essential Eight programme which strategy is holding them back, and the answer is application control. It is two bullet points at Maturity Level One and routinely the longest single workstream in the plan.
The reason is not technical difficulty. Every modern Windows estate ships with a capable enforcement mechanism. The difficulty is that application control requires you to know what your organisation actually runs — and almost no organisation does.
What the requirement actually says
At Maturity Level One, application control must be implemented on workstations and must restrict execution to an organisation-approved set covering executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets.
Two things in that list catch people out:
- Software libraries. Controlling .exe files while DLLs load freely does not meet the requirement, and DLL rules are where performance and breakage problems concentrate.
- Scripts. PowerShell, batch and script hosts are in scope. This is often the single biggest source of business disruption, because scripts accumulate quietly in every organisation.
Level Two extends enforcement to internet-facing servers, adds Microsoft's recommended application blocklist, annual ruleset validation and central logging. Level Three extends to all servers, adds drivers and the vulnerable driver blocklist, and requires logs protected from modification.
Why discovery is the project
The approved set is not a list you write. It is a list you discover, and the discovery reveals things nobody expected: a finance macro that shells out to an unsigned utility, a vendor support tool that runs from a user profile directory, an engineering team using portable executables from a network share.
Plan for discovery to take longer than deployment. Organisations that budget three months for tooling and two weeks for discovery have it precisely backwards.
Track application control alongside the other seven
GRC Copilot ships all four Essential Eight maturity levels as assessments, so application control progress sits next to the strategies it is blocking.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
A sequence that works
- Turn on audit mode everywhere first. Enforce nothing. Collect what executes across a full business cycle — including month-end, quarter-end and any annual process. A four-week sample will miss the payroll run that only matters in July.
- Build rules from publisher and path, not hash. Hash rules are precise and unmaintainable; every patch invalidates them. Publisher rules survive updates. Reserve hashes for the handful of unsigned binaries you cannot eliminate.
- Attack the user-writable directories. The core of the requirement is that users cannot execute code from locations they can write to. Getting this right closes most of the risk even before the ruleset is complete.
- Pilot on IT first, then a friendly business unit. IT will break things in ways they can diagnose. Finance will not.
- Enforce in waves, with a fast exception path. The programme fails politically, not technically. If a blocked user waits three days for a decision, you will be told to turn it off.
- Then add the blocklist and validation. Microsoft's recommended blocklist and annual ruleset review are Level Two items; adding them before you have stable enforcement is out of order.
The traps
- Allowing a whole directory that users can write to. This satisfies a scanner and defeats the control entirely. Assessors check for it specifically.
- Leaving scripts out of scope because they caused too much noise in audit mode. The requirement names them.
- Treating "the product is licensed and installed" as implementation. The requirement is that unapproved code cannot execute, which is a state of the environment, not a purchase.
- Forgetting servers at Level Two. Internet-facing servers enter scope at Level Two and every server at Level Three; teams that scoped only workstations discover this late.
What to keep as evidence
Policy exports showing the ruleset, evidence that enforcement rather than audit mode is active, coverage figures against your asset inventory, the exception register with approvals and expiry dates, and — from Level Two — central logs of allowed and blocked executions. Coverage matters: an assessor will ask what proportion of workstations are enforcing, and "most" is not an answer.
Frequently asked questions
Do we need a commercial application control product?
No. The requirement is about outcome, and native platform capabilities can meet it when configured and enforced properly. Commercial tools mainly buy easier rule management and reporting, which matters more at scale than at small estates.
How long does application control take to implement?
For a typical mid-sized estate, plan in quarters rather than weeks. Audit-mode collection across a full business cycle, rule construction, piloting and staged enforcement is realistically a six to twelve month programme unless the environment is unusually uniform.
Can we exclude developers?
Excluding a population from a control means that population is not covered, and coverage is what gets assessed. Developers usually need a differentiated ruleset rather than an exemption — dedicated build environments, tighter monitoring, and their toolchain explicitly approved.
Does application control replace antivirus?
No, and the Essential Eight does not present it that way. Application control stops unapproved code executing; antivirus and endpoint detection deal with approved code behaving badly and with threats that never touch the filesystem.
Key takeaways
- Software libraries and scripts are in scope, not just executables.
- Discovery takes longer than deployment; run audit mode across a full business cycle.
- Publisher and path rules survive patching; hash rules do not.
- Allowing a user-writable directory defeats the control and assessors look for it.