The Essential Eight is being retired. What that means for application control
ASD confirmed in June 2026 that the Essential Eight will be replaced by the Essentials series. Application control is not going away, and here is why.
On 24 June 2026 the Australian Signals Directorate confirmed that the Essential Eight will be retired and replaced by a broader set of guidance called the Essentials series. If you are part way through an application control programme justified on Essential Eight grounds, the obvious question is whether that work still counts. It does, and this is why.
What was actually announced
The headline points, as they stand.
- The Essential Eight will be replaced by the Essentials series, structured as separate chapters for different domains rather than one list of eight mitigations.
- The first chapter covers enterprise IT, with operational technology and cloud chapters to follow. A chapter on agentic AI has been flagged as likely.
- The two frameworks are expected to run side by side for around 12 months, with deprecation after that and full retirement at roughly 24 months.
- The stated reasoning is that a single list of eight mitigations designed for a Windows domain estate is a poor fit for an environment of software as a service, cloud, bring your own device and AI agents.
The new guidance is described as leaning towards outcomes and intent, giving organisations more flexibility in how they satisfy it, rather than prescribing a specific implementation.
At the time of writing the enterprise IT chapter has been through consultation and the detailed control text is what matters most for planning. Treat any specific claim about what the new chapters require, including from us, as provisional until the final text is published.
Why application control is not the part at risk
Frameworks are packaging. Controls are the actual thing.
The reason application control has appeared in the Essential Eight since the beginning is not that a committee liked it. It is that deny by default execution control addresses a class of problem that detection based controls structurally cannot. Ransomware needs to run an encryptor. Unknown malware defeats anything that has to recognise a threat first. Neither of those facts changes because the framework is renamed.
The stated motivation for the change also points the other way. The Essentials series is being introduced because the old model did not cover cloud, SaaS and modern endpoint reality well enough. That is an argument for more coverage of execution control across more surfaces, not less.
What genuinely does change
Being honest about this rather than reassuring.
The compliance vocabulary. "Maturity Level 2 for application control" is language that will stop meaning anything in about two years. If your board reporting, your internal standards and your supplier contracts are written in maturity level terms, that is a documentation exercise ahead of you.
The evidence you present. Guidance framed around outcomes and intent tends to ask you to demonstrate that a control is effective, not just that it is configured. A screenshot of a policy in Intune is weaker evidence than a record of what was blocked, what was approved, by whom, and what happened when it broke.
The scope. Separate chapters for enterprise IT, operational technology and cloud means the question of where application control applies gets asked more precisely. An OT environment has different constraints and a much lower tolerance for a bad policy.
What to do in the next twelve months
Do not pause. Maturity Level 2 is the current baseline expectation for most organisations, cyber insurers are increasingly asking for evidence of Essential Eight alignment before they will write or renew a policy, and the transition period means the old framework still applies. Stopping controls work because a framework is being renamed would be difficult to defend.
Build the control, not the checkbox. Work that produces a maintainable policy, a real intake path for new applications and a rollback capability you have actually tested will satisfy any framework. Work that produces a policy in audit mode that nobody reads satisfies neither.
Keep the evidence trail now. Policy versions, approvals, exceptions and their expiry, rollback events. If the new guidance leans harder on demonstrating effectiveness, the organisations that already keep this will have a much easier time than the ones reconstructing it.
Write the scope down. Which device groups, which binary types, which environments are explicitly out. That document is useful today and it is the thing a domain structured framework will ask you for.
The uncomfortable part
Most organisations that report application control maturity are reporting on a policy that is not actually enforcing, or is enforcing with path rules broad enough that the protection is thin. That was survivable under a framework focused on implementation. It is less survivable under guidance focused on outcomes.
If your application control position would not withstand someone asking what it actually blocked last month, the framework change is not your problem. That is worth knowing before somebody else points it out.
Where this leaves you
Application control was a good investment when it was control eight of eight, and it remains one under whatever the guidance ends up being called. The work that transfers is the operational work: knowing what runs in your environment, having a policy built on durable rules, having a path for new software, and being able to reverse a bad decision quickly.
That is the same work regardless of the framework, which is rather the point.
If you want the practical version, the platform sets out the sequence and is honest about where the time goes. The App Control fundamentals piece covers the control itself.
Whichever framework replaces the one you mapped to, the control being asked about is the same and so is the evidence. PoliEze produces that evidence as a by-product of running the control rather than as a reporting exercise before an audit, and reports against whichever framework your documentation uses.
Sources
- Essential Eight and the Essential Eight Maturity Model, from the Australian Signals Directorate
- Application Control for Windows, for what the Windows control actually does
- Applications that can bypass App Control and how to block them
Questions about this
Is the Essential Eight being retired?
Does application control survive the change?
Should we pause our Essential Eight work?
Related reading
The missing control plane for App Control for Business
Windows already enforces. What no vendor ships is the layer that decides what to trust, records who approved it, and takes it away again when it is no longer needed.
Every application control product identifies files the same way
The file identity model is common to all of them. What separates one product from another is the operating model around it, which is what evaluations skip.
Policy options that mean the opposite of what they read
An App Control policy option is true because it is present. Several are written as double negatives, so the secure setting is often the one nobody set.