Essential Eight ML1 to ML2 uplift: what changes and what it takes

What moving from Essential Eight ML1 to Level 2 requires

Moving from Maturity Level 1 to Level 2 adds 41 controls in the ISM Essential Eight profiles, and the ML1 set is contained within ML2, so nothing you built for ML1 is discarded. The step that changes the most is central logging: a central log platform is a prerequisite for ML2, because much of the added control set covers centralised event logging, protection of those logs, analysis of internet-facing server logs and incident reporting. If your organization does not yet collect logs centrally, that is the first decision to make, because several other ML2 requirements cannot be evidenced without it.

The effort itself depends on your estate: how many workstations, servers and online services you run, how many accounts hold privileges, whether your identity provider already supports phishing-resistant methods, and how much of your application control is already enforced. Some organizations will find the uplift mostly configuration and evidence work, while others will need new platforms. Confirm the current state of each strategy against the ISM profile before you estimate work. A useful starting point is the Essential Eight maturity model on cyber.gov.au, which sets out the requirements at each level.

Your organization owns its controls and is accountable for whether they work. An implementation partner can prepare systems, configuration and evidence, but only an independent assessor can issue an assessment outcome for the level you claim. Note also that the Essential Eight is a set of mitigations rather than a certification scheme, so there is no ASD certificate for ML2. When a customer or contract asks for ML2, ask them what form of evidence they will accept and who must produce it, and agree that before work starts.

Why central logging is the prerequisite for ML2

Moving to ML2 adds 41 controls in the ISM profiles, and much of that growth is centralised event logging, log protection, log analysis and incident reporting. Logging is usually the longest dependency because other controls produce their evidence into it, so it should be scoped before the other ML2 work is scheduled.

Central collection of key events

ML2 requires application control, PowerShell, command line, privileged access and MFA events to be sent to a central log store rather than left on individual endpoints and servers. The practical decision is which sources feed the platform first, because each one needs an agent, a forwarder or a native export and a parser. Check that timestamps are synchronised across sources, since correlation across privileged access and MFA events depends on it. Confirm the exact event list against ISM-1660, ISM-1623, ISM-1889 and ISM-1509 in your profile.

Protection of event logs

Logs are only useful as evidence if an administrator cannot quietly alter or remove them. At ML2 the central store needs write-once or restricted-write behaviour, separated administrative roles, and integrity checks on archived records. Decide who can read logs, who can change retention, and how access to the log platform is itself logged. Testing this in practice means attempting to delete or edit a recent event as a privileged user and confirming the attempt fails and is recorded, which is a check an assessor will expect to see.

Timely analysis of internet-facing servers

Logs from internet-facing servers must be analysed in a timely way, which means someone or something reviews them and acts on what they show. Define the detection rules, the review cadence and the escalation path before the platform goes live, and record who reviewed what and when. Alerts that no one triages do not satisfy the intent of the control. Confirm the expected review window with your assessor and document it in the procedure, since the requirement is qualitative in the model.

Incident reporting to the CISO and ASD

ML2 requires security incidents to be reported to the CISO and to ASD, so the logging platform has to feed a defined incident process. Map which log-derived alerts become incidents, who classifies them, and what the report to ASD contains. Rehearse the path with a tabletop exercise so the evidence trail from first alert to report exists. Confirm the reporting route and contacts with ASD and your own governance documents, because the procedural detail sits outside the technical profile.

Who is paid for what when moving to ML2

This table compares the four cost components of moving from Maturity Level 1 to Level 2: internal staff time, implementation partner work, central logging and other tooling, and an independent assessor's fee. Each row shows who is paid, whether the cost is one-time or recurring, and what pushes it up, so you can ask suppliers the right questions. The main takeaway is that the ML2 logging platform and the staff time to run it usually cost more over time than the one-off configuration work.

Cost component	Who is paid	One-time or recurring	What drives it up
Internal staff time	Your own employees (identity, endpoint, security operations and application owners)	Mostly one-time during uplift, then recurring for log review and privileged access revalidation	Number of systems in scope, legacy applications, and how many teams must change process
Implementation partner work	External implementation partner, under a written scope	One-time for configuration, documentation and evidence preparation	Breadth of MFA rollout, number of applications needing application control rules, and gaps in existing documentation
Central logging platform	Software vendor (if licensed) or your own staff and infrastructure (if open source)	Recurring for storage, licences or hosting, plus one-time for setup and parsing	Event volume from application control, PowerShell, command line and MFA events, plus log retention periods
Log protection and analysis	Your security operations staff or a managed service provider	Recurring, as logs must be reviewed and analysed on an ongoing basis	Alert volume, number of internet-facing servers and the depth of incident reporting processes
Other tooling for scanning and backups	Vendor (licensed) or your own staff (open source)	Recurring licences or hosting, plus one-time integration	Number of applications to scan fortnightly, backup volume and whether separate backup administrator accounts are needed
Independent assessor's fee	Independent assessor or certification body, only if you commission an assessment	One-time per assessment, repeated when you reassess	Scope of systems reviewed, evidence quality and the number of strategies assessed
Quote and scope documents	Partner or consultant, as a fixed-scope deliverable	One-time	Ambiguous scope, undefined ML2 target systems and missing evidence requirements

How the ML1 to ML2 uplift runs, phase by phase

The uplift moves from a gap assessment against the ML2 profile to an evidenced, independently assessed ML2 position, with each phase handing a defined output to the next. Central logging is the prerequisite that shapes the order of work.

Assess the gap against the ML2 profile
Start by loading the ISM OSCAL Essential Eight ML2 baseline profile and mapping it against current configurations, tooling and documented procedures for all eight strategies. Your internal security team owns the decisions, and an implementation partner can run the mapping if asked. The output is a gap register listing each missing control, its owner, its dependencies and whether it needs a technical change, a process change or both. The step closes when the register has been reviewed and accepted by the control owners.
Design and deploy the central logging platform
Build the central log platform first, because ML2 adds a large set of logging and log protection controls that depend on it. Define which sources feed it, including application control, PowerShell, command line, privileged access and MFA events, then set retention, access and integrity protection for the logs. The output is a working platform receiving events from every in-scope source, with log protection verified and tested. Confirm the detailed event list against the ISM controls before deployment, since the logging requirements are the largest single block of ML2 work.
Change MFA and privileged access
Extend MFA to all privileged and unprivileged users of systems, and move staff to phishing-resistant methods. In parallel, introduce privileged access expiry for 45 days of inactivity and 12 months without revalidation, and route administration through jump servers. Your identity team makes the changes, and the platform team tests them against a pilot group before rollout. The output is an access model where every privileged session passes through a jump server, and each privileged account has a documented expiry and revalidation record in the central log.
Widen application control and harden macros and backups
Extend application control to internet-facing servers and to all locations other than user profiles and temporary folders, then implement Microsoft's recommended application blocklist. Block Office macros from making Win32 API calls, and restrict privileged accounts from reading, modifying or deleting backups belonging to other accounts. The output is an enforced ruleset with a recorded annual validation date, a macro configuration that passes review, and backup permissions confirmed by a test that attempts and fails unauthorized access.
Set up the vulnerability scanning cadence
Introduce fortnightly vulnerability scanning of applications other than office suites, browsers and extensions, email clients, PDF applications and security products. Set a patch process that meets the one-month window for those applications after release. The output is a scheduled scanner, a documented asset list of in-scope applications, and a ticket trail showing scan results and patch dates. Confirm the exact cadence and scope against the ISM controls, since the wording is what an assessor will test.
Collect evidence for each strategy
Gather the artifacts that show each control operates, not only that it was configured. Examples include log samples from the central platform, MFA enrollment reports, access review records, application control validation records, scan reports and backup restore evidence. Organize them by ISM control ID so an assessor can trace each claim to its proof. The output is an evidence index covering all ML2 controls, with the owner, date and location of each item recorded.
Complete internal review before independent assessment
Run an internal review of the evidence index against the ML2 profile, looking for gaps, stale records and controls that work on paper but fail in practice. Correct the findings and rerun the affected tests. The output is a signed internal readiness record, and the decision to request an independent assessment is taken by your organization. The assessor then tests the implementation and issues its own findings, since only an independent assessor can confirm a maturity level.

Who does what: the organization, the partner and the assessor

Your organization owns every Essential Eight control at ML2, including the decisions that no vendor or consultant can make for you. Your security, IT operations and business leadership define which accounts are privileged, who approves exceptions to application control, how long an unused privileged account may stay active, and who receives incident reports under the ML2 requirements. These are accountable choices, and they must be recorded in your own policies and approvals.

Business decisions on privileged access: Name the owners who approve privileged roles, set the access revalidation process, and accept the operational impact of disabling accounts after 45 days of inactivity or 12 months without revalidation.
Approval of changes: Review and approve application control rules, the trusted publisher list, macro settings and patch deadlines before they reach production.
Incident reporting: Decide who in the organization is notified, how the CISO is involved, and how reports reach ASD under your own incident response plan.
Ownership of logs and backups: Confirm who holds the central log platform and backup administration roles, and keep those duties separate from routine administration.
Evidence you keep: Retain approvals, exception records and review sign-offs so an assessor can trace each decision back to a named owner.

Before engaging anyone, confirm that each ML2 control has a named internal owner and a written procedure that your own staff can run.

What usually delays the ML1 to ML2 uplift

Most stalled Essential Eight uplifts trace back to a handful of gaps that were never planned for. The cards below cover the delays we see most often when moving from ML1 to ML2, with a check for each so the work can be scoped before the change window opens.

Starting logging late

ML2 makes central logging a prerequisite, and much of the added control set sits in event collection, log protection and analysis. Teams that begin with application configuration and only then look at a log platform often find their collection gaps block the rest. Confirm early which events must reach the central platform, how long logs are retained, and who can alter them. Check that the platform can receive PowerShell, command line, application control and privileged access events before you change any endpoint policy.

Unmanaged legacy accounts

ML2 disables privileged access after 45 days of inactivity and after 12 months without revalidation. Old service, break-glass and contractor accounts that nobody owns can be disabled on the first expiry cycle, which breaks scheduled jobs and on-call access. Inventory every privileged account, record an owner and a purpose for each, and confirm which ones are interactive. Agree revalidation dates before the first expiry runs so the change does not arrive as an outage.

Unvalidated application control rulesets

Application control at ML2 extends to internet-facing servers and to every location outside user profiles and temporary folders. Rulesets built for workstations often miss server paths, and a blocklist applied without testing can stop line-of-business software. Confirm that Microsoft's recommended blocklist is in place, test rulesets against each server role in audit mode, and document a validation step that runs at least annually. Ask who signs off rule exceptions and where that approval is recorded.

MFA gaps for service and unprivileged users

ML2 extends MFA beyond staff and customers to all privileged and unprivileged users of systems, and requires phishing-resistant methods for staff. Teams often cover interactive staff sign-in and miss shared mailboxes, service accounts used by people, remote access gateways and administrative consoles that still accept passwords alone. Build an inventory of every authentication path into systems, mark which ones are human-used, and plan a phishing-resistant method for each staff path. Record exceptions with a named owner and an end date.

No evidence trail for scanning cadence

ML2 adds fortnightly vulnerability scanning for applications outside the excluded office, browser, email, PDF and security product set, and patching those applications within one month of release. Teams often run scans but keep no record of scan dates, scope or the remediation that followed, so an assessor cannot confirm the cadence. Set up scan scheduling that writes timestamped reports to a retained store, tie each finding to a ticket, and track patch dates against release dates. Confirm the scan scope matches the application inventory.

Questions buyers ask about moving to Essential Eight ML2

How much effort does moving from Essential Eight ML1 to ML2 take?

The effort depends mainly on how far your current controls sit from the ML2 requirements, not on a single fixed number. The ISM profiles add 41 controls when moving from ML1 to ML2, so the work spans all eight strategies rather than one or two. The biggest drivers are the size and age of your estate, how many workstations and servers already run application control, how many administrators hold standing privileges, and whether you already have a central log platform. Ask any partner to base its estimate on a written inventory of your systems and a gap assessment against the ISM ML2 profile, and to show which items it has counted as new work versus existing configuration to verify.

Can our internal team move from ML1 to ML2 without outside help?

Many teams can, provided they have engineers who already run the platforms involved and time to change them. Internal teams usually handle the configuration work well but find the cross-cutting parts harder: central logging, jump server design, privileged access expiry and evidence collection across eight strategies. A useful test is whether someone on your team can explain, for each ML2 control, where the configuration lives, who owns it and what evidence proves it. If those answers are unclear, outside help can prepare systems and evidence, while your staff keep ownership of the controls.

What does the work require from our own staff?

Your staff own the controls, so they must make decisions that no outside party can make for you. These include approving the application allowlist, agreeing privileged access rules, deciding which logs must be retained and who may read them, and accepting risk where a control cannot yet be met. Expect your identity, endpoint, server and security teams to be involved in configuration changes, testing and change approvals. Ask a prospective partner to name which tasks it expects your staff to perform and how many hours of their time each task needs, and treat any answer that leaves this blank as a gap in the scope.

Is a central log platform mandatory for ML2?

Yes, in practice a central log platform is a prerequisite for ML2. The ML2 requirements add central logging of application control, PowerShell, command line, privileged access and MFA events, along with protection of event logs, timely analysis of logs from internet-facing servers and incident reporting to the CISO and ASD. Doing this from individual machines is not a reliable way to meet those requirements. Your platform must collect the required events, protect them from modification and support analysis within the timeframes your own ML2 mapping sets. Confirm the exact event sources and retention needs with the ISM ML2 profile before choosing a product, since the choice of tool does not remove the obligation.

Is ML2 an ASD certificate?

No. The Essential Eight is a set of mitigation strategies, not a certification scheme, and ASD does not issue an ASD certificate for ML2. Maturity is shown through assessment of how each strategy is implemented and how well it works against the maturity model. Your organization can say it has reached ML2 only if its assessment supports that conclusion. Be wary of any provider that offers an ASD certificate or badge for ML2, because no such document exists in the framework.

How does the independent assessor's role differ from the partner's role?

The partner prepares your systems, configurations and evidence so that they match the ML2 requirements. An independent assessor tests whether those controls are implemented and effective, then reaches its own conclusion. DeployOpen prepares systems and evidence for assessments and does not issue audit reports, attestations or certifications. Your organization remains responsible for its controls, and the assessor's findings decide what you can claim. Keep the two roles separate in your contracts so that the party that built a control is not the party that signs off on it.

How should we scope a fixed-scope Essential Eight engagement?

A fixed-scope engagement starts with a written definition of what is in and out before any work begins. Define the target level, the systems in scope by category (workstations, servers, cloud tenants, backup platforms), the strategies covered, the deliverables such as configurations, runbooks and evidence packs, and the acceptance criteria. Also state which ML2 items are owned by your staff and which are handled by the partner, and what happens if discovery shows additional systems. Request a written scope and a quote that follows from it, and check that each in-scope item maps to a named ISM control in the ML2 profile.

How to choose a partner or assessor for the ML2 uplift

Moving from ML1 to ML2 means a partner touches logging, MFA, privileged access and application control at once, so the contract matters as much as the technology. These four checks separate who does the work, who owns the evidence and who issues the outcome. Settle them in writing before any system change begins.

Confirm assessor independence

Ask who will assess or advise you, and whether they are independent of the systems they help build. A firm that configures your central logging and then tests it has a conflict that an assessor will notice. Ask for named people with prior Essential Eight work against ASD's maturity model, including ML2 logging, MFA and privileged access. Request references you can verify with your own risk team.

Get the scope in writing

Request a written scope before any work starts. It should name the in-scope systems, the eight strategies and ML2 control set you are targeting, the environments covered (cloud accounts, data centers, air-gapped networks), and each deliverable with its acceptance test. Fixed-scope agreements with named deliverables make cost comparable between bids. Also confirm what happens to findings that are out of scope and whether retesting is included.

Split evidence ownership

Agree a responsibility matrix that lists each artifact, its owner and its retention location. A partner may configure central logging, prepare the MFA enrollment report or draft the application control ruleset, but your organization must own the approvals, the access review sign-offs and the evidence that controls ran over time. Assessors test operation, so a snapshot prepared by a consultant does not replace your own records.

Keep the outcome with the assessor

Confirm in writing that the partner will not issue the assessment outcome or state your maturity level. The Essential Eight is a set of mitigations with no ASD certificate, so the maturity outcome is a judgment an assessor reaches by testing each strategy's implementation and effectiveness against the model. That keeps the party that prepares evidence separate from the party that judges it. Ask how the partner responds when an assessor raises findings, and who pays to fix them.

How DeployOpen prepares ML2 systems and evidence

DeployOpen works on the move from Essential Eight Maturity Level 1 to Level 2 as an implementation partner. We prepare systems, controls and evidence inside your own infrastructure, while your organization owns its controls and an independent assessor decides the maturity result.

How we scope

Agree in writing which of the eight strategies and which ISM controls in the ML2 profile fall inside the engagement.
Map current state for MFA, central logging, privileged access, application control, macros, backups and application scanning.
Confirm the target systems, cloud accounts or networks in scope, and the assessor who will test the result.

How we build

Deploy a self-hosted central log platform first, since ML2 logging depends on it for application control, PowerShell and privileged events.
Configure phishing-resistant MFA for staff, privileged access expiry and jump servers within your existing identity and network setup.
Extend application control to internet-facing servers and validate rulesets, then test scanning cadences for applications outside the office suite list.

How we hand over

Deliver configuration records, test results and evidence mapped to each ML2 control so your assessor can trace requirements to proof.
Document the incident reporting path to your CISO and the access restrictions placed on backups for privileged accounts.
Run a handover session with your security and IT teams covering who performs each recurring task after the engagement ends.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work is accepted.
Provide a written quote that follows from the agreed scope, with deliverables and timelines fixed before work starts.
Ask your independent assessor to confirm the ML2 result, since DeployOpen prepares evidence but does not issue assessment reports.

Moving from Essential Eight Maturity Level 1 to Level 2