Choosing an Essential Eight target maturity level

Which Essential Eight maturity level should we target?

Most organizations target at least Maturity Level One (ML1), and a non-corporate Commonwealth entity bound by the Protective Security Policy Framework must reach ML2, according to Microsoft Learn's summary of PSPF section 14.2. Entities regulated under the Critical infrastructure risk management program Rules may use ML1 as one option among several recognized frameworks, so the first task is to read the exact obligation in your contract, regulator letter or board mandate. The obligation sets the floor, and the level you choose should never sit below it. Confirm the wording with the party that issued the requirement, because a requirement for a level usually means the level achieved, not a plan to reach it.

Once the floor is clear, weigh it against the threat you need to stop. ML1 addresses commodity tradecraft, ML2 addresses more capable and targeted adversaries, and ML3 addresses the most sophisticated adversaries. Scope the size of the work too: the ISM v2026.09.4 Essential Eight profiles contain 46 controls at ML1, 87 at ML2 and 123 at ML3, so ML2 roughly doubles the ML1 control set. Because each level builds on the one below, a target of ML2 means finishing ML1 first, and a target of ML3 means ML2 is already a prerequisite. Ask your team to map current systems against the ML1 and ML2 profiles before setting a date, since the gap, not the level name, determines cost and effort.

The organization owns the target, the risk acceptance and the decision to pursue a level. An implementation partner can help you assess the gap, prepare systems and assemble evidence, but it does not confirm the level achieved. Only an independent assessor can do that, so agree on the assessor and the assessment method before you commit to a target. Document the chosen level, the obligation it satisfies and the date the board approved it, because that record is the first thing an assessor or regulator will ask for.

What each maturity level is designed to stop

The Essential Eight maturity model sets Levels One to Three to mitigate increasingly capable and targeted adversary tradecraft. Each level assumes the one below is already in place, so the threat each card describes is cumulative: a higher level still has to stop everything the lower levels stop.

ML1: opportunistic attackers

Level One targets commodity threats: adversaries who run broad, automated campaigns using known vulnerabilities, stolen or weak passwords, and malicious macros in email attachments. The controls focus on removing the easy entry points, such as unpatched applications, Office macros running by default and users with standing administrative rights. When choosing this target, check that your environment can show these basics working across all systems, not only on the machines your team manages most often. Ask whether the scope covers contractors and remote devices.

ML2: targeted adversaries using common tradecraft

Level Two is designed for adversaries who are more capable and who deliberately target an organization, often by using stolen credentials, phishing-resistant bypasses and living-off-the-land techniques. The step up is less about new tools and more about detection and control: phishing-resistant MFA for system users, privileged access that expires, and events that are centrally logged and protected. Before you commit, confirm that you can produce those logs and that someone reviews them.

ML3: sophisticated, persistent adversaries

Level Three addresses adversaries with the resources and patience to develop tailored tradecraft, including exploiting drivers and firmware, abusing standing administrative credentials and tampering with backups. The controls add just-in-time administration, Secure Admin Workstations, driver and firmware patching, and backups that administrators cannot change during retention. Ask whether the organization has the operational maturity to run these controls without causing outages, since many ML3 controls restrict everyday administrative work.

Why the levels build on each other

Every ML1 control also appears in ML2, and all but three ML2 controls also appear in ML3, where three are replaced by stricter versions. This means a higher target is not a separate program that replaces the first one. Gaps in ML1, such as unsupported applications or macros that run by default, will fail an ML2 or ML3 assessment too. Check your current position against the lower level before you plan any uplift work.

Confirm the target against external drivers

Some organizations must meet a minimum level because of a rule or contract, not because of their own threat assessment. Government entities subject to the PSPF and certain critical infrastructure operators under the CIRMP Rules may have a required level or a choice of frameworks. Read the exact clause that applies to your entity, confirm whether it names a level or a framework, and ask your regulator or contract owner whether a lower level is acceptable before setting a target.

How the PSPF and CIRMP Rules set a minimum target

For some organizations the target level is not a free choice. Two external drivers set a floor, and the first step is to find out whether either applies to you. For Australian non-corporate Commonwealth entities subject to the *Public Governance, Performance and Accountability Act 2013* (PGPA Act), Microsoft's Essential Eight guidance states that Maturity Level 2 is mandatory, citing section 14.2 of the Protective Security Policy Framework (PSPF). If your entity falls in that group, ML1 is not an acceptable end state, and your planning should start from ML2 and the logging, privileged access and application control work that ML2 brings. Confirm the applicable PSPF requirement with your agency's security adviser or legal team rather than relying on a summary, because the obligation attaches to your entity's status, not to the framework itself.

The Critical infrastructure risk management program (CIRMP) Rules 2023 work differently. Section 8(4) requires responsible entities to comply with one of five frameworks: AS ISO/IEC 27001:2015, the Essential Eight Maturity Model at maturity level one, the NIST Cybersecurity Framework, C2M2 at Maturity Indicator Level 1, or the 2020-21 AESCSF Framework Core at Security Profile 1. Choosing the Essential Eight route means ML1 is the compliance floor for that option only. An entity that meets the CIRMP through a different framework is not bound to ML1 by this section, and an entity that chose the Essential Eight route should not read ML1 as a sufficient security posture for its wider estate. Have your legal team confirm which framework your entity has adopted and whether any other obligation applies to it.

A regulatory minimum is often not the highest bar you will meet. Customer contracts, procurement questionnaires and board risk appetite may ask for ML2 or ML3 even where the law asks for less. Before you commit to a target, list every written requirement, record the level it names, and ask counterparties to state in writing whether they mean the Essential Eight level or a general statement of good practice. Where a contract says only that you must follow the Essential Eight without naming a level, ask for the level in writing before scoping any work.

How the control set grows from ML1 to ML3

Maturity Level One is the entry point. In the ISM v2026.09.4 Essential Eight baseline profiles, ML1 contains 46 ISM controls spread across the eight mitigation strategies. It sets the first requirements for each strategy, aimed at stopping the less capable and opportunistic adversary tradecraft the model describes. Because it is the foundation for every higher level, the work done here carries forward rather than being discarded later.

Control count: 46 ISM controls form the ML1 profile, the smallest of the three sets.
Scope of effort: Most ML1 work is configuration and policy: dedicated admin accounts, macro settings, browser hardening and a working backup routine.
Foundation role: Every ML1 control also appears in ML2, so ML1 implementation is not wasted when an organization moves up.
Ownership: The organization owns the controls and decisions, while an implementation partner may prepare configurations and evidence.
Cost driver: Estate size and the number of unmanaged systems usually matter more than the control count itself.

Before committing to a level, confirm the current ML1 status of each strategy with an assessor or your own evidence, since an uplift plan depends on it.

Why skipping a level costs more than it saves

A target above ML1 is not a separate project. Every ML1 control in the ISM Essential Eight profiles also appears in ML2, and all but three ML2 controls (ISM-1691, ISM-1695 and ISM-1873) also appear in ML3. Those three are replaced by stricter ML3 versions rather than dropped. An organization that aims for ML2 or ML3 therefore carries its ML1 work forward, and the planning question becomes how much new scope to add and in what order. Treating a higher target as a fresh start usually means re-doing configuration, documentation and evidence that already exists.

Moving to ML2 is the largest single step in the control set, adding 41 controls in the ISM profiles, much of it centralized event logging, log protection, log analysis and incident reporting. A central log platform is a prerequisite for ML2, so planning has to start there, not at the end of the project. Confirm with your team how logs are collected today, where they are stored, how long they are retained and who can alter them. If the answer is that logs stay on individual endpoints or servers, the logging build is the critical path, and it should be scheduled and resourced before any other ML2 work is promised to a regulator, customer or board.

Skipping a level tends to cost more because the deferred work does not disappear. An organization that stops at ML1 to save effort will still need the logging platform, the privileged access changes and the backup protections later, usually under deadline pressure and with systems that have grown in the meantime. Ask any implementation partner to show, in writing, which ML1 controls will be reused at the next level, which will need rework, and which new platforms the next level requires. That written view is the basis for a fair comparison between a one-step and a two-step plan.

How to set the target in four steps

This sequence turns an informal sense of ambition into a documented target level, with a named owner and a clear list of the gaps that stand between current state and that level. Each step produces a record that an assessor or regulator can later check.

Confirm the obligation in writing
Start by establishing which requirement actually applies to the organization. Ask legal, compliance or the contracting team to identify the source in writing, such as a government policy that cites a Maturity Level, a critical infrastructure rule that accepts Maturity Level One as one of several options, or a customer contract that names a level. Record the clause, the regulator or counterparty, and the wording used. The step is done when someone can point to a document that states the minimum level, or when the team confirms in writing that no external obligation exists and the target is voluntary. Where an obligation appears to be unclear, confirm the reading with the regulator or the contract owner rather than assuming it.
Define the scope of assessment
Decide which systems, business units, user populations and cloud accounts the target level will cover. A level applies to the environment it is assessed against, so a boundary drawn too narrowly can leave out the systems an auditor or regulator will test. Document the in-scope asset inventory, the owners of each asset group, and any systems deliberately excluded with the reason. The output is a scope statement signed off by the owner of the target level, and an asset list that the gap assessment in the next step can use as its population.
Map each strategy to current maturity
Run a gap assessment that scores each of the eight mitigation strategies against the requirements of Maturity Level One, Two and Three, using the ASD maturity model and the ISM Essential Eight baseline profiles as the reference set. For each strategy, record the level the organization currently meets, the specific controls that are missing at the next level, and the evidence that exists or does not. Staff with access to the systems should perform the checks, and a second person should review the results. The output is a matrix of eight strategies, current level for each, and a list of unmet controls grouped by the work needed to close them. Because the requirements build on each other, the lowest-scoring strategy usually sets the practical ceiling.
Estimate the uplift effort by strategy
Using the gap matrix, describe the work needed to reach each candidate level for each strategy. Note which items need new tooling, such as central logging or immutable backup storage, which need configuration changes, and which need process or staffing decisions. Flag the items that depend on other teams, vendors or contracts, because these tend to set the timeline. Ask any implementation partner or internal platform team to review the list and confirm the scope in writing before the decision in the next step. The output is a set of options, one per candidate level, each with the named dependencies and the open questions that remain.
Decide the level and the date
Choose the target level and the date by which it must be met, based on the obligation from step one, the gap matrix, and the uplift options. Where a regulator or contract sets the minimum, the target cannot sit below it. Where the choice is voluntary, weigh the adversary tradecraft each level is designed to address against the cost of the controls it adds. Put the decision to the accountable executive, and record the reasons, the known risks of deferring any higher level, and any compensating measures agreed for gaps that will remain open at the date.
Record the decision with the owner
Write the decision into a single governance record that names the accountable executive, the control owner for each of the eight strategies, the target level, the target date, and the review point. Link the record to the scope statement, the gap matrix and the uplift options so that each can be traced later. Confirm that the owners accept their assignments in writing. The step is complete when the record is stored where audit and assurance teams can retrieve it, and when the owners have a copy of their tasks in the tracker they use day to day.

What makes a target too high or too low

A target maturity level is only useful if it matches the systems in scope, the obligations that apply and the people who will keep it running. The cards below cover the most common ways a target goes wrong, and the check that catches each one before work starts.

Targeting ML3 without central logging

ML3 builds on ML2, and ML2 makes centralised event logging, log protection and log analysis a prerequisite. An organization that sets ML3 before a central log platform exists will spend most of its budget on controls that cannot be evidenced. Before committing, confirm that events from every in-scope system reach one store, that logs are protected from modification, and that someone reviews them on a defined schedule. The ML2 logging controls are the first thing to test, not the last.

Targeting ML1 when a contract requires ML2

A target set below an external requirement fails on the first assessment, and the gap is often discovered late. Microsoft Learn states that Maturity Level 2 is mandatory for non-corporate Commonwealth entities under the PGPA Act, citing section 14.2 of the PSPF. Customers, regulators and parent organizations can impose similar demands by contract. Before setting the target, ask each party who requires a level and which version of the model they reference, and record the answer in the scope document.

Unclear scope across systems and locations

A maturity level applies to the systems in scope, and an unclear boundary makes every level claim unverifiable. Teams often leave out identity providers, backup platforms, jump hosts, developer workstations or a branch office, then discover an assessor treats them as in scope. Define the system list, the user populations and the physical locations in writing before choosing a level. Confirm who owns each system, because a system without an owner usually has no patching cadence, no logging and no restore test.

Unowned recurring tasks after uplift

Each level depends on work that repeats: scanning on fixed cadences, reviewing rulesets, expiring privileged access, running restore tests and checking for configuration drift. A target that assumes these tasks happen without named owners tends to slip within months of the uplift. For each recurring control, record the role responsible, the frequency, where the output is stored and who checks it. If no one can name the owner for a task, the target is too high for the current operating model, whatever the technical capability.

Treating the target as a certification

The Essential Eight is a set of mitigations, not a certification scheme, and ASD issues no certificate for a maturity level. A target expressed as a badge to win a tender invites shortcuts, such as documenting a control without testing its effectiveness. Maturity is shown through assessment of each strategy's implementation and effectiveness against the model. Ask whether the claimed level will be supported by evidence an independent assessor can test, and ask the assessor which evidence they expect for each strategy.

Which target fits which obligation

This table compares four common reasons to adopt the Essential Eight, showing the minimum target each usually implies, what pushes the target higher, and what to confirm with the source. Read each row against your own legal and contractual position, because the governing source sets the level. Since each level builds on the one below, a higher target also brings the lower level's controls.

Obligation	Typical minimum target	What drives a higher target	What to confirm with the source
PSPF-bound entity	Maturity Level 2, as Microsoft Learn summarizes section 14.2 of the PSPF for non-corporate Commonwealth entities under the PGPA Act	Entity risk assessment, agency direction, and ML3 controls such as just-in-time administration and immutable backups	Current PSPF wording, whether your entity is in scope, and any due dates set by your agency
CIRMP responsible entity choosing the Essential Eight	Maturity Level 1, under section 8(4) of the CIRMP Rules 2023 as made	Sector risk profile, the choice of a higher framework option, and the ML2 step, which adds 41 ISM controls	Whether the Essential Eight is your chosen framework, which level applies to your asset, and any regulator guidance
Contracted supplier with a customer requirement	Set by the contract, with no standard minimum across the market	Sensitivity of customer data, flow-down of government or critical infrastructure rules, and audit rights in the contract	The exact level, the evidence expected, who assesses it, and the deadline in the security schedule
Voluntary adopter	Usually Maturity Level 1 as a first step, since each level extends the one below	Threat exposure, incident history, board or insurer expectations, and capacity to build central logging for ML2	Whether any customer, insurer or partner will ask for a stated level, and what evidence they accept

Who owns the target and who confirms the level

The organization owns its target maturity level and every decision that follows from it. The Essential Eight is a set of mitigation strategies rather than a certification scheme, so there is no ASD certificate to obtain. Maturity is judged by an assessor who examines whether each of the eight strategies is implemented and effective against the requirements of the level the organization has chosen. The target itself, and the risk appetite and external obligations behind it, belong to the accountable executive, who should sign off the choice in writing before any gap work begins.

An implementation partner such as DeployOpen can prepare the systems and evidence that an assessment will examine. In practice that means documenting the current state of each strategy against the level's requirements, mapping the gaps, configuring the controls in the client's own environment and assembling the records, such as scan outputs, MFA configurations and backup restore test results. The partner can also document the gap between the current state and the target. That work is preparation. DeployOpen does not issue assessment outcomes, reports or certificates, and it does not confirm that a level has been reached.

Only an independent assessor issues the assessment outcome. Before you commit to a target, confirm with your regulator or contract owner which level they accept, since the Protective Security Policy Framework and the CIRMP Rules name specific levels for different entities. Then agree with the assessor, in writing, the scope, the evidence they will test and how they will report each strategy. Ask whether they will review the partner's evidence packs or sample the underlying systems directly, because that answer determines how much of the preparation work will count toward the outcome.

Questions buyers ask about choosing a target level

Is Essential Eight Maturity Level 2 mandatory for us?

It depends on your sector and the rules that apply to you, so confirm the source of the requirement before you plan. Microsoft Learn states that ML2 is a mandatory requirement for non-corporate Commonwealth entities subject to the PGPA Act, citing section 14.2 of the Protective Security Policy Framework. For critical infrastructure, section 8(4) of the CIRMP Rules 2023 lets responsible entities choose one of several frameworks, and the Essential Eight at maturity level one is one of the options listed. Ask your regulator, contract owner or legal team which level they expect in writing, and whether that level applies to your whole estate or a defined scope. Also check Microsoft's overview of the Essential Eight for the current summary of those obligations.

Can we target ML1 now and move to ML2 later?

Yes, and the levels are built so that this is a normal path. In the ISM v2026.09.4 Essential Eight profiles, every ML1 control is also in ML2, so work completed at ML1 carries forward rather than being discarded. Each level sets requirements for all eight strategies, so the question is which controls you can evidence today and what the next step adds. Plan the ML1 work so it does not create rework later, for example by choosing a central log platform and an identity approach that can support ML2 requirements. Confirm with your assessor or contract owner whether an interim ML1 result is acceptable for your timeline.

How much more work is ML2 than ML1 in control count?

In the ISM v2026.09.4 Essential Eight profiles, ML1 contains 46 controls and ML2 contains 87, so ML2 roughly doubles the ML1 control set. Moving to ML2 adds 41 controls, much of it centralised event logging, log protection and analysis, and incident reporting. Control count is only a rough guide, because a single control can involve many systems and a set of technical changes. The effort also depends on how mature your identity, patching and logging tooling already is, and on how many systems fall in scope. Ask any consultant to show a control-by-control gap assessment against your environment rather than a count alone.

Do we need a central log platform before moving to ML2?

Yes. Centralised event logging, log protection and log analysis are a large part of what ML2 adds, so a central log platform is a prerequisite for ML2 in practice. Without one, you cannot show that the required events are collected centrally, protected from alteration, and reviewed in a timely way. Choose the platform before you start the ML2 work, and confirm which events, retention periods and analysis tasks your target level requires with the current maturity model. Open-source and self-hosted logging stacks can meet these needs, but you should confirm each capability against the requirement rather than assume it.

Can our own team set the target maturity level?

Yes. The choice of target is an internal governance decision, and your security leadership can make it using the maturity model, your external drivers and your risk appetite. The steps are to list the rules that apply to you, identify the level each one requires, check the current state of the eight strategies, and record the decision with its owner. Outside help is useful when the current state is unclear, when several regulators set different levels, or when the internal team lacks time to assess evidence. An independent assessor is needed to verify the result, because the Essential Eight is a set of mitigations and not a certification scheme.

What does the work need from our team?

The work needs owners for each of the eight strategies, people who can change configurations across identity, endpoints, servers and backups, and someone who can collect and retain evidence. Expect the identity, endpoint and infrastructure teams to carry most of the technical change, with risk or compliance leads owning the decisions and the evidence file. Ask any implementation partner to name which tasks they perform, which stay with your staff, and what your team must approve in writing. Fixed-scope engagements list these responsibilities in the agreed scope before work starts, which helps your team plan its time.

How DeployOpen scopes an Essential Eight target

DeployOpen starts by agreeing a written scope that names the Essential Eight maturity level you are aiming for, the systems and strategies in that scope, and the evidence your assessor will expect. We then prepare the systems and records to meet that target, while your organization keeps ownership of its controls and the independent assessment remains with your assessor.

How we scope

We confirm which systems, business units and of the eight strategies sit inside the target level scope.
We map your external driver, such as a PSPF or CIRMP obligation, to the maturity level your scope must reach.
The written scope lists deliverables, assumptions and the evidence each strategy must produce before work starts.

How we build

We implement the controls needed for the agreed level in your own cloud accounts, data centers or air-gapped networks.
We configure central logging, scanning and backup tooling where the target level requires them, using open-source platforms you can operate.
We test each strategy against the maturity model and record results so gaps are visible before your assessor arrives.

How we hand over

We document configurations, owners, procedures and recurring tasks so your team can run the level without us.
We deliver an evidence register that maps each in-scope control to the artifacts that show it is in place.
We walk your staff through handover so they can explain the controls to internal reviewers and independent assessors.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover is complete.
A retainer can cover scanning cadence reviews, restore tests and changes when the ISM or maturity model is updated.
Any change to the target level is handled as a new written scope with its own deliverables and timeline.