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

Moving from Essential Eight Maturity Level 2 to Level 3: what changes first

If a contract, regulator or board has set ML3 as the target, the first fact to hold onto is that ML3 adds 39 controls and replaces 3 relative to ML2 in the ISM v2026.09.4 Essential Eight profiles. Your organization owns every control and its evidence, and only an independent assessor reaches a conclusion on maturity. The count is a starting point for scoping, not a measure of effort, because the work depends on your environment: how many internal servers and workstations you run, whether your drivers and firmware are inventoried, how many systems are on operating system releases that are no longer current, and how privileged access is granted today.

Start by sorting the 42 additions and replacements into the work they touch. Patching changes are often the first to be felt: the 48 hour target for critical vulnerabilities on workstations and internal servers, and the fortnightly scanning and patching of drivers and firmware, need an asset inventory that can actually show coverage. Privileged access changes (just-in-time administration, Secure Admin Workstations, and credential protection) usually require redesigning admin accounts before any tooling is chosen. Ask your team to confirm, with an owner for each area, which of these you already meet and which depend on hardware or procurement lead times you do not yet control.

Backups deserve early attention because ML3 requires that backup administrators cannot modify or delete backups during retention, which can change who holds which keys and consoles. Confirm the current backup administrator model and the retention settings before you commit to a design. Also confirm with your assessor, in writing, which evidence they will accept for each ML3 control, since the ISM OSCAL profiles in the ASD mirror define the control set but your scope boundaries are your own decision.

What makes the ML2 to ML3 uplift more expensive or slower

The effort to reach ML3 depends less on the controls themselves than on the size and state of the estate they apply to. Five drivers tend to decide how long the uplift takes and what it costs, and each one can be reduced before work starts.

Endpoint and server count

ML3 extends timely event log analysis from internet-facing servers to non-internet-facing servers and workstations, and application control applies to all servers. Every added endpoint and server increases the patching, logging and policy work. Ask for an asset count split by workstation, internet-facing server and internal server before any scope is agreed, and confirm which groups already have a managed agent. Reducing the count through decommissioning or consolidation shrinks the work before tooling is bought.

Driver and firmware inventory

ML3 requires drivers and firmware to be patched and scanned on a fortnightly cadence, which most organizations have not done before. If no inventory exists, the first task is discovery across endpoints, servers and network devices, followed by a record of vendor, version and support status for each item. Teams that already maintain a hardware asset register with firmware versions will typically move faster. Confirm whether the vendor publishes firmware advisories in a format the scanner can read.

Legacy applications and operating systems

Legacy line-of-business applications often block application control rules, and older operating system releases fail the requirement to run the latest or previous release. ML3 also requires .NET Framework 3.5 to be disabled or removed. Each blocked application becomes either a vendor upgrade, an isolated system with a documented exception, or a retirement decision. Build an inventory of applications that cannot run under strict control and assign an owner and a replacement date to each one.

Privileged access model

Just-in-time administration, Secure Admin Workstations and Credential Guard change how administrators sign in and where they work. Organizations with standing administrator rights across many systems face the largest redesign, because access must be granted on request and expire. An environment that already uses a directory-based privileged access tool and dedicated admin accounts needs less rework. Ask how many accounts hold standing privileged rights today and which ones depend on shared credentials.

Separate backup administrator credentials

ML3 requires that backup administrators cannot modify or delete backups during their retention period, and that non-administrator accounts cannot reach even their own backups. If backup administration currently uses the same credentials as domain or server administration, separating them is a prerequisite and affects every job, restore process and vendor account. Splitting these roles early also makes the immutability requirement easier to test. Confirm whether the backup platform supports immutable storage and independent administrative roles.

Backups, MFA and logging: the three ML3 changes that touch data

At ML2, backups must be protected from unauthorized change, but backup administrators can still modify or delete them. At ML3, the ISM Essential Eight baseline requires that backup administrator accounts cannot modify or delete backups during their retention period, and that non-administrator accounts cannot access even their own backups. The outcome is that a compromised administrator account cannot destroy the recovery copies. Achieving this usually means a backup platform or storage layer that enforces retention in hardware or software, separate from the credentials that run daily backup jobs.

Separate retention authority: Retention locks must be enforced by a control that the backup administrator cannot override, such as object lock in write-once mode or a separate retention account.
Access restriction on user backups: Non-administrator users must not be able to read backups of their own systems, which affects self-service restore designs.
Restore testing: Immutable copies still need periodic test restores to prove they are usable.
Key and credential custody: Encryption keys and the accounts that manage them need the same separation from backup administration.

Confirm with your backup vendor or storage platform whether it supports true retention locks, how it handles early deletion requests, and who holds the override path.

How an ML2 to ML3 uplift runs from gap analysis to assessment

The sequence turns the ML3 baseline into a funded, tested and evidenced set of changes that an independent assessor can examine. Each phase produces a named artifact, and the organization decides when it moves to the next one.

Scope the uplift against the ML3 profile
The organization, with its security leadership, takes the Essential Eight ML3 baseline profile from ASD's ISM OSCAL release and works out which systems, user groups, administrative accounts and backup platforms fall inside the target boundary. The profile contains 123 ISM controls at ML3, of which 39 are added over ML2 and 3 are replaced, so the scope should list each control by ID and name the owner for each. The output is a signed scope statement with a control list that marks which items are already met, which are new and which are stricter versions of ML2 controls. Confirm the boundary with the assessor before work starts, because a narrow scope cannot later support a broader claim.
Run a gap analysis for each strategy
Working strategy by strategy, the team compares the current state of patching, privileged access, application control, macros, user application hardening and backups against each ML3 requirement. The analysis should examine configuration, not only policy: for example, whether driver inventories exist, whether administrator sessions are logged, and whether backup credentials can delete data. Each gap is recorded with its ISM identifier, the evidence that would prove closure, the systems affected and an estimated effort range agreed with the people who will do the work. The output is a gap register that a steering group can rank and approve, and it is the document that later drives every change ticket.
Design and pilot the changed controls
Before anything reaches production, engineers design the changed controls, such as just-in-time administration, Secure Admin Workstations, Credential Guard and LSA protection, driver application control, and immutable backup storage. Each design is tested in a pilot group that represents the real estate, including at least one example of each server and workstation build. The pilot checks that business applications still run, that privileged workflows remain usable and that logs capture the events the design relies on. The output is a tested design record and a pilot report listing exceptions, rollback steps and the people who approved them.
Roll out changes in controlled waves
The approved designs are deployed to the rest of the scope in waves, with each wave tied to a change record, a rollback plan and a named owner. Patch cadence changes, driver and firmware patching, and operating system currency work are scheduled around maintenance windows and vendor support dates, which the team should confirm for each platform. Access changes are communicated to administrators before they take effect, since loss of standing access is the most visible effect of the uplift. The output is a completed change log that maps each wave to the controls it closed and to the systems it covered.
Collect evidence over a defined operating period
Maturity is judged on whether controls operate over time, not on a single configuration snapshot, so the organization runs the new controls and collects their output for an agreed period. Evidence includes patch and scan reports for internal systems and drivers, just-in-time elevation records, expiry and revalidation logs, log analysis outputs for servers and workstations, MFA records for data repositories and restore test results. The assessor will ask whether the evidence is complete and protected, so log integrity and retention should be confirmed early. The output is an evidence index mapped to each ISM control, with a named source system and a retrieval procedure for every item.
Hand over to an independent assessor
An independent assessor, not DeployOpen and not the implementation team, examines the scope statement, gap register, design records and evidence index, then tests the implementation and its effectiveness against the ML3 requirements. Any finding is returned to the organization, which decides whether to remediate and retest. DeployOpen can prepare systems, controls and evidence for this step, but it does not issue assessment results, reports or certificates, because the Essential Eight is a set of mitigations rather than a certification scheme and maturity is evidenced through assessment. Ask the assessor in advance how they will sample evidence and what format they expect for the final report.

What must be in place before an ML3 assessment

An ML3 assessment tests whether the controls work across the whole estate, not just on a sample of flagship systems. The checks below cover the records and evidence an assessor will ask for first, and each one shows how to test it before the assessor arrives.

Accurate asset inventory with drivers and firmware

ML3 extends patching to drivers and firmware, so the inventory must list them alongside operating systems and applications, with versions and owners. Compare the inventory against a live discovery scan and against vendor-supplied firmware records for a sample of servers and workstations. Any device the scan finds but the inventory lacks is a gap to close before assessment.

Documented patch timelines for critical vulnerabilities

At ML3, critical vulnerabilities on workstations and internal servers must be patched within 48 hours, and drivers and firmware fall under the same discipline. Write the timeline into a patch procedure, then pull patch records from the last quarter and measure the gap between vulnerability disclosure and deployment for each critical item. Where the gap exceeds 48 hours, record the reason and the approved exception.

Privileged access records and just-in-time workflow

Assessors will expect a current register of privileged accounts, the approval path for elevation, and evidence that Secure Admin Workstations and credential protection are in use. Confirm that each standing privileged account has a named owner and a documented reason to exist. Then request an elevation sample and check that the approval, the time window and the revocation are all logged.

Tested immutable backup restores

ML3 requires backups that backup administrators cannot modify or delete during retention, and that non-administrator accounts cannot reach. Show this with the actual configuration: attempt a deletion using a backup administrator credential and confirm it fails. Then perform a restore test from the immutable copy and record the time taken, the data verified and the person who signed off.

Log coverage across all servers and workstations

At ML3, timely log analysis extends from internet-facing servers to every non-internet-facing server and workstation. Compare the log source list against the asset inventory and identify any device that does not forward events. Confirm that the forwarding is protected from tampering and that analysts review the events within the timeframe your own procedure sets.

Gap register mapped to ISM control IDs

Every shortfall should appear in one register with its ISM control ID, the owner, the compensating measure if any, and the date of closure. Use the ML3 profile in ASD's OSCAL release to generate the control list, then mark each control as implemented, partly implemented or open. An assessor reads this register first, so keep the evidence link beside every line.

Who owns each ML3 change

This table compares your team, an implementation partner such as DeployOpen, and the independent assessor across the work of moving from ML2 to ML3. Read each row as a split of responsibility: the organization owns the controls and the conclusion it draws internally, the partner configures systems and prepares evidence, and the assessor alone reaches the conclusion on maturity.

Responsibility	Your organization	Implementation partner	Independent assessor
Owning ML3 controls	Accountable for every ML3 control, including driver patching, just-in-time administration and immutable backups	Advises on control design and documents how it is built, but does not take ownership	Tests whether the control is implemented and operating, without owning it
Configuring 48 hour patching and driver and firmware patching	Approves patch deadlines, maintenance windows and exceptions	Configures scanning, patch pipelines and driver and firmware reporting in your environment	Samples patch records and scan outputs to test timeliness
Configuring just-in-time administration and Secure Admin Workstations	Decides which roles qualify and signs off privileged access policy	Builds the access workflow, admin workstation baseline and credential protection settings	Checks privileged access logs and configuration against the requirement
Configuring immutable backups	Sets retention periods and defines who holds backup administrator rights	Implements immutable storage, retention locks and restricted access settings	Tests that backup administrators cannot modify or delete protected backups
Producing ML3 evidence	Collects, retains and maintains the evidence set, including exports and screenshots	Prepares evidence packs and documents how each evidence item was generated	Reviews evidence for completeness, consistency and reliability before relying on it
Issuing the maturity conclusion	Reports internal readiness and may describe its own target level, but cannot certify maturity	Does not issue reports, attestations or certificates of any kind	Alone reaches the assessment conclusion on whether each strategy meets ML3

Your team, a partner and the assessor: who does what

Your organization owns the Essential Eight position, the target level and every control decision. Accountability for the ML3 outcome stays with your leadership and the people who run your environment, whether or not you bring in outside help. Only your team can confirm which systems are in scope, which risks you accept, and whether a control is working day to day.

Scope and risk decisions: Decide which servers, workstations, data repositories and backup systems fall inside the ML3 boundary, and document any exceptions with a named owner.
Operational ownership: Run patching, privileged access, logging and backup restores after the uplift, since those tasks recur long after a project closes.
Policy and approvals: Approve the policies, exception register and risk acceptances that auditors will ask to see.
Staff time: Assign people from security, infrastructure and application teams to validate changes, because implementation partners cannot make business decisions for you.
Evidence custody: Keep the source records, such as scan exports and access reviews, in systems you control and can produce on request.

Before signing anything, confirm in writing which of these items each partner will hand back to you and who signs off on each one.

Questions buyers ask about the ML2 to ML3 move

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

The effort depends mostly on how far your current environment is from the ML3 baseline, not on the number of controls alone. The ISM Essential Eight profiles add 39 controls at ML3 and replace 3 ML2 controls with stricter versions, so the list is longer, but the hard work sits in a few areas: patching internal systems within 48 hours for critical vulnerabilities, patching and scanning drivers and firmware, introducing just-in-time administration and Secure Admin Workstations, extending log analysis to all servers and workstations, and making backups immutable during retention. Each of these depends on tooling, identity design and operating processes that already exist or do not. Ask for a gap assessment against the ML3 profile before estimating anything, because that gap list is what drives the work.

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

A capable team can do much of the uplift in-house if it already runs a mature patch process, privileged access tooling and a central logging platform. Teams usually struggle where ML3 forces changes across the estate at once, such as application control on all servers with driver control, or privileged access redesign that touches every administrator. Outside help is most useful for the gap assessment, architecture decisions for immutable backups and admin workstations, and independent review of evidence before an assessment. An implementation partner prepares systems and evidence, but the organization owns its controls and must run them day to day.

Is ML3 required for our sector or contract?

Whether ML3 is required depends on your sector rules, government arrangements or contract terms, not on the Essential Eight itself, which is a set of mitigations rather than a mandatory scheme. Check the specific instrument that applies to you, such as the Protective Security Policy Framework or any critical infrastructure obligations, and confirm in writing which maturity level, and which assessment evidence, the regulator or customer expects. If your obligations name ML2 today, moving to ML3 may be a business choice rather than a compliance deadline, and that choice should be weighed against the added operating burden.

Do we have to keep ML2 running during the ML3 uplift?

Yes, you should keep the ML2 controls in force throughout the uplift. Every ML1 control is in ML2, and all but three ML2 controls remain in ML3, so ML2 is the floor that ML3 builds on rather than a state you pass through. The three replaced controls (ISM-1691, ISM-1695 and ISM-1873) need careful handling, because the ML3 versions are stricter and changing them can briefly weaken coverage if done carelessly. Plan changes in stages, keep the ML2 evidence current, and avoid switching off existing protections until their replacements are proven.

What should we ask a partner to include in a quote?

Ask for a written scope that lists each ML3 control or control group in the work, the systems covered, and what the partner will deliver for each, such as configuration, documentation, test results or evidence packs. Request a separation of one-time work, like gap assessment, identity redesign and backup architecture, from recurring work, like scanning cadences, privileged access reviews and restore tests. Ask who owns each control after handover, which items the client must provide, what assumptions the timeline depends on, and how changes to scope are priced. DeployOpen agrees scope, deliverables and timelines in writing before work starts and quotes from that scope.

How does an assessor test our ML3 evidence?

An assessor examines whether each strategy is implemented and whether it works, using the maturity model and the ISM Essential Eight profile as the reference. For ML3 that typically means reviewing configuration records, patch and scan reports against the 48 hour and fortnightly cadences, privileged access records, Credential Guard and application control settings, log coverage across servers and workstations, and backup restore tests showing that backup administrators cannot modify or delete backups during retention. Evidence must show operation over time, not only a snapshot. Only the independent assessor issues the assessment outcome, and DeployOpen prepares systems and evidence but does not issue assessments or certificates.

Which parts of the ML3 move are one-time and which recur?

One-time work includes the gap assessment, designing just-in-time administration and Secure Admin Workstations, deploying Credential Guard and LSA protection, building the immutable backup design, and rolling out application control to servers. Recurring work includes fortnightly driver and firmware scanning, keeping 48 hour patch deadlines, reviewing privileged access, running restore tests and maintaining log analysis. Recurring costs are usually the larger share over the life of the level, so ask a partner and your own team to estimate both and to show how the recurring tasks will be staffed or contracted.

How DeployOpen prepares ML3 systems and evidence

DeployOpen works on the ML2 to ML3 move as an implementation partner: we scope the change, build and test the ML3 controls inside your own infrastructure, and hand over the evidence your organization needs. Your organization owns its maturity level, and an independent assessor makes the assessment of it.

How we scope

We agree a written, fixed scope listing which ML3 controls and systems are in and out before work starts.
We map the 39 added controls and 3 replacement controls to your estate, using ASD's ISM Essential Eight profiles.
We confirm with you which internal systems, drivers, data repositories and backup platforms the scope covers.

How we build

We configure patching cadences for critical vulnerabilities on workstations and internal servers, and for drivers and firmware.
We implement just-in-time administration, Secure Admin Workstations and credential protection in your own directory and endpoints.
We build log collection for non-internet-facing servers and workstations, and test that events reach central storage.

How we hand over

We document each implemented control with configuration records, test results and the owner responsible for it.
We run restore tests and immutable backup checks, and record the results in a form your assessor can review.
We deliver a control-to-evidence register so your team and independent assessor can trace each ML3 requirement to proof.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Confirm with us in the written scope which recurring tasks, such as scanning reviews and privileged access revalidation, we will run.
Confirm with your auditor or assessor which evidence formats they accept before we finalize the evidence pack.

Moving from Essential Eight Maturity Level 2 to Level 3