Does Essential Eight Maturity Level 2 apply to our Commonwealth entity?
If your organization is a non-corporate Commonwealth entity subject to the PGPA Act, Maturity Level 2 is mandatory for you. Microsoft Learn cites section 14.2 of the Protective Security Policy Framework (PSPF) as the basis for this requirement, so confirm the current wording of that section with your agency's security adviser or the PSPF itself. ML2 is not a certificate you can obtain: it is a set of mitigations that an assessor tests against the Essential Eight Maturity Model, strategy by strategy, for both implementation and effectiveness.
The effort to get there depends on three things in your own estate. The first is the size and mix of the environment, since every ML2 control has to be met across every in-scope system, not only the flagship ones. The second is logging maturity. ML2 makes central logging of application control, PowerShell, command line, privileged access and MFA events a prerequisite, so if you do not already have a central log platform that protects and analyzes those events, that work comes first. The third is your privileged access model, because ML2 disables privileged access after 45 days of inactivity, requires revalidation at least every 12 months, and requires jump servers for administration.
Before asking for a quote, run a gap check against the ML2 profile in ASD's OSCAL catalog and record which of the controls you already meet with evidence. Ask any implementation partner to price the work from that written baseline, and confirm with your assessor which evidence they will accept. Partners can prepare systems and evidence, but only your own control owners and the independent assessor you engage can attest to the outcome.
Where ML2 gets harder than ML1 in practice
Moving from Maturity Level 1 to Maturity Level 2 changes five things at once: how staff authenticate, how long privileged accounts stay live, how administration is routed, where logs live, and how incidents are reported. Each decision depends on the others, so a gap in one usually shows up as a gap in the evidence for another. Check each one against the ISM control it maps to before scoping the work.
Phishing-resistant MFA for staff
ML1 accepts several MFA combinations that ML2 does not. ML2 requires phishing-resistant methods for staff accessing online services and systems, which covers controls ISM-1872 and ISM-1682. Check every staff path, including legacy protocols, VPN gateways, admin consoles and service accounts that still accept SMS or one-time codes. Evidence is an identity provider configuration export, a sign-in log sample per system, and a list of exceptions with approval records.
Privileged access inactivity limits
ML2 disables privileged access after 45 days of inactivity and after 12 months without revalidation, covered by ISM-1648 and ISM-1647. Many environments have dormant admin accounts that nobody reviewed because they were never used. Run a dormancy report against directory and platform accounts, then confirm each privileged account has an owner and a revalidation date. Evidence is the disable policy configuration, the report output, and the signed revalidation records.
Jump servers for administration
ML2 requires administrative activity to be routed through jump servers, which is the control ISM-1387 describes. This changes network paths, not only policy, because administrators can no longer reach servers directly from workstations. Map every admin route including vendor access, database tools and cloud consoles, then decide which paths must pass through the jump tier. Evidence is the network diagram, firewall rules that block direct administration, and session recordings from the jump host.
Central log platform as a prerequisite
The 41 controls added over ML1 are heavily weighted toward central logging, log protection and analysis, so a central log platform is a prerequisite rather than an optional tool. Application control, PowerShell, command line, privileged access and MFA events all have to reach it. Confirm sources, retention and integrity before writing any other ML2 control, because each one produces evidence through this platform. Evidence is a source inventory, log integrity settings, and sample queries showing events from each category.
Incident reporting to CISO and ASD
ML2 requires incidents to be reported to the CISO and to ASD, covered by controls such as ISM-1815 and ISM-1906. The reporting path only works if the central logs can detect the incident and the team knows the reporting threshold. Document the path from detection to report, including who decides an event is reportable and the timeframe each step must meet. Evidence is the approved incident procedure, a tabletop exercise record, and examples of logged reports.
Who owns the controls, who prepares the evidence, and who assesses
The entity owns its Essential Eight position at Maturity Level 2. Its own people make the risk decisions, accept residual risk, assign the accountable officers who answer for each strategy, and run the incident process that the Maturity Level 2 controls on incident reporting depend on. A partner can build a logging pipeline, but the entity decides what gets alerted on, who reviews it, and how an incident reaches the CISO and ASD.
- Control ownership: Named owners for each of the eight strategies, with decisions on scope, exceptions and risk acceptance recorded by the entity.
- Privileged access decisions: Approval of which accounts are privileged, who may revalidate them, and when inactive accounts are disabled.
- Incident process: Triage, escalation to the CISO and reporting to ASD, which the entity runs and records.
- Recurring operation: Daily or periodic review of central logs, patch cadence oversight and restore testing, which continue after any partner leaves.
- Procurement and contracts: Written scope, deliverables and data handling terms agreed before work starts.
Before engaging anyone, confirm internally which accountable officer signs off on Maturity Level 2 and who will operate the logging platform after handover.
An implementation partner such as DeployOpen prepares systems, configurations, logging pipelines and evidence inside the entity's own infrastructure, within a fixed written scope. For Maturity Level 2 that typically covers central logging of application control, PowerShell, command line, privileged access and MFA events, protection of event logs, and the evidence that shows each control operates. The partner works on the entity's behalf and does not replace the entity's ownership of the result.
- Configuration and hardening: Phishing-resistant MFA setup, jump server design and privileged account controls, delivered to the scope agreed in writing.
- Logging pipeline: Collection, retention and protection of event logs on a self-hosted open-source platform in the entity's environment.
- Evidence preparation: Records, screenshots, exports and mappings to ISM control IDs that the entity's assessor can test.
- Handover documentation: Runbooks and configuration records so the entity's team can operate the controls.
- Limits: DeployOpen does not issue assessment reports, attestations or certificates, and it does not decide what the entity's maturity is.
Check that the written scope names the ISM controls covered, the systems in scope and who receives the evidence files.
The independent assessor tests whether each strategy is implemented and effective against the maturity model, using the ISM baseline profiles as the reference. The assessor samples evidence, observes configurations and reaches its own findings. Only an independent assessor issues the findings or report that the entity relies on. Because there is no Essential Eight certificate, the entity should be clear with the assessor about what the report will and will not state.
- Independence: The assessor should not have designed or built the controls it tests, so that its findings carry weight.
- Testing approach: Assessment of both implementation and effectiveness for each strategy, against the ISM Essential Eight profiles.
- Evidence requests: Logs, configuration exports and restore test records supplied by the entity or its partner, which the assessor verifies directly.
- Findings: Written findings issued by the assessor, which the entity uses to plan remediation.
- Engagement terms: Scope, sampling approach and report format agreed with the assessor before fieldwork.
Ask the assessor whether it has assessed against the ISM Essential Eight profiles before, and how it will treat evidence produced by a partner.
How an ML2 program moves from gap analysis to assessment
The sequence turns a Maturity Level 2 target into evidence an independent assessor can test, starting with the decisions only the accountable officer can make and ending with an assessor's review of the evidence. Each step has a named output, so the organization can see what is finished before moving on.
Confirm the target level and scope
The accountable officer confirms that Maturity Level 2 is the target for the entity and records which systems, sites, service providers and user populations fall inside the assessment boundary. Your PSPF obligations and any agency-specific direction should be checked here, since they set the target. The output is a signed scope statement that names the accountable officer, the in-scope systems and the owners of each Essential Eight strategy. Nothing else in the program is sized until this statement exists.
Gap-assess each strategy against the ML2 profile
Work through all eight strategies against the ISM Essential Eight ML2 baseline profile, which ASD publishes in OSCAL. Because every ML1 control is also in ML2, the ML1 results carry forward, and the work focuses on the 41 controls that ML2 adds. For each control, record whether it is met, partly met or not met, with the current evidence and the named owner. The output is a gap register that lists every unmet or partly met control, its owner and the evidence still needed.
Close identity and privileged access gaps first
Start remediation with multi-factor authentication and privileged access, because those controls gate most of the others. ML2 requires phishing-resistant MFA for staff on online services and systems, disables privileged access after 45 days of inactivity and after 12 months without revalidation, and requires jump servers for administration. Confirm which authenticators are in use, which accounts hold privilege and how administration traffic is routed. The output is a verified list of privileged accounts, an authenticator inventory and a working jump server path.
Build central logging and log protection
ML2 makes logging central. Build a central log platform that receives application control, PowerShell, command line, privileged access and MFA events, and protects those logs from unauthorized change. Set up timely analysis of internet-facing server logs and a documented path for reporting incidents to the CISO and to ASD. Because the log platform is a prerequisite for much of ML2, it usually runs in parallel with the access work and is often the longest technical dependency. The output is a log source inventory showing each source forwarding to the platform, plus a tested alert path.
Close the remaining strategy gaps
With identity and logging in place, close the remaining gaps across patching, application control, macro restrictions, user application hardening and backups. Each change should be traced back to a control ID in the gap register so the work can be tested later. Keep configuration changes in version control where the platform allows it, so the state at assessment time can be shown. The output is an updated gap register in which each control is marked as implemented, with a reference to the configuration or record that shows it.
Validate evidence before the assessor arrives
Test each control the way an assessor would. Pull samples of log entries, access reviews, patch records, backup restore results and MFA enrollment data, and check that they show the control operating over time rather than at one moment. Fix evidence gaps that come from missing records, not missing controls. The output is an evidence pack indexed to ISM control IDs, with a short note on any control that is implemented but has thin evidence, so the entity can explain it honestly.
Engage an independent assessor
Only once the evidence pack is complete, bring in an independent assessor to test the implementation and effectiveness of each strategy against the ML2 profile. The assessor forms its own view, and the entity owns the outcome and the reporting obligations. Implementation partners can prepare systems and evidence, but they do not issue the assessment conclusion. Ask the assessor to confirm its scope, sampling approach and reporting format before testing begins. The output is the assessor's findings and the entity's response plan for each finding.
Using Microsoft guidance for Microsoft-heavy estates
Microsoft publishes Essential Eight implementation guidance on Microsoft Learn for each of the eight strategies, written for security advisers, assessors, architects and decision makers. Microsoft describes this material as Consumer Guidance, meaning it is meant to be read alongside Microsoft's IRAP assessment reports rather than treated as a standalone compliance statement. For a non-corporate Commonwealth entity under the PGPA Act, Maturity Level 2 is mandatory under section 14.2 of the Protective Security Policy Framework, so the Microsoft pages are a useful starting point for mapping a Microsoft estate to ML2 controls. They do not transfer responsibility. The entity still owns its configuration, its risk decisions and the evidence an assessor will test, and the guidance cannot substitute for that evidence.
The areas where Microsoft guidance touches ML2 most directly are phishing-resistant MFA in Entra ID, privileged access, and application control. For MFA, the entity should confirm which phishing-resistant methods are available in its tenant and which authentication strengths it can enforce for staff accessing online services and systems. For privileged access, the relevant decisions are how administrative accounts are separated, how privileged roles are time-limited through Entra Privileged Identity Management, and how the 45-day inactivity and 12-month revalidation limits are enforced and logged. For application control, the entity must decide between WDAC and AppLocker and confirm that the policy covers the execution paths ML2 requires. Each of these depends on tenant licensing and feature availability, which change over time, so confirm the current position with Microsoft and your reseller before committing to a design.
Before relying on any Microsoft page, the practical check is to trace each ML2 control to a setting in your own tenant and to the log that proves it. Export the configured policies, confirm the events for MFA, privileged access and application control reach your central log platform, and record who reviewed them and when. Where a Microsoft page describes a capability your licence does not include, record that gap as a risk with an owner rather than assuming the control is met. An independent assessor will test your environment, not the guidance, so the evidence pack should show what your estate actually does.
What ML2 costs and who gets paid for each part
This table separates the cost of reaching Maturity Level 2 by who is paid, whether the cost is one-time or recurring, and what moves it up or down. Use it to structure a quote request so each part can be compared on its own terms. No figures are shown, so ask each party for a written scope and fee basis before comparing offers.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Internal staff time | Your own staff (salary cost, not a fee), plus any backfill contractors | Mostly one-time during uplift, then recurring for reviews and log triage | Number of in-scope Commonwealth systems, existing logging maturity, and whether identity and endpoint teams are already staffed |
| Implementation partner for systems and evidence | External partner, paid under a written scope for configuring systems, central logging, privileged access changes and evidence packs | Usually one-time for the uplift, with optional retainers afterwards | Scope of ISM controls covered, number of Microsoft and non-Microsoft platforms, and whether evidence is already collected |
| Logging and identity tooling | Software licensing or subscription vendors, hosting providers, or your own infrastructure budget; self-hosted open-source options carry staff and hosting costs instead | Licences and subscriptions recur; deployment is one-time | Event volume retained, log storage duration, number of phishing-resistant MFA licences, and whether tools are already licensed under existing agreements |
| Independent assessor | Independent assessor engaged by your entity; DeployOpen does not issue assessment reports | Assessment is typically one-time per cycle, with follow-up for findings | Number of entities or systems in scope, evidence readiness, and how many findings need retesting |
| Recurring review and re-assessment | Your staff for ongoing reviews, plus any partner retainer or assessor for re-assessment | Recurring for as long as the entity holds ML2 | Frequency of access reviews, log analysis workload, patch cadence changes, and any change to PSPF reporting expectations |
What makes ML2 more expensive or slower for one entity
Most of the effort in moving to Maturity Level 2 comes from the size and shape of the estate, not from any single control. The cards below cover the factors that expand scope and timelines, and for each one, the scoping or consolidation decision that tends to reduce it.
Estate size and boundary
The number of systems in scope sets the effort for every ML2 control. Each in-scope workstation, server, and cloud workload needs application control, patching, logging, and backup evidence. Define the assessment boundary early, separate systems that process sensitive information from those that do not, and confirm with your assessor which systems the Essential Eight applies to.
Endpoint and server counts
Each endpoint and server needs its own patch cadence, application control policy, and log forwarding. Heterogeneous fleets with legacy operating systems usually cost the most, because unsupported systems must be replaced or isolated before they can meet the patching requirements. Ask for an inventory that separates managed from unmanaged devices before you request a quote.
Identity platform sprawl
Multiple directories, local accounts, and separate MFA systems make phishing-resistant MFA harder to enforce consistently. Consolidating identity into one authoritative directory typically reduces the number of configurations you must document and test. Map every login path to an online service or system before deciding which identity platform will carry ML2 MFA.
Existing SIEM and log coverage
ML2 makes central logging of application control, PowerShell, command line, privileged access, and MFA events a prerequisite. If an existing SIEM already collects these sources, the work is mostly onboarding and retention review. If logs stay on individual hosts, you will need new collection, protected storage, and analysis rules, which is where most of the added time goes.
Privileged account population
The number of administrative accounts drives the work on privileged access controls. ML2 disables privileged access after 45 days of inactivity and requires revalidation within 12 months, and it requires jump servers for administration. A large population of standing administrators, shared accounts, or service accounts with interactive logon takes time to inventory and remediate before evidence can be collected.
Third-party and contractor access
Vendors and contractors who administer systems or hold accounts fall within the same privileged access and MFA requirements as staff. Each external path needs its own jump server route, MFA method, and inactivity rule. Identify every external account and support tunnel early, because agreements with suppliers often take longer to change than technical configuration.
Evidence maturity
Assessors test whether controls operate over time, so ad hoc screenshots rarely suffice. Organizations with recorded patch cycles, change records, and periodic access reviews usually produce evidence faster than those that must create records retrospectively. Confirm with your assessor the form and retention period of evidence they expect before the assessment begins.
Questions Commonwealth teams ask before engaging help on ML2
Is Essential Eight Maturity Level 2 mandatory for Commonwealth entities?
For non-corporate Commonwealth entities subject to the PGPA Act, Maturity Level 2 is a mandatory requirement, and Microsoft Learn ties that requirement to section 14.2 of the Protective Security Policy Framework (PSPF). The obligation comes from the PSPF, not from the Essential Eight itself, which is a set of mitigations rather than a certification scheme. Confirm the exact applicability of the PSPF requirement to your entity with your agency's security adviser or the PSPF guidance, because the scope depends on your entity type and your current reporting obligations. Your internal security team, not an outside partner, decides and attests to the maturity level you report.
How many controls does Maturity Level 2 add over Maturity Level 1?
In the ISM Essential Eight profiles, Maturity Level 2 adds 41 controls on top of Maturity Level 1. The ML1 profile contains 46 controls and the ML2 profile contains 87, and every ML1 control also appears in ML2. Most of the added work is not on the endpoints but in logging, log protection, log analysis and incident reporting, so the count understates the effort for teams that have to build those capabilities from scratch. Use the ASD OSCAL profiles as your working checklist and confirm the control counts against the version your assessor uses, since the profiles are updated over time.
Do we need a central log platform to reach Maturity Level 2?
Yes, in practice a central log platform is a prerequisite for ML2. The level requires central logging of application control, PowerShell, command line, privileged access and MFA events, protection of those event logs, timely analysis of internet-facing server logs, and reporting of incidents to the CISO and ASD. Local event logs on individual machines cannot show that these records are collected, protected and reviewed. Your engineers will need to choose a collection and storage design, set retention, restrict who can alter logs, and define who triages alerts. Open-source, self-hosted log stacks can meet these needs inside your own infrastructure, but you should confirm each capability against your assessor's test expectations before you commit to a design.
Can our in-house team implement Maturity Level 2 without outside help?
Many agencies have the skills in-house, and the decision depends on capacity and gaps rather than on whether the work is possible. Your team has to cover phishing-resistant MFA, privileged access limits, jump servers, log design and incident reporting, and each of these touches identity, endpoints and network teams who may already be stretched. A useful test is whether one person can name the owner, the evidence and the recurring review for each of the 41 added controls. If several answers are missing, an implementation partner can prepare systems, configurations and evidence packs while your staff keep ownership of decisions and sign-off. Ask any partner to show how their scope, deliverables and timeline are written down before work starts.
What cost components should we expect for an ML2 uplift?
The cost of an ML2 uplift has several components, and only some of them are one-time. Expect one-time costs for assessing your current state, designing the logging platform, configuring phishing-resistant MFA, building jump servers, tightening privileged access, and preparing evidence. Recurring costs include log storage and retention, licence renewals where you use commercial tooling, patch and vulnerability scanning cycles, periodic access reviews, backup restore tests and the time your staff spend reviewing alerts. Costs rise with the number of endpoints, the number of systems that hold sensitive data, the age of your current estate and how much of the logging work starts from zero. When you request a quote, ask for the one-time and recurring costs separately, the staff effort assumed, the tools included and the items your own team must provide. No external figure has been supplied for this page, so treat any number in a proposal as something to validate line by line.
Can a consultant or partner certify our entity at Maturity Level 2?
No. The Essential Eight is not a certification scheme, so there is no ASD certificate for a partner to issue. Maturity is evidenced by assessing the implementation and effectiveness of each strategy against the maturity model, and the assessment is performed or accepted under your entity's own governance and assurance arrangements. A DeployOpen engagement prepares systems, controls and evidence for that assessment, but DeployOpen does not issue audit reports, attestations or certifications, and independent assessors remain responsible for their conclusions. Ask any provider to state in writing which deliverables are preparation material and which, if any, are assessor outputs, and confirm the assessment route with your agency before you buy.
How DeployOpen prepares ML2 systems and evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure so that the systems and evidence for Essential Eight Maturity Level 2 are in place for your assessor. We do not issue assessment reports or certificates. The Commonwealth entity owns its controls and the independent assessor forms the maturity conclusion.
How we scope
- We agree a written scope covering which systems, tenants and networks fall within the ML2 controls being addressed.
- Scope documents name the ISM Essential Eight ML2 controls each deliverable is intended to support, for your assessor to review.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and quotes follow from that scope.
How we build
- We deploy a self-hosted central log platform to collect application control, PowerShell, command line, privileged access and MFA events.
- We configure log protection, timely analysis of internet-facing server logs and jump server access for administration within your environment.
- We test privileged access expiry settings, phishing-resistant MFA enrolment and incident reporting paths before handing them to your team.
How we hand over
- We document each configuration, its owner and the evidence it produces, so your assessor can trace each control to a system record.
- We provide runbooks for recurring tasks such as access reviews, 12-month revalidation and log review, owned by your staff.
- We confirm with you which evidence sits in your own GRC tooling and which items need your assessor's review before reliance.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover platform patching, log platform upgrades and periodic re-testing of the controls that changed during uplift.
- Ask us to confirm in the written scope which support tasks are included and which remain with your internal teams.
