ML1 is enough. Most SMBs still overshoot.
The Essential Eight has three maturity levels. Most SMBs reach for ML2 or ML3 because the number looks better. Here's why ML1, done honestly, beats ML2 done badly - and what the gap actually costs.
Every quarter we have the same conversation. A business owner comes in and says they need to get to ML2 by EOFY. Sometimes it's a real requirement - a contract with a federal agency, a condition buried in their cyber insurance renewal. Most of the time it's an internal target someone set because "higher must mean better." We spend the first thirty minutes figuring out which one it is, because the answer changes everything.
The three levels, in plain English
The ACSC designed the Essential Eight around three maturity levels that map to different threat models, not a progression you climb as you mature. ML1 is the floor the ACSC expects every modern organisation to meet - it covers the baseline mitigations that stop the most common attack patterns: commodity ransomware, phishing-driven credential theft, and opportunistic exploitation of unpatched software. Done honestly, ML1 is a meaningful security posture for a 20 to 200 person SMB.
ML2 starts to look like a regulated or high-value-target environment. It introduces Privileged Access Workstations (dedicated hardened machines for administrative activity), application control in enforcement mode rather than audit mode, and time-bounded admin sessions with documented approval workflows. ML3 is the level the ACSC associates with state-actor-level threat models - credential theft via memory-scraping tools, supply chain compromise, persistent adversarial presence. Most SMBs are not in that threat model. Most are not even close.
What ML2 actually costs (and why most SMBs don't notice the bill)
Privileged Access Workstations are the item that surprises people most. ML2 wants a dedicated, hardened device for each person who does privileged work - your IT administrator, your finance approvers, anyone with Global Admin rights. For a 50-person business that typically means four PAWs to procure, configure, enrol in endpoint management, keep patched separately, and eventually decommission. The hardware cost is one thing. The cultural cost is the harder part: the person can't check their email or browse the web on their admin laptop. That rule breaks down within weeks unless someone is enforcing it, and enforcing it is a full-time behaviour-change programme.
Application control at ML2 has to be in enforcement mode, not audit. Audit mode is what you run while you're mapping your environment - it logs what would have been blocked without blocking anything. Enforcement mode blocks unknown executables. The transition from audit to enforcement typically breaks three to five line-of-business applications in the first week. Every breakage is a support ticket, a workflow disruption, and a conversation about whether the security control is worth the friction. We've done this migration many times. The organisations that get through it cleanly are the ones with an IT team that can absorb a chaotic fortnight. Many SMBs can't.
The reporting overhead at ML2 is also non-trivial. ML1 evidence is largely configuration-based - show us the policy, show us it's applied, show us some recent events. ML2 evidence requires historical proof: 30 days of blocked-execution events with the policy that generated them, 90 days of patch compliance records with CVE references, quarterly privileged access reviews with documented sign-off and the names of anyone removed. Building that audit trail takes tooling, calendar discipline, and someone whose job includes maintaining it. At an SMB without a dedicated security function, that's a real ongoing cost.
When ML1 is the wrong answer
There are situations where ML2 is genuinely the right target, not theatre. Before you conclude that ML1 is enough for you, check these three cases honestly:
- Your contract with a federal or state government agency explicitly cites ML2 as a condition of supply. Not 'aligned to the Essential Eight' - specifically ML2. Read the clause carefully.
- Your cyber insurer has raised the floor. This is becoming more common. Check the exact wording: 'aligned to ML2' and 'compliant with ML2' are different standards, and insurers know it.
- You handle special-category data: health records under the Privacy Act, financial advice data under AFSL obligations, or government PROTECTED-level material. These categories carry regulatory obligations that push the right answer toward ML2 regardless of your threat model.
In any other case, the question to ask before reaching for ML2 is: what specific threat am I trying to defend against, and does this control meaningfully reduce my exposure to it? If the honest answer is "it's the score I want to show people," you're solving the wrong problem. ML1 done properly is a better security outcome than ML2 done badly, and most organisations that rush to ML2 don't have the operational discipline to sustain it.
What honest ML1 looks like
Honest means evidence-backed. Anyone can write "we patch monthly" on a self-assessment. The honest version is the patch deployment report from NinjaOne or Intune showing actual SLA compliance over the last 90 days, the list of deferred patches with documented business justifications, the CVE references for the exploited vulnerabilities you patched within 48 hours. The framework isn't about the configuration you have; it's about the audit trail that proves it's real and it's maintained. An assessor who sees clean configuration with no supporting evidence will mark you down - rightly.
Honest also means the controls that don't feel like security work. Quarterly restore tests where someone actually restores a file, confirms the data is intact, and writes it up. Privileged access reviews where someone is actually removed from a role they no longer need - not a review where the list comes back unchanged every time. Macro allowlists that get pruned when the spreadsheet they were created for is retired. These controls fail most audits not because the technology is wrong but because they're operational, not technical. They need a calendar, an owner, and follow-through. That's the gap for most SMBs.
Where to start
Take the eight controls and rank your current environment honestly: green for implemented with evidence, amber for partially implemented or evidence is thin, red for not started. Don't set a target maturity until you know your starting maturity - it's the only way to size the gap realistically. We've put together a line-by-line ML1 checklist that goes through each control with the specific evidence an assessor will ask for. It's the same document we use as the baseline with new managed-service customers. If you're in a position where a customer or insurer has asked about your Essential Eight posture and you're not sure where to start, that's the starting point. Our Compliance Foundation Programme takes you from the checklist through to a documented, evidence-grade posture.
The conversation we'd rather have isn't "let's get you to ML3." It's "let's figure out where your real risk is and build the controls that actually move it." If your insurer or customer has asked for ML2 specifically, we'll get you there - see what ML2 actually involves before you commit. But check the ask first. Most of the time the requirement is ML1 done honestly, and that's a better use of your budget than a maturity number that looks good on a slide.
