Maturity Level 3 counters adversaries who are more adaptive and less reliant on public tooling — attackers who tailor their approach to a specific target. It applies to organisations whose threat picture, regulator or contracts require it, and it is not a default target. In practice it means the fastest patch timeframes in the model, phishing-resistant MFA, and centralised event logging that is monitored.
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 encounter. That adversary profile is the qualification test for the level.
The organisations that require it hold information or operate systems that make targeted effort worthwhile, or sit in a supply chain where an upstream party does: government environments handling sensitive information, operators of infrastructure other organisations depend on, and suppliers whose contracts name the level explicitly. For everyone else, ASD’s guidance is to implement a maturity level suited to the threat environment and hold it.
There is no general mandate at this level. 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 — so the first thing to establish is who is asking and what they will accept as proof.
The eight strategies are unchanged — 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 tolerance the model leaves in each 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, alongside 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 cannot 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 requirements run through the whole table. 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 requires a SIEM capability with analysts operating it. And pace: the fastest patch timeframes hold only where vulnerability scanning and patch tracking run continuously, because a monthly cycle cannot evidence a weekly window.
Assessment at this level is usually independent. There is still no single central provider — IRAP assessors where formal assurance is required, private consultancies otherwise — but self-assessment rarely satisfies the party that specified Maturity Level 3.
ASD’s model ties each level to adversary tradecraft rather than to security quality, so the level is chosen against a threat picture rather than aimed at as the best available score.
Where it is chased without a matching adversary, the outcome follows a consistent pattern: the uplift project reaches the level on assessment day, the operational load of fast patch windows, log monitoring and privilege reviews exceeds what the team can sustain, and within six months the organisation operates at Maturity Level 2 while claiming Maturity Level 3 in questionnaires. That claim is testable, and it will eventually be tested. Selecting the level the threat picture demands, and resourcing it to hold, produces a defensible position.
Maturity Level 3 is largely sustained operations, and that is what we run: continuous scanning and patch verification, centralised logging with monitoring behind it, privilege and MFA coverage tracked week to week, with evidence accumulating as a by-product. Where Splunk, CrowdStrike or Defender is already in place, we layer over it and unify the data rather than replacing it. Commercials are scoped to the engagement. Where Maturity Level 3 is not warranted for your threat picture, the readiness call says so.
Is anyone required to reach Maturity Level 3?
There is 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 is protected and monitored rather than only collected.
Is Maturity Level 3 excessive for us?
Possibly. ASD’s guidance is to implement a maturity level suited to your threat environment. Where the adversary profile is opportunistic rather than targeted, Maturity Level 2 held consistently is a stronger position than 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 operating, 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 overall maturity is the lowest level across the eight strategies, so the reported level would be Maturity Level 2. Mixed levels work as a transition state rather than an end state.
