Essential Eight ML3 patch operating systems: requirements

What Essential Eight ML3 operating system patching requires

If you are preparing for an ML3 assessment or redesigning patch operations, the core change is this: at Maturity Level Three, operating system patches classed as vendor-critical or exploited must be applied within 48 hours, and the same discipline extends to drivers and firmware. Non-critical operating system patches still have a one-month deadline. At ML2 the flat one-month deadline applied to everything, so the new requirement is a fast lane for the items that matter most. The underlying risk is simple. Adversaries study published flaws and begin exploiting them quickly, often before a monthly patch cycle has even reached most workstations and servers. A deadline measured in weeks leaves a window that a targeted attacker can use.

Meeting the 48-hour deadline is hard for reasons that have little to do with the patch itself. The first problem is inventory. If you cannot say which workstations, non-internet-facing servers and network devices exist, or which operating system build each one runs, you cannot prove a deadline was met for any of them. The second is maintenance windows. Critical fixes often need a reboot, and a process designed around monthly change windows will miss a 48-hour clock unless emergency change approval is defined in advance. The third is firmware and drivers. Vendor firmware is often outside the reach of the scanners and agents used for operating systems, so the scan that proves compliance may simply not see the device.

Start with three checks. Confirm that your asset register covers every in-scope device with its operating system and version, and that it is refreshed automatically rather than by spreadsheet. Confirm that your scanner actually reports driver and firmware versions, not only operating system packages, and run it against a sample of network devices to test that claim. Finally, document an emergency change path that allows a critical patch to go out inside 48 hours, and rehearse it once. Confirm with your assessor which evidence they will accept for the deadline, such as scan timestamps, change records and patch deployment logs, and confirm details of ML3 scanning frequency and the current ISM control mapping against the ASD Information Security Manual OSCAL catalog before you finalize the design.

Which systems and teams Essential Eight ML3 patching covers

Essential Eight ML3 operating system patching applies to several populations at once, each with its own deadline and owner. The cards below separate the populations so that scoping, deadlines and accountability can be agreed before the first patch cycle starts.

Workstations in scope

Workstations take the one-month deadline unless a patch is vendor-critical or exploited, in which case the 48-hour rule applies. Endpoint teams own this population, and it is usually the largest by count. Check that the asset register separates laptops that roam outside the corporate network from desktops that never leave it, since the scanning and deployment paths often differ. Confirm which operating system builds are in the fleet and whether any fall outside vendor support, because unsupported systems must be replaced rather than patched.

Non-internet-facing servers

Servers that are not internet-facing fall under the same 48-hour and one-month split as workstations. Server teams should confirm which hosts are internet-facing by reviewing published services, reverse proxies and cloud security groups, because that classification determines which deadline and which scanning cadence apply. Internal servers that accept connections from partner networks need a documented position. Change windows for production hosts are the usual source of missed deadlines, so agree emergency change paths in advance.

Network devices

Network devices such as routers, switches and firewalls appear in the same ML3 deadline structure as workstations and servers. Network teams often own their own patch cycles and vendor advisories, so the central patch register needs to capture them explicitly. Confirm which devices are internet-facing, since edge firewalls and VPN concentrators are typically treated as exposed. Many devices run firmware rather than a conventional operating system, so the scope decision for firmware affects this population directly.

Drivers and firmware

At ML3, drivers and firmware follow the same 48-hour and one-month deadlines as operating system patches, and a vulnerability scanner must check them for missing patches at least fortnightly. This population is the one most often left out of inventory, so confirm that firmware versions for servers, endpoints, storage and network hardware are recorded, not only the operating system. Agree with the hardware owner who receives vendor advisories and who approves firmware rollouts.

Operating systems in use

ML3 requires that operating systems be the latest release or the previous release. Platform owners should list every operating system family and release in use, mark those that are out of support, and plan replacements. Because release currency is a condition on the whole estate, a single legacy image can fail the assessment for the population it covers. Record the release dates and support end dates in the inventory so that an assessor can trace each system to a compliant release.

Owners and the change board

Endpoint, server and network teams each patch their own populations, but the change board decides when emergency patches bypass normal approval and who signs off scope exceptions. Document the owner for each population, the escalation path for a vendor-critical advisory, and the record kept for each exception. Assessors look for evidence that deadlines are tracked against these owners, so a clear RACI for patching is part of the evidence, not an administrative extra.

How an assessor tests Essential Eight ML3 operating system patching

This table sets out each test an assessor typically runs for ML3 operating system patching, the evidence requested and the findings that most often appear. Read it as a checklist: if your evidence cannot answer the question in the middle column, expect that row to become a finding.

Test area	What the assessor checks	Evidence requested and common findings
Patch policy and deadlines	The written policy sets 48 hours for vendor-critical or exploited operating system patches and one month for others, on workstations, non-internet-facing servers and network devices (ISM-1696, ISM-1902).	Evidence: approved policy, change records showing the deadline applied. Common finding: policy still states a flat one month deadline from ML2 (ISM-1695).
Vulnerability scan coverage	Scan results include workstations, non-internet-facing servers and network devices, with each population listed in the scope.	Evidence: scanner asset list reconciled to the CMDB or inventory. Common finding: network devices or branch systems missing from scan scope.
Driver and firmware scan scope	Drivers and firmware are checked for missing patches at least fortnightly (ISM-1703, ISM-1900).	Evidence: scanner configuration and scan history for driver and firmware checks. Common finding: firmware not in scan scope because the scanner only reads operating system packages.
Sample: disclosure to installation	For a sample of critical items, the assessor compares the vendor or exploit disclosure date with the installation date on each system.	Evidence: vendor advisory dates, deployment records and installation timestamps per host. Common finding: installs complete within the window on most hosts but not on a subset that was excluded from deployment rings.
Driver and firmware patch deadlines	Driver and firmware patches meet the same 48 hour and one month deadlines as operating system patches (ISM-1879, ISM-1697, ISM-1903, ISM-1904).	Evidence: patch records for drivers and firmware with dates. Common finding: firmware updates handled under a separate hardware process without deadline tracking.
Exceptions and risk acceptance	Each missed deadline has a documented exception, an owner, a compensating control and an approval by an accountable officer.	Evidence: exception register with approvals and expiry dates. Common finding: exceptions without approval or with no end date.
Operating system release currency	Systems run the latest or previous operating system release, as ISM-1407 requires at ML3.	Evidence: installed release versions per host from inventory. Common finding: unsupported releases still in service, or hosts on a release two versions behind with no recorded exception.

Sequence for moving operating system patching to ML3

This sequence takes an organization from an unverified asset list to ML3 operating system patching, where critical and exploited flaws are fixed within 48 hours and everything else within one month. Each step produces a record that an assessor can test, so the level is proven by evidence rather than asserted.

Build an authoritative asset and software inventory
The IT asset owner builds one register of every workstation, non-internet-facing server and network device in scope, with operating system, build, driver and firmware versions and the responsible person for each. Automated discovery can feed the register from agents, but someone must reconcile it against procurement and network records so that unmanaged endpoints do not drop out of scope. The step is done when the register can answer which systems run which operating system version, and the owner signs off that gaps are closed. Agent-based tools such as Wazuh, Fleet, GLPI or Zabbix can populate much of this, but the owner should confirm each tool's coverage for their platforms.
Confirm operating systems are supported and on a current release
The platform team checks each operating system in the register against the vendor's support lifecycle and records whether it is the latest release or the previous one, as ISM-1407 requires at ML3. Systems on unsupported releases go into a dated replacement or isolation plan owned by a named manager, because ML3 cannot be reached with unpatchable software in the estate. The output is a lifecycle table with a status and target date per system, reviewed by the CISO. Confirm current release status directly with each vendor, since release timing changes.
Extend scanning to drivers and firmware fortnightly
The security engineering team configures the vulnerability scanner to check drivers and firmware for missing patches at least once every fortnight, in addition to operating system and application checks. Where a scanner cannot read firmware versions directly, the team records a compensating process, such as vendor advisory tracking against the hardware register. The step closes when a scan report for each scoped device class shows driver and firmware results on a fortnightly schedule, with failures logged. Confirm which device classes your scanner can assess before relying on it.
Define 48-hour and one-month deadlines with a triage rule
The vulnerability management lead writes a triage standard that classifies each operating system, driver and firmware flaw as vendor-critical or exploited, which triggers the 48-hour deadline, or otherwise, which triggers the one-month deadline. The rule should name the sources used to judge exploitation and vendor severity, and who can reclassify an item. The output is an approved standard, signed by the CISO and IT operations, that every scanner ticket references. Test the rule on a sample of recent advisories before approval so that the classification is applied consistently.
Run an emergency change path that meets the 48-hour deadline
The change manager creates a pre-approved emergency change path for vendor-critical and exploited patches, with named approvers who can authorize out-of-cycle deployment outside the normal weekly window. The path covers testing scope, rollback steps and communication to system owners, so the 48-hour clock is not lost to meeting schedules. The step is complete when a tabletop exercise or a live emergency patch produces a timestamped record from triage to deployment and verification. Ask your change advisory process how it records approval and deployment times, since assessors will look for them.
Set up recurring reporting of deadline performance and exceptions
The GRC or security operations lead builds a recurring report that shows, for each reporting period, how many items met the 48-hour and one-month deadlines, which systems are behind, and every formal exception with its approver and expiry date. The report is reviewed by a named management forum, and minutes are kept as evidence of oversight. Once running, this report becomes the primary record an independent assessor samples when testing ML3 operating system patching. Confirm the reporting cadence and retention period with your assessor before fixing the format.

Evidence that passes an Essential Eight ML3 patching review

An assessor testing ML3 operating system patching wants to see that your asset list, scanning, patch timing and exceptions agree with one another. Each artifact below is a record your organization owns and must keep current between assessments, not a document prepared the week before the review.

Current asset inventory export

A dated export of every workstation, server and network device in scope, with operating system version, owner and location. Assessors use it to confirm that the scanner and patch tools cover the same population the policy describes. Check that the export is generated from your inventory system rather than typed into a spreadsheet, and that retired hosts are removed so they do not inflate coverage. Illustrative: a laptop missing from the export but still receiving no updates is the first gap an assessor will find.

Scanner configuration and driver coverage report

The scanner settings and a coverage report showing that drivers and firmware are checked for missing patches, not only the operating system. Record which scan profiles apply to which hosts and which sources feed vulnerability data. Confirm the vulnerability database is current, and if you run an offline copy, keep a record of when it was last refreshed. A report that lists operating systems but omits driver and firmware checks will not satisfy the ML3 requirement.

Scan result history

A run log showing that scans happened at the required cadence over the review period, with timestamps, scope and results for each run. Assessors look for gaps, so a missed run should be explained in the record, not discovered by them. Keep scan outputs for the full period an assessor may sample, and confirm that the history is stored where it cannot be silently overwritten by later scans.

Patch deployment records with timestamps

For each patch, the date the vendor marked it critical or the date it was first seen exploited, set against the date it was deployed to each host. This is the evidence for the 48 hour deadline for vendor-critical or exploited patches and the one month deadline for other patches. Record the reference date you used, because assessors will test whether the clock started when the vendor or exploitation signal appeared. Patch management tool logs usually hold these timestamps, so confirm they are retained long enough.

Approved exception register

A register of every system that cannot meet the patch deadline, with the reason, the compensating controls, the named risk owner, the approval date and a review date. Exceptions should be rare, time-limited and approved by someone with authority to accept the risk. Assessors will read the register against the scan results to check whether any host with overdue patches is missing from it. An empty register across a large estate often raises more questions than a short, well-justified one.

Operating system release record

A register of the operating system release running on each host, showing whether it is the latest or the previous release, plus the support status for each version in use. ML3 requires current releases, so an unsupported or older build needs a documented replacement plan. Update this record whenever a host is upgraded, and tie each release entry back to the inventory export so the two never disagree.

What meeting Essential Eight ML3 patching costs

This table lists the cost components of meeting ML3 operating system, driver and firmware patching, who is paid for each, whether it is one-time or recurring, and what drives it up. Read it as a checklist for building a quote, since no prices are published here and most costs depend on the size and mix of your estate.

Cost component	Who is paid or who carries it	One-time or recurring	Main cost drivers
Scanning and inventory tooling	Software licensing if commercial; engineering time to deploy if open source	Recurring for licenses; one-time for deployment	Number of endpoints, servers and network devices; whether drivers and firmware are in scope
Engineering time for the 48-hour emergency path	Internal platform or security engineers, or an implementation partner for the build	One-time build, recurring tuning	Number of patch sources, change approval rules, and how many systems can be patched without a maintenance window
Driver and firmware scanning coverage	Internal engineers or a partner to map firmware types and hardware vendors into the scanner	One-time mapping, recurring as new hardware arrives	Number of firmware types, hardware vendor mix, and whether vendors publish machine-readable advisories
Change-window and vendor coordination	Internal change managers, system owners and vendor support contracts	Recurring with each critical advisory	Vendor support lifecycles, number of business-critical systems, and how often out-of-band patches arrive
Evidence upkeep	Internal compliance or security staff, with tooling output as the source	Recurring, usually at each review or assessment cycle	Frequency of scan reports, ticket volume for patch deadlines, and how exceptions are recorded
External review or testing	Independent testers or reviewers, paid by the organization	Optional, usually recurring if scheduled	Scope of the review, number of environments tested, and whether it covers the emergency path
Assessor fees if an assessment is commissioned	Independent assessor, paid by the organization	Recurring per assessment cycle	Scope of systems sampled, number of sites, and the assessor's own engagement terms
Open-source platform licensing	No license fee for the open-source tools themselves; infrastructure and support time still apply	Recurring infrastructure and operations time	Hosting footprint, agent deployment effort, and whether internal staff or a partner operates the platform

Open-source tools that can produce ML3 patching evidence

ML3 patching depends on knowing what is installed on every endpoint, which vulnerabilities apply to it, and when each patch landed. The four tools below cover different parts of that chain: vulnerability matching, software inventory, asset records and host inventory. None of them decides whether an organization meets the requirement, and each needs configuration and confirmation before its output can serve as assessment evidence.

Wazuh vulnerability detection

Wazuh (GPL-2.0-only) correlates the software inventory that each agent collects with the Wazuh CTI vulnerability repository, or with a locally hosted offline copy. For ML3 this gives a per-endpoint view of operating system and application vulnerabilities, which supports the 48 hour and one month deadlines. Confirm that the agent inventory covers drivers and firmware, since the operating system and application data alone may not show missing driver or firmware patches. Confirm how often the feed updates and whether the offline copy is kept current in an air-gapped network. Keep dated scan exports as evidence.

Fleet vulnerable software detection

Fleet (MIT) detects vulnerable software on enrolled hosts by matching installed software against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. Its matching across several advisory sources helps show which vulnerabilities apply to each host. The team must confirm which hosts enroll, whether firmware and driver components are visible to the matcher, and how often hosts report. Test the matching against a known patched and unpatched host before relying on its output for deadline reporting.

GLPI Assets inventory

GLPI Assets (GPL-3.0-or-later) records computers, software, network equipment, peripherals and racks. Its native inventory, built into GLPI since version 10, lets the GLPI Agent push hardware and software data automatically. This gives the asset register that ties each vulnerability finding to a named owner, location and device. Confirm that the agent runs on every workstation and server, that network equipment and firmware versions are captured, and that the register is reconciled against scanner output. Record who approves exceptions to the deadlines.

Zabbix host inventory

Zabbix (AGPL-3.0-only) host inventory stores details such as device type, serial number, location and responsible person. These fields can be entered manually or populated automatically from agent items for hardware, operating system and installed package data. For ML3 it helps show which operating system release each host runs, which supports the requirement to use the latest or previous release. Confirm that the agent items collect the operating system version and package data for every monitored host, and that release dates are tracked so the previous release can be identified.

Who does what for ML3 operating system patching

The organization is the only party that can be accountable for ML3 operating system patching. Its leadership must decide what the patching policy says, which deadlines apply to each asset class, who may accept a risk when a patch cannot be applied in time, and which systems are in scope. These decisions cannot be handed to a consultant or a vendor without losing the accountability the Essential Eight depends on. Outside help can prepare the work, but the organization signs off on it.

Policy and deadlines: Set the internal rule for the 48 hour window on vendor-critical or exploited operating system and driver patches, and the one month window for everything else, for workstations, non-internet-facing servers and network devices.
Risk acceptance: Record who approves a deferred patch, the compensating controls, and the review date. An approval that lives only in an email thread will not satisfy an assessor.
Patch decisions: Decide which updates go to which rings, and who can stop a deployment during an incident.
Scope and ownership: Name an owner for each endpoint, server and network device, so that every missing patch has a person responsible for it.

Before engaging any partner or assessor, confirm internally who holds each of these decisions and where the approvals are stored.

Questions buyers ask about Essential Eight ML3 patching

How much more effort does ML3 operating system patching take than ML2?

ML2 and ML3 share the same operating system patching baseline for most endpoints, but ML3 tightens the clock. At ML3, operating system patches for workstations, non-internet-facing servers and network devices must be applied within 48 hours when vendor-critical or exploited, and within one month otherwise. Driver and firmware patches follow the same deadlines, and a vulnerability scanner must check drivers and firmware for missing patches at least fortnightly. The added effort is mostly operational: faster triage, a tested emergency change path, and inventory accurate enough to find every affected device quickly. Confirm the exact control wording against the ISM Essential Eight profile for your target level before scoping.

Can our internal team implement ML3 patching without outside help?

Often yes, if the team already runs a disciplined patch process and has the tooling and time to extend it. The work splits into three parts: an accurate software and hardware inventory, a scanner that covers operating systems, drivers and firmware, and a change process that can deliver 48-hour patches without breaking production. Organizations with mature configuration management usually need less outside support than those where inventory is spread across spreadsheets. Whatever the choice, the organization owns the control and must be able to show the evidence to an assessor. An implementation partner can prepare systems and evidence under a written scope, but it does not assess or certify the result.

How long does it take to build the 48-hour patching track?

The time depends on the size and state of your estate, so no fixed duration is given here. The main variables are how many device types you run, how complete your asset inventory already is, whether your change approvals can be compressed for vendor-critical fixes, and how many drivers and firmware sources you must track. A small, uniform estate with working endpoint management can move quickly, while a heterogeneous estate with unknown assets and manual change control takes longer. Ask any provider to base its timeline on a written assessment of your environment, and to list the milestones and what you must supply at each one.

What drives the cost of consultant help with ML3 patching?

Cost follows the written scope, so the main drivers are the number of systems and device classes in scope, the state of your inventory, the number of platforms that must be integrated, and how much documentation and evidence preparation is requested. One-time costs usually cover assessment, design, integration and hardening. Recurring costs cover scanner operation, patch testing, fortnightly review and evidence collection, which an internal team or a retainer can carry. When requesting a quote, ask for the deliverables, the systems covered, which tasks stay with your staff, what evidence is produced, and whether ongoing support is included. DeployOpen does not publish a price list, and quotes follow from the agreed scope.

Is there an ASD certificate for Essential Eight ML3 compliance?

No. The Essential Eight is a set of mitigation strategies, not a certification scheme, so ASD does not issue a certificate for any maturity level. Maturity is shown by assessing how each strategy is implemented and whether it works against the Essential Eight Maturity Model. Evidence for the operating system patching strategy at ML3 typically includes scan results, patch records against the deadlines, driver and firmware coverage, and records of exceptions. Ask any provider to explain which evidence it will prepare and who will perform the assessment, because only the independent assessor you engage can state a maturity result.

What does the work require from our internal staff?

Your staff keep ownership of the controls and make the decisions that only your organization can make. Typical internal inputs include confirming asset ownership and business criticality, approving emergency change windows for vendor-critical patches, defining which systems are internet-facing, deciding exception and risk acceptance processes, and reviewing scanner findings each fortnight. Engineers also need to test patches on representative devices and roll back when needed. Name a single accountable owner for the 48-hour process and agree on who signs off evidence before the work starts, so that the implementation partner and your teams work from the same written scope.

How DeployOpen prepares ML3 patching and evidence

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, so patch scanning, inventory and evidence for Maturity Level Three run in your environment. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen prepares systems and evidence; the organization owns its controls, and an independent assessor reaches the conclusions.

How we scope

Inventory every workstation, non-internet-facing server, network device, driver and firmware source in the agreed boundary
Record which systems fall under the 48 hour deadline for vendor-critical or exploited patches and which follow the one month deadline
Agree in writing which operating systems are current, previous or unsupported, and how each will be handled
Confirm with your assessor which ISM Essential Eight ML3 controls apply to your environment before design begins

How we build

Deploy a vulnerability scanner that checks operating systems, drivers and firmware for missing patches at the fortnightly cadence ML3 requires
Configure software inventory collection from endpoints and an offline or locally hosted vulnerability data source where your network needs it
Set up tracking that records detection time, assigned owner, patch applied and exceptions against each deadline
Test the scanning and reporting pipeline on a representative subset of systems before rolling it out across the estate

How we hand over

Document scan schedules, deadline rules, exception handling and escalation paths in a runbook your team can operate
Export evidence sets showing scan results, patch timestamps and inventory records for an assessor to sample
Map each operational step to the ISM control IDs in scope so your GRC tracking reflects the implemented controls
Walk your operations and security staff through the handover and confirm ownership of each recurring task

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, agreed separately from the fixed-scope build
Retainers can cover scanner upkeep, vulnerability data updates, and review of deadline breaches before an assessment
Ask any implementation partner to state in writing what the retainer covers, how changes to scope are priced, and who receives the evidence

Patch operating systems maturity level 3