Essential Eight: what it asks of unsupported software
The Essential Eight asks for removal by class. At ML1 online services, office productivity suites, web browsers and their extensions, email clients, PDF software, Adobe Flash Player and security products that are no longer supported by vendors are removed, and operating systems no longer supported are replaced. ML3 extends removal to every other application. The held ML2 texts carry the ML1 set by reference without restating it, so for a target of ML2 the ML1 wording is cited.
- Scheme
- Essential Eight (ASD)
- When it is placed
- Placed when you say Essential Eight applies to you, at the maturity level you target (1, 2 or 3). Which clause attaches turns on the class of the product: operating systems, the priority application classes, or other applications.
- Held text
- Essential Eight (ASD) on the standards site, read 30 Sep 2026
The held Essential Eight ML2 texts carry the ML1 set by reference ("All ML1 requirements plus"; "the same set of requirements as ML1") and do not restate the removal and replacement wording. For a target of ML2 the ML1 wording is cited and said to be carried into ML2. The Essential Eight Maturity Model ASD is named, not quoted.
Findings that cite it
4 of 10The clauses cited
4 clausesEssential Eight Patch applications ML1Patch Applications
Patch Applications (ML1). An automated method of asset discovery is used at least fortnightly to support detection of assets for subsequent vulnerability scanning. A vulnerability scanner with an up-to-date vulnerability database is used. The scanner runs at least daily for online services and at least weekly for office productivity suites, web browsers and their extensions, email clients, PDF software and security products. Patches or vendor mitigations for online services are applied within 48 hours when critical or working exploits exist, otherwise within two weeks. Patches for office productivity suites, web browsers and their extensions, email clients, PDF software and security products are applied within two weeks of release. Online services that are no longer supported by vendors are removed. Office productivity suites, web browsers and their extensions, email clients, PDF software, Adobe Flash Player, and security products that are no longer supported by vendors are removed.
What an assessor asks to see: Asset discovery tool configuration (Tenable Nessus, Qualys, Rapid7 InsightVM, Microsoft Defender for Endpoint) showing fortnightly scheduled discovery scans; Vulnerability scanner plugin/feed last-updated timestamp evidence; Daily scan schedule and result history for online services (web apps, externally exposed APIs, internet-facing portals); Weekly scan schedule and result history for the in-scope application classes; Patch deployment evidence: tickets, change records or SCCM / Intune / Jamf reports correlating CVE publication date to patch deployment date for each in-scope class; List of online services with EOL/EOS status and decommissioning evidence; Endpoint software inventory showing no Adobe Flash, no unsupported browser versions, no out-of-support PDF readers; Vendor support lifecycle policy with explicit deadlines for replacement
Where software lists usually fall short: Asset discovery cadence longer than fortnightly or run only when changes are requested; Scanner credentialed scanning not configured, only unauthenticated scans, missing internal patch state; Patching SLA met for Microsoft updates but missed for third-party apps (Chrome, Firefox, Adobe, Java, Zoom); Adobe Flash Player still installed on legacy systems; Online services classed differently to ACSC definition, missing daily scan obligation; Critical CVE patched but evidence of decision (critical vs non-critical) not retained
Essential Eight Patch applications ML3Patch Applications
Patch Applications (ML3). All ML2 requirements plus: Patches or vendor mitigations for office productivity suites, web browsers and their extensions, email clients, PDF software and security products are applied within 48 hours of release when vulnerabilities are critical or working exploits exist. Applications other than the priority classes that are no longer supported by vendors are also removed.
What an assessor asks to see: Threat intelligence feed configuration (CISA KEV, MSRC, vendor advisories) integrated with patching workflow; Sample emergency patch tickets showing CVE publication, criticality decision, deployment to fleet within 48 hours; Vendor mitigation register where a patch was not available but mitigation was applied (registry change, configuration change, firewall rule); Asset inventory showing no unsupported applications across the entire application estate; Decommissioning evidence (change tickets, audit logs) for removed legacy applications; Out-of-cycle change board records authorising emergency deployments; Coverage report showing every workstation, server and mobile device received the patch within SLA; Quarterly executive report showing 48-hour SLA compliance percentage
Where software lists usually fall short: 48-hour SLA tracked but not met for remote or roaming workstations; Browser extension patches missed because of dependency on user-driven updates; Vendor mitigation applied but no record kept of when patch supersedes it; Unsupported in-house apps tolerated indefinitely under risk acceptance; Threat intelligence not linked to patch prioritisation; Coverage report incomplete because mobile devices use separate patching tool
Essential Eight Patch operating systems ML1Patch Operating Systems
Patch Operating Systems (ML1). An automated method of asset discovery is used at least fortnightly. A vulnerability scanner with an up-to-date vulnerability database is used. The scanner runs at least daily for operating systems of internet-facing servers and internet-facing network devices, and at least fortnightly for operating systems of workstations, non-internet-facing servers and non-internet-facing network devices. Patches for internet-facing OS and network device vulnerabilities are applied within 48 hours when critical or working exploits exist, otherwise within two weeks. Patches for workstation, non-internet-facing server and network device OS are applied within one month of release. Operating systems that are no longer supported by vendors are replaced.
What an assessor asks to see: Asset discovery configuration and reports showing fortnightly cadence covering servers, workstations and network devices; Authenticated OS vulnerability scan results (Nessus, Qualys, Defender for Endpoint TVM) with last-update timestamp; Daily scan schedule and report for internet-facing servers and network devices (perimeter firewalls, load balancers, VPN concentrators); Fortnightly scan schedule and report for workstations and non-internet-facing infrastructure; Patch deployment evidence (WSUS, SCCM, Intune, Jamf, vendor portals for network devices) with CVE-to-patch timestamps; Network device firmware management evidence (Cisco PSIRT subscription, deployment tickets); Asset register showing no out-of-support OS (e.g. no Windows 7, no Server 2012 R2 past EOL); EOL replacement plan for any in-progress migrations with compensating controls
Where software lists usually fall short: Network devices not in vulnerability scan scope; Internet-facing servers patched in 48 hours but cloud-managed appliances (load balancer firmware) miss SLA; Workstations patched via WSUS but roaming or remote machines miss the one-month window; Non-internet-facing servers patched on quarterly cycle, breaching one-month SLA; Out-of-support OS retained for legacy app without compensating control documented; Asset discovery misses cloud VMs spun up outside the central inventory
Essential Eight Patch operating systems ML3Patch Operating Systems
Patch Operating Systems (ML3). All ML2 requirements plus: A vulnerability scanner is used at least fortnightly to identify missing patches in drivers and in firmware. Patches for drivers and firmware are applied within 48 hours of release when critical or working exploits exist, otherwise within one month. Patches for workstations, non-internet-facing servers and non-internet-facing network device operating systems are applied within 48 hours when critical or working exploits exist (rather than one month). The latest release, or the previous release, of operating systems are used. Operating systems that are no longer supported by vendors are replaced.
What an assessor asks to see: Fortnightly driver and firmware scan results from vendor tools (Dell Command Update, HP Image Assistant, Lenovo Vantage, server iLO/iDRAC, network device vendor advisories); Driver and firmware patch deployment evidence with CVE-to-deployment timestamps within SLA; Emergency patching evidence for non-internet-facing servers and workstations within 48 hours for critical CVEs; OS version inventory confirming all hosts are on the latest or N-1 OS release; Replacement evidence (decommissioning tickets, migration plans) for any out-of-support OS; Threat intelligence to patch workflow link (CISA KEV subscription, vendor PSIRT, ASD alerts); Coverage report for drivers across all hardware models and firmware across UEFI, BIOS, BMC, network device OS; Quarterly executive report showing N or N-1 OS adherence percentage
Where software lists usually fall short: Driver and firmware patching done opportunistically at hardware refresh only; 48-hour SLA met for internet-facing but not internal critical workloads; OS version drift (e.g. Windows 10 22H2 retained alongside Windows 11) with no clear N-1 boundary; Network device firmware lagging due to maintenance window scarcity; Driver vulnerability scanning depends on vendor agent not installed across fleet; EOL OS replacement plan slipped without re-baselining
See the specimen list runCheck your own list