The Essential Eight is being retired. What comes next?

A friend who works in cyber security and I were talking about the Essential Eight being retired (after he did not read to the end of my recent article). We realised we have both gravitated towards NIST, for cyber security and increasingly for AI.

Part of the reason is that NIST cybersecurity is pillar-based and it gives us a clear structure for thinking about a complex problem, without pretending every organisation has the same systems, risks or operating context.

That matters. A framework should help us organise the work. It should not become the work.

The Australian Signals Directorate has announced plans to retire the Essential Eight (although ASD says is will "evolve") over the next two years and replace it with a broader Essentials series. The transition is staged, so the Essential Eight remains relevant while the new guidance is developed. The proposed series is intended to cover a wider range of environments, including enterprise IT, cloud and operational technology.

This is a substantial change. But it is not a reason to stop doing the Essential Eight today.

A framework is a map

The Essential Eight has helped Australian organisations focus on practical security measures. That has value. Baselines make it easier to see whether important protections are in place and to have a concrete conversation about gaps.

But a baseline is not a security strategy.

Organisations now depend on cloud platforms, software-as-a-service, complex supply chains, operational technology and AI systems. Risk does not sit neatly inside eight mitigation strategies, or inside a single technology environment.

The proposed Essentials series seems to recognise that. Broader, threat-informed guidance could give organisations more room to work with their actual environment, rather than trying to make every environment fit the same maturity ladder. The test will be whether the new guidance is clear enough to use. “Outcomes-based” should not mean “work it out for yourself”.

Why we both like NIST

NIST gives us a useful structure for thinking about cyber security and AI risk. Its frameworks act as pillars: a small number of high-level functions that hold up the whole, leaving room for organisations to work out what those mean in their own context.

The NIST Cybersecurity Framework 2.0, for example, uses six functions: Govern, Identify, Protect, Detect, Respond and Recover. That’s a useful map. It helps people see what needs attention without assuming every organisation should implement the same controls in the same way.

NIST’s AI Risk Management Framework gives us another structure for thinking about AI risk. The frameworks are not a substitute for technical controls, judgement or local context. They give us a shared language for organising the work.

That is especially useful because AI risk is not just a model issue. It runs through security, procurement, data governance, operations and accountability.

NIST’s work on a Cyber AI Profile reflects that overlap. It looks at securing AI systems, using AI to support cyber defence and countering AI-enabled attacks. NIST’s early discussions also highlighted the dual-use nature of AI, the need for multidisciplinary collaboration, and the importance of human oversight and measurable performance.

AI changes the defence problem

AI can help defenders analyse data, find patterns and respond faster. It can also help attackers scale and adapt their activity.

And the AI systems we deploy have their own attack surfaces: data, models, identities, tools, integrations, permissions and dependencies. This is still software. It is also software that can act in ways we may not have anticipated.

A conventional red-team exercise once a year, followed by a report that sits on a shelf, is not enough.

We need red-purple-blue teaming as a continuous learning loop:

• Red teams test assumptions and probe for weaknesses in AI systems and the environments around them.
• Blue teams detect, respond and recover, using what they learn to improve operational defences.
• Purple teaming connects the two, turning findings into better detection, response and control.

AI tools can help with each part of that loop. MITRE ATT&CK gives teams a shared language for describing adversary techniques and planning tests. Adversary-emulation tools such as Apache CALDERA can automate repeatable simulations so teams can check whether their defences detect and respond to known behaviours.

For testing generative AI applications themselves, Microsoft’s open-source PyRIT can help security teams automate and structure adversarial testing. It can probe systems for risks and help teams identify areas that need closer examination. Microsoft is clear that PyRIT is intended to augment human expertise, not replace manual red teaming.

On the blue-team side, AI can help analysts sift through security alerts, summarise incident information and identify patterns across telemetry. Used well, these tools can reduce repetitive work and help teams focus their attention. Used badly, they can add noise, obscure uncertainty or create a new dependency that is hard to test.

Purple teaming is where the value should become visible. The team can use automated simulations to test a specific behaviour, check whether it was detected, review the evidence, tune the controls and run the test again. The point is not to automate for its own sake. The point is to close the gap between what we think our defences do and what they actually do.

Make the loop accountable

Red-purple-blue teaming should produce more than a list of vulnerabilities. It should help an organisation answer some basic questions:

• What did the test try to do, and within what boundaries?
• Which control detected it, and how quickly?
• What evidence was captured?
• Did an AI tool generate or prioritise any findings, and how were they checked?
• Who decided whether an alert needed action?
• What changed as a result?
• Has that change been tested again?

For AI systems, we also need to test the environment around the model. An agent’s permissions, connected tools, identity, data access and ability to act over time can matter as much as its outputs.

Automation can support this work. It cannot take responsibility for it.

People need to know what a system is permitted to do, when it must stop, and who is accountable when it does something unexpected. Testing also needs to be authorised and conducted within clear boundaries. A tool that can simulate attacks is not safe simply because it is called a testing tool.

The work continues

The Essential Eight will not disappear overnight. Its planned retirement does not make the work organisations have already done irrelevant. ASD’s transition plan allows the existing guidance and new Essentials material to run alongside each other for a period.

For Australian organisations, the practical response is to keep using the Essential Eight where it is useful, follow the development of the new guidance, and avoid treating any framework as a substitute for ongoing testing.

My friend and I came away with the same instinct: NIST gives us a useful structure for thinking about cyber security and AI together. It gives us a map, without pretending the map is the territory.

No framework or AI tool can do the work for us.

We need defence that learns: teams that test assumptions, share evidence, use automation carefully and change their approach as the threat changes. That is what we should carry into whatever comes after the Essential Eight.