Essential Eight implementation roadmap, sequenced by level

How to sequence an Essential Eight implementation roadmap

If a customer, contract or regulator now expects Essential Eight maturity, the roadmap runs in order: Maturity Level One across all eight strategies first, then Maturity Level Two, then Maturity Level Three. The ASD's ISM Essential Eight profiles set the checklist for each step, with 46 controls at ML1, 87 at ML2 and 123 at ML3 in ISM v2026.09.4. Every ML1 control is also in ML2, and all but three ML2 controls carry into ML3, so work done at a lower level is not thrown away when you move up. The organization owns its controls and the decisions behind them. An implementation partner can prepare systems, configurations and evidence against the profiles, but only an independent assessor reports on maturity. Confirm that assessor's scope and independence in writing before work starts.

The sequence changes with your target level and your current state. An organization with no central logging and no restore-tested backups will spend more time on those foundations than one that already has them, and an organization targeting ML2 with weak ML1 patching should fix patch cadences before anything else. Start by loading the ML1 profile into your GRC tooling, which ASD describes as a machine-readable format for tracking implementation, and mark each control as met, partly met or not started. Then schedule the tooling needed for the ML1 patching cadences, including automated asset discovery and vulnerability scanning, before you configure application control or privileged account separation, because those controls depend on knowing what assets and software exist.

Plan ML2 as a logging and phishing-resistant authentication project as much as a hardening exercise. ML2 adds 41 controls over ML1, much of it centralised event logging, log protection and analysis, and incident reporting, so a central log platform should be in place and collecting before you claim ML2 for any strategy. Budget for recurring work from the start: application control rulesets must be validated at least annually from ML2, and Microsoft Office's trusted publisher list at least annually at ML3. Ask any implementer to show how these reviews will be scheduled, evidenced and owned after the project ends, because they recur for as long as the level is held.

The phases from ML1 baseline to ML3 target

The sequence moves from an honest gap picture against the ML1 baseline, through the eight strategies in an order that clears the cheapest visibility gaps first, then adds central logging and phishing-resistant MFA for ML2 and the stricter ML3 controls. Each phase closes with a named artifact that an independent assessor can test.

Establish the current-state gap register
Start by mapping the in-scope estate and each Essential Eight strategy against the ISM Essential Eight ML1 profile, which can be loaded into GRC tooling in OSCAL form. The organization owns the scope decision and the control owners, while the implementation partner records what is in place, partly in place or missing for each control. The output is a gap register with an owner, evidence location and status for every ML1 control, and it is done when the register has been reviewed by the people who run the systems it describes. Confirm with the assessor early which systems they expect to see in scope.
Build the asset inventory and scanning baseline
Patching cannot be measured until the organization knows what it runs. Automated asset discovery and vulnerability scanning come first, because the ML1 patching controls set cadences for discovery at least fortnightly and scanning ranging from daily for online services and internet-facing operating systems to fortnightly for workstation operating systems. The implementation partner deploys self-hosted scanning in the client's own environment and tunes it to the agreed scope. The output is a scanning baseline showing asset coverage, scan schedules and the first set of open findings, and the step closes when scans run on the agreed cadence without manual intervention.
Set patch deadlines and track remediation
Once findings exist, the organization needs deadlines it can defend. ML1 sets 48 hours for vendor-critical or exploited vulnerabilities in online services and internet-facing systems, two weeks for other such vulnerabilities and for common user applications, and one month for workstation and internal server operating systems. The implementation partner configures ticketing or patch workflows so each finding carries its deadline and owner. The output is a remediation tracker with aging reports, and the step closes when the team can show a sample of findings moved from detection to closure within their deadlines.
Close MFA and privileged access gaps
This phase covers multi-factor authentication for online services with sensitive data and dedicated, separated privileged accounts. The organization decides which identity provider and access paths are in scope, and the implementation partner configures MFA enforcement, removes shared or daily-use administrative accounts and records who holds privileged rights. The output is an access tracker listing privileged accounts, their owners, their MFA status and the review date for each. The step is done when an assessor can compare the tracker against directory exports and find them consistent.
Deploy application control and macro restrictions
Application control on workstations and macro blocking carry the most change risk, so they are sequenced after identity and patching are stable. The implementation partner helps the organization define an approved execution set, deploys it in audit mode before enforcement, and configures Microsoft Office macro settings so that macros are blocked from the internet and disabled by default. The output is an approved ruleset with a change log and a macro policy record. Ask the vendor or your environment team to confirm which application control mechanisms your platforms support, since capabilities differ by operating system.
Harden user applications and test backups
User application hardening covers browsers and related software, and the backup strategy closes the ML1 baseline. The implementation partner applies hardening settings, such as blocking Java and advertisements at ML1, and deploys self-hosted backups in the client's infrastructure. Restore testing is the proof point: ML1 requires backups to be restore-tested to a common point in time as part of disaster recovery exercises. The output is a restore test record showing the date, the systems restored, the point in time used and the outcome, and the step closes when the first full restore has been completed and documented.
Add ML2 central logging and phishing-resistant MFA
Moving to ML2 adds 41 controls, much of it centralised event logging, log protection, analysis and incident reporting, so a central log platform must exist before the logging controls can be met. The implementation partner deploys self-hosted log collection and retention in the client's environment and replaces weaker MFA combinations with phishing-resistant methods for staff on online services and systems. The output is a log coverage map and an MFA method inventory, and the step closes when logs from the in-scope systems reach the central platform and MFA records show phishing-resistant methods. Confirm log retention periods with your own regulatory and contractual requirements.
Implement ML3 additions and recurring reviews
ML3 adds 39 controls and replaces 3, including driver and firmware patching, just-in-time administration, Secure Admin Workstations, driver application control and backups that backup administrators cannot modify or delete during retention. Application control rulesets must be validated at least annually from ML2, and Microsoft Office's trusted publisher list at least annually at ML3, so the output is a recurring review calendar. The implementation partner builds the ML3 controls and the review schedule into the tracker, and the step closes when the first annual review has been logged with its evidence. Scope and durations for this phase must be agreed in a written scope before work starts.

What ML1 asks of each strategy and the tooling it needs

Maturity Level One sets a baseline requirement for all eight strategies, and each one needs a different kind of tool or process. The cards below group the ML1 demands by strategy so you can match each one to a platform component, an owner and a recurring check before you start building.

Patch applications

ML1 expects asset discovery at least fortnightly and vulnerability scanning on a cadence that depends on the asset type: daily for online services and internet-facing systems, weekly for common user applications. Patch deadlines are 48 hours for vendor-critical or exploited issues in online services and internet-facing systems, and two weeks for other such issues and common user applications. You need an asset inventory that feeds a scanner, and a ticketing workflow that tracks each deadline. Confirm which of your applications count as online services before you set the scan schedule.

Patch operating systems

ML1 requires internet-facing operating systems to be scanned daily and workstation operating systems fortnightly, with a one-month patch deadline for workstation and internal server operating systems. The practical need is a scanner that covers every host class and an endpoint or configuration management tool that can push updates within those windows. Check that your scanner authenticates to hosts, since unauthenticated scans miss many missing updates.

Multi-factor authentication

At ML1, MFA must cover staff and customers accessing online services that handle sensitive data. The control is about coverage: every such service needs an MFA step, and the identity provider must enforce it rather than relying on each application. Identify the online services that process sensitive data, then confirm which identity provider or single sign-on platform can enforce a second factor on each of them. Phishing-resistant methods are not required at ML1 but become required at ML2.

Restrict administrative privileges

ML1 requires dedicated privileged accounts that are separate from everyday user accounts, with privileged access validated and limited to those who need it. The tooling need is an identity directory that can create, group and audit admin accounts, plus a record of who holds elevated rights. Ask whether your directory can report privileged group membership on demand, because an assessor will ask for that list and its review history.

Application control

ML1 requires application control on workstations, which restricts execution to an approved set of programs. The tooling must enforce allow rules at the endpoint, not just report on them, and the approved set must be maintained as software changes. Plan for an initial build period in audit or monitor mode before enforcement, and confirm that your endpoint platform supports workstation policies on every operating system in your fleet.

Restrict Microsoft Office macros

ML1 requires macros to be blocked in Microsoft Office files from the internet and disabled for users who have no business need. The tooling is a group policy or endpoint configuration that sets these rules centrally and reports the effective settings. Confirm the exact policy settings with the current ASD guidance and test them against your Office version, because a setting that works in one build can behave differently in another.

User application hardening

ML1 covers browser hardening, including blocking Java and ads in web browsers, along with the other user application settings in the strategy. The tooling is a centrally managed browser and endpoint policy, and a way to verify that each setting is applied on each device. Confirm which browsers and PDF readers your users run, since each one has its own policy keys and some settings must be set in more than one place.

Regular backups with restore testing

ML1 requires backups to be performed, protected and restore-tested to a common point in time as part of disaster recovery exercises (ISM-1515). Backup software alone does not satisfy the control, so you also need a documented restore test with recorded results. Ask your backup platform for logs of each restore test, and confirm that restored data is checked for consistency, not just that the job reported success.

Why central logging comes before ML2 controls

Moving to Maturity Level Two adds 41 controls, and much of that increase is centralised event logging, log protection, log analysis and incident reporting. A central log platform is therefore a prerequisite, not a later improvement. If logs stay on individual workstations and servers, you cannot show an assessor that events are collected, protected from tampering and reviewed, and an ML2 program stalls at the point where evidence is requested. Before you buy or extend anything, confirm which logging platform your estate already runs, which sources feed it (endpoints, domain controllers, cloud tenants, firewalls and privileged access tooling), how long logs are retained, and who can alter or delete them. Those answers determine whether the work is configuration or a new deployment.

Identity is the second dependency. ML2 requires phishing-resistant multi-factor authentication for staff accessing online services and systems (ISM-1872 and ISM-1682), which rules out the weaker combinations still accepted at ML1. Confirm which identity provider issues your credentials, whether it supports phishing-resistant factors for every population in scope, and whether privileged accounts are covered separately. Identity logs also belong in the central platform, because authentication events are often the first evidence an assessor asks to see.

Some ML2 obligations recur rather than finishing once. Application control rulesets must be validated at least annually from ML2 (ISM-1582), so the review needs an owner, a calendar entry and a record of each validation. Treat that task, the log review cycle and the periodic restore tests as operating costs when you plan staffing and any retainer. Ask any implementation partner to show which of these tasks it will hand over and which it will leave with your team.

Which steps stay with your team and which a partner can prepare

Your organization owns the Essential Eight program. Accountability for each mitigation strategy, the risk decisions behind it, and the business trade-offs stay inside your management structure, because no outside party can accept risk on your behalf or know which systems carry the most business impact.

Control ownership: Name an accountable owner for each of the eight strategies and for each ISM control in the ML1, ML2 or ML3 profile you target.
Risk decisions: Decide and record any exceptions, deferred patches or compensating controls, and who signed them.
Patch approvals: Approve change windows for servers, workstations and online services so that deadlines in the model are met without disrupting critical operations.
Business impact: Identify which applications, data sets and recovery time objectives matter most, since these set the order of work and the restore test scope.
Ongoing review: Own the recurring tasks, such as annual application control ruleset validation from ML2, once the work is handed over.

Check that every ISM control in your target profile has a named owner who can explain the control to an assessor without help.

Where Essential Eight programs stall

Most stalled Essential Eight programs fail on sequencing, not on technology. The cards below cover the delays we see most often, each with a practical step that keeps the roadmap moving from Maturity Level One through the higher levels.

Starting ML2 logging before ML1 inventory

Teams often buy a central log platform before they know which assets exist. ML2 logging is only useful when every server, workstation and online service sends events to it, and that depends on an accurate asset inventory built during ML1. Before ingestion starts, reconcile the inventory against directory and cloud account exports, then confirm each asset class has a named log source. Ask the implementation partner to show which log sources are missing from the first sweep.

Unmanaged asset lists breaking scan cadences

Patch cadences in the ML1 profile depend on scanners seeing the full estate. Assets that sit outside the scanner's discovery scope, such as lab hosts or unmanaged cloud accounts, quietly fall out of the patch record. Schedule automated asset discovery at least fortnightly, compare results against the inventory, and treat any asset that has not been scanned within its cadence as an open finding. Confirm that the scanner is reporting on internet-facing systems daily, not just on the internal estate.

Privileged accounts never separated

Many administrators still use one account for email, browsing and domain administration. ML1 requires dedicated privileged accounts that are separated from day-to-day use, and the separation is hard to retrofit once scripts, service jobs and runbooks depend on the shared identity. Map every account with administrative rights, create dedicated admin identities, and move scheduled tasks to them before removing old rights. Record each change so the assessor can trace the privileged population at review time.

Backups never restore-tested

A backup job reporting success does not prove that data can be recovered. The ML1 requirement is a restore test to a common point in time, run as part of a disaster recovery exercise. Programs that skip this step often discover during an incident that their backup sets are incomplete or mutually inconsistent. Schedule a restore test for each critical system, record the point in time restored, and keep the output as evidence. Confirm that the test covers applications and their data together, not only the file store.

Recurring reviews forgotten after assessment

Essential Eight maturity is not a one-time achievement. Application control rulesets must be validated at least annually from ML2, and the Microsoft Office trusted publisher list at least annually at ML3. These tasks are easy to lose once the assessment is closed. Assign an owner to each recurring review, add it to the control calendar with its evidence location, and check the calendar at the start of each quarter. Ask for the review schedule as a standing deliverable in any implementation scope.

Essential Eight roadmap questions buyers ask

How long does each Essential Eight maturity level take to reach?

No supplied source gives a standard duration for reaching Maturity Level 1, 2 or 3, so agree durations in writing against your own scope rather than relying on a generic figure. What drives the timeline is the number of ISM controls you must implement, how many systems and user populations sit in scope, and how much of your estate already has automated patching, central logging and backups in place. The ISM v2026.09.4 profiles contain 46 controls at ML1, 87 at ML2 and 123 at ML3, and ML2 adds 41 controls over ML1, which is the main reason ML2 usually takes longer than ML1. Ask any partner for a phased plan with milestones per strategy and a stated assumption for each dependency, such as log platform readiness or identity provider changes.

Can our own team implement the Essential Eight without a partner?

Yes, many organizations do this in-house, and nothing in the Essential Eight requires an outside firm. The work is still cross-functional: patching, identity, endpoint management, logging, backup and change control all need owners who can make configuration changes and produce evidence. Use the ISM Essential Eight profiles as your checklist and load them into your GRC tooling so each control has an owner and a status. Bring in outside help where your team lacks capacity or skills, such as testing backup restores, designing a central log platform or preparing evidence for an assessor. Be clear that an implementation partner prepares systems and evidence, while the organization still owns its controls and any independent assessment is performed by an assessor you engage separately.

What does the Essential Eight need from our IT and security staff?

The work needs staff who own each strategy and can act on the results, not just a project manager. Patching needs people who run vulnerability scanning and enforce deadlines, identity staff need to manage MFA and privileged accounts, and endpoint teams need to maintain application control and macro settings. Backup owners must run restore tests, and at ML2 security operations staff must review central logs. Expect recurring effort after the first build: ML2 and ML3 application control rulesets must be validated at least annually from ML2 (ISM-1582), and Microsoft Office trusted publisher lists at least annually at ML3 (ISM-1676). Ask any provider how much of that effort they would take over and how much stays with your staff.

Which maturity level should we target first?

Most organizations start with Maturity Level 1, because the ML2 and ML3 profiles build on it: every ML1 control also appears in ML2, and all but three ML2 controls also appear in ML3. Starting at ML1 lets you establish asset discovery, vulnerability scanning, patch deadlines, MFA, dedicated privileged accounts, macro blocking and tested backups before you add central logging and phishing-resistant MFA. Your target may be set by a requirement you already face, such as a PSPF or CIRMP obligation, so confirm which level applies before planning. If you set ML2 or ML3 as the target, plan the central log platform early, since ML2 treats it as a prerequisite and it touches many other controls.

What recurring tasks follow once we reach a maturity level?

Reaching a level is not the end, because several controls repeat on a schedule. Vulnerability scanning must keep running at the cadences set for each asset type, and patch deadlines of 48 hours, two weeks or one month apply to the relevant categories at ML1. Backups must be restore-tested to a common point in time as part of disaster recovery exercises at every maturity level (ISM-1515). From ML2, application control rulesets need annual validation (ISM-1582), and at ML3 Microsoft Office trusted publisher lists need annual review (ISM-1676). Build these into a calendar with named owners and keep the evidence each run produces, since assessors will ask for proof of the most recent cycle.

Can a partner issue an Essential Eight certificate for us?

No. The Essential Eight is a set of mitigation strategies, not a certification scheme, so there is no ASD certificate to obtain from a partner, an auditor or anyone else. Maturity is shown through assessment of each strategy's implementation and effectiveness against the maturity model, and the organization owns the result. DeployOpen can plan, implement, harden and document the systems and evidence that support an assessment, but it does not issue audit reports, attestations or certifications. Ask any provider to state this in writing, and confirm with your regulator or contracting body what form of assessment or evidence they accept.

How DeployOpen scopes and prepares Essential Eight evidence

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, so the Essential Eight roadmap is built on the systems that will produce the evidence. We agree a written scope first, then build, document and hand over each strategy against the ISM profile your assessor will test.

How we scope

Confirm the target maturity level and the systems in each of the eight strategies before any work starts.
Map current tooling, cloud accounts, identity services and backup estate to the ML1 control list in the ISM profile.
Agree deliverables, timelines and exclusions in writing, since most engagements are fixed-scope.
Ask for a quote that separates platform work from any independent assessment you commission separately.

How we build

Deploy scanning, central logging and backup platforms in your environment, sized to your asset and log volumes.
Configure application control rulesets, privileged account separation and MFA scope against documented baselines.
Test patch cadences, deadline reporting and backup restores, keeping the results as dated evidence.
Load the ISM OSCAL profiles into your GRC tooling so each control links to its implementing system.

How we hand over

Document configurations, owners and recurring tasks such as annual application control ruleset validation.
Deliver evidence packs that show each strategy's implementation and its test results, organized by control ID.
Walk your internal team through the runbooks so operations continue without DeployOpen on site.
Record which findings remain open and which items need your own policy decisions or sign-off.

How we support

Keep platforms current with upgrades, backups and hardening reviews under an ongoing support arrangement.
Offer retainers for continuous vulnerability scanning and periodic restore testing if your team needs them.
Re-run evidence collection before your assessor visits, so the packs reflect the current state of systems.
Remember that only your independent assessor can issue an assessment outcome, and DeployOpen does not certify maturity.

Essential Eight implementation roadmap