Two pages, two years
The ASD Essential Eight Maturity Model PDF for application control is about two pages.
The implementation is about two years.
ML3 looks deceptively simple on paper:
- block executables, libraries, scripts, installers, and drivers
- apply rulesets validated annually or more frequently
- use Microsoft's recommended block rules
- log events centrally
Four bullets. How hard could it be.
Where the two years actually go
When you decompose a typical ML3 program, the timeline is dominated by a small number of activities:
- Discovery. Working out what actually runs across the estate, on which OS versions, signed by which publishers, in which business workflows. In environments that have never been allowlisted, this is the longest single line item.
- Policy authoring. Translating that discovery into WDAC rules. Hash rules, publisher rules, file path rules, signing scenarios, supplemental policies for specific workloads. Done by hand, this is slow and error-prone.
- Audit-mode operation. Running the policy in audit on a meaningful subset of devices, collecting events, refining the policy, and doing it again. Most programs cycle through this phase several times.
- Exception management. Capturing the requests that come in once enforcement starts to bite, deciding which become permanent policy and which are time-bounded, and tracking what happens to each one.
- Enforcement transition. Moving from audit to enforced one ring at a time, with the operational room to pull back if something breaks.
- Annual validation. Reviewing every active policy, confirming what is still needed, removing what is not, and producing the artefacts an auditor will ask for.
Each of these is necessary work. Most of the calendar time is not spent on the work itself. It is spent on the manual effort, the waiting, and the rework that comes from doing each step in isolation from the others.
The compression is in the operating model, not the technology
The technology to do ML3 application control is built into Windows. WDAC ships with the operating system. There is nothing to procure, nothing to license, nothing to install. The Microsoft-recommended block rules are public. The schema is public. The deployment paths through Intune are public.
If the technology was the bottleneck, the average ML3 program would not take two years.
What takes two years is the absence of an operating model around the technology. Specifically:
- there is no canonical place where "the things this organisation is allowed to run" lives, separate from the XML
- discovery, authoring, deployment, and exception handling are run as separate manual workstreams instead of one connected flow
- a vendor certificate change requires hunting through every policy that referenced it
- audit events sit in a SIEM and are not connected back to the rules that need updating
- exceptions live in spreadsheets and risk registers, not in a workflow that closes them
- the annual validation is reconstructed from memory because nobody captured the decisions as they were made
Every one of these is solvable. None of them are solvable by adding more people to a manual process.
What changes when the lifecycle is the platform
If the operating model is treated as the product, the same six activities collapse dramatically:
- Discovery stops being a one-off project. Execution telemetry from Defender for Endpoint, Windows event logs, and endpoint agents flows continuously into the platform, and the catalogue of "what runs here" is always current.
- Policy authoring stops being XML editing. Administrators manage logical applications — Adobe Acrobat, the finance team's payroll tool, the developer toolchain — and the platform generates the WDAC rules underneath. When a vendor rotates a certificate, the application is updated once and every policy that referenced it regenerates.
- Audit-mode operation becomes a feedback loop. Audit events come back into the platform and surface as suggested rule additions or deny rules, attached to the application that triggered them. The cycle that used to take weeks per iteration runs in days.
- Exception management becomes a workflow. A time-bounded, audited override path means the Friday afternoon "I need this to run right now" request has a designed answer that does not silently weaken the policy.
- Enforcement transition stops being a leap. Ring-based deployment, version history, and rollback are first-class features rather than scripted afterthoughts.
- Annual validation becomes evidence generation. Every change to every policy is captured at the moment it happens, with the application context, the approver, and the reason. The auditor's question about why a specific publisher is trusted has an answer that does not require archaeology.
The ML3 controls do not change. The work to satisfy them does.
Six months is realistic, with caveats
Six months is not a marketing number. It is what the timeline looks like when the manual work is replaced with a platform that carries the lifecycle, and when the operating-model questions are answered before policy authoring starts rather than after enforcement breaks something.
The caveats are real:
- the organisation still has to decide who owns the program, who approves new applications, and how exceptions are handled
- the discovery period still has to cover a representative cross-section of the estate, including the workloads nobody talks about until they break
- enforcement still rolls out in rings, and the first ring still surfaces things the discovery missed
- annual validation still requires someone to make decisions, even if the evidence is generated automatically
What changes is the ratio of decision time to mechanical time. In a conventional program, most of the calendar is mechanical. With the right platform, most of the calendar is decisions, and the mechanical work happens between meetings rather than between quarters.
Why this matters now
Under Horizon 2 of the national cyber strategy (2026–2028), ML3 is the target for critical infrastructure, defence, finance, and government. ML2 is becoming the baseline for everyone else. If your sector is on either list, the realistic timeline starts now, not after the next audit.
A two-year program started today lands after the horizon it was meant to satisfy. A six-month program started today lands inside it, with time to refine before the next audit window.
The question is not whether ML3 is achievable. The controls are well-defined, the technology is in the operating system, and the framework is unambiguous. The question is whether your operating model around application control is built for the timeline you actually have.
How WDACManager fits
WDACManager exists because most of what makes ML3 a two-year program is work the technology should be doing for you. The platform sits on top of native WDAC and carries the lifecycle: discovery, application abstraction, policy generation, deployment through Intune or directly, audit feedback, exception handling through OneCode, version history, and audit-ready evidence.
The WDAC enforcement engine in Windows does not change. What changes is everything around it. That is where the two years live, and that is where the compression comes from.
ML3 stops being a two-year program when the operating model stops being the bottleneck. The technology has been ready for years.