Maturity Level 3 counters adversaries who are more adaptive and less reliant on public tooling — attackers who tailor their approach to you. It’s for organisations whose threat picture, regulator or contracts demand it, not a default target. In practice it means the fastest patch timeframes, phishing-resistant MFA, and centralised event logging that someone actually watches.
ASD’s maturity model at cyber.gov.au assigns each level an adversary. Maturity Level 3 counters adversaries who are more adaptive and less reliant on public tooling — attackers who study a specific target, adjust when a technique fails, and bring capability the commodity levels never see. That sentence is the qualification test. If nobody with that profile has a reason to study you, Maturity Level 3 is probably not your target.
The organisations that genuinely need it share a shape: they hold information or operate systems that make targeted effort worthwhile, or they sit in a supply chain where someone upstream does. Government environments handling sensitive information, operators of infrastructure other people depend on, and suppliers whose contracts name the level explicitly. For everyone else, ASD’s own guidance applies — implement a maturity level suited to your threat environment, and hold it.
Note what’s absent from that list: there’s no general mandate. The Protective Security Policy Framework mandates Maturity Level 2 for non-corporate Commonwealth entities. Where Maturity Level 3 is required, the requirement arrives through a specific contract, a regulator, or a threat assessment — which means the first question isn’t “how do we get there?” but “who is asking, and what will they accept as proof?”
The eight strategies don’t change — application control, patch applications, configure Microsoft Office macro settings, user application hardening, restrict administrative privileges, patch operating systems, multi-factor authentication, regular backups. What changes is how little slack the model leaves in any of them, and how much of the level is detection rather than prevention.
| Mitigation strategy | What the top of the model expects | What the evidence looks like |
|---|---|---|
| Application control | The strongest coverage in the model, with rulesets validated rather than assumed, and execution events feeding central logs | Ruleset validation records and the events themselves, queryable |
| Patch applications | The fastest patch timeframes, driven by frequent scanning | Scan-to-patch intervals you can report, not just patch dates |
| Configure Microsoft Office macro settings | Macro execution locked to the narrowest justified set, with events visible centrally | The approved list, and logs showing everything outside it blocked |
| User application hardening | Hardening at its fullest extent, aligned to current published guidance | Configuration baselines and drift checks against them |
| Restrict administrative privileges | The tightest privilege controls, with privileged activity logged and reviewed | Privilege registers, re-validation records, and the activity logs |
| Patch operating systems | Fastest OS timeframes; nothing unsupported anywhere in the fleet | Scan results proving the window held, fleet-wide |
| Multi-factor authentication | Phishing-resistant MFA — methods a convincing fake login page can’t harvest | Enrolment records showing who authenticates with what method |
| Regular backups | Backups an attacker with a foothold can neither reach nor alter, restores proven | Access-control evidence and dated restoration tests |
Two threads run through the whole table. First, centralised event logging: at the top of the model, events from across the strategies land in one place, the logs are protected from tampering, and signs of compromise are detected and acted on. That’s a SIEM capability with humans behind it, not a log folder. Second, pace: the fastest patch timeframes only hold if vulnerability scanning and patch tracking run continuously — a monthly cycle can’t evidence a weekly window.
Assessment at this level is almost always independent. There’s still no single central provider — it’s IRAP assessors where formal assurance is required, private consultancies otherwise — but self-assessment rarely satisfies whoever demanded Maturity Level 3 in the first place.
Treating Maturity Level 3 as a badge — “the best one” — and chasing it without an adversary who justifies it. The failure mode is predictable: the uplift project reaches the level on assessment day, the operational load (fast patch windows, log monitoring, privilege reviews) exceeds what the team can sustain, and six months later the organisation is at Maturity Level 2 in practice while claiming Maturity Level 3 in questionnaires. That gap is worse than the honest level, because it’s a claim someone will eventually test. ASD’s model is explicit that levels correspond to adversary tradecraft, not to virtue — pick the one your threat picture demands and resource it to hold.
Maturity Level 3 is mostly sustained operations, and that’s what we run: continuous scanning and patch verification, centralised logging with real monitoring behind it, privilege and MFA coverage tracked week to week — evidence accumulating as the by-product. Already have Splunk, CrowdStrike or Defender? We layer over it and unify the data rather than replacing it. Commercials are scoped to the engagement. If Maturity Level 3 isn’t actually warranted for you, the readiness call is where we’ll say so.
Is anyone actually required to reach Maturity Level 3?
There’s no blanket mandate. The Protective Security Policy Framework mandates Maturity Level 2 for non-corporate Commonwealth entities; Maturity Level 3 requirements arrive through specific contracts, regulators, or an organisation’s own assessment of its threat environment.
What's the practical difference between Maturity Level 2 and 3?
Posture and pace: the fastest patch timeframes in the model, phishing-resistant MFA, the tightest privilege controls, and centralised event logging that’s protected and monitored rather than merely collected.
Is Maturity Level 3 overkill for us?
Possibly. ASD’s guidance is to implement a maturity level suited to your threat environment. If your adversary profile is opportunistic rather than targeted, Maturity Level 2 held consistently beats Maturity Level 3 attempted and abandoned.
Does Maturity Level 3 mean we need 24/7 monitoring?
The model expects event logs to be centrally collected and signs of compromise to be detected and acted on — the monitoring has to be real, whoever runs it. Many organisations meet that with a provider rather than an in-house roster.
Can we be Maturity Level 3 in some strategies and 2 in others?
You can operate that way, but your overall maturity is the lowest level across the eight strategies — so you’d report Maturity Level 2. Mixed levels make sense as a transition, not as an end state.
