TL;DR: Essential 8 patch management is two controls, not one: patch applications and patch operating systems. At ML1, both require patches applied within one month for most vulnerabilities and within two weeks when a working exploit exists. ML2 adds automated scanning and centralised reporting. ML3 tightens critical patches to within 48 hours. Microsoft 365 environments can satisfy ML1 and ML2 using Windows Update for Business, Intune, and Microsoft Defender Vulnerability Management.
What is Essential 8 patch management?
Essential 8 patch management refers to two distinct mitigation strategies defined by the Australian Signals Directorate's Australian Cyber Security Centre (ACSC): patch applications and patch operating systems. Both appear in the Essential Eight alongside application control, MFA, and five other strategies.
Treating them as a single control is one of the most common misconceptions among Australian SMBs preparing for assessment. Each has its own scope, its own ACSC-defined timelines, and its own evidence requirements. A business that patches Windows thoroughly but leaves browsers and PDF readers unpatched will pass one control and fail the other.
Why the ACSC separates patch applications from patch operating systems
The two controls address different vulnerability surfaces and different patching mechanisms.
Patch applications covers software running on top of the OS: web browsers (Chrome, Edge, Firefox), email clients (Outlook), PDF viewers (Adobe Reader), productivity suites (Microsoft 365 apps), and any third-party software with a network-facing surface or that handles user content.
Patch operating systems covers the underlying OS: Windows 10, Windows 11, Windows Server editions, and any end-of-life versions in scope.
The ACSC separates them because browser and application exploits are frequently weaponised within days of public disclosure. These applications receive untrusted input from websites, emails, and documents by design. OS patches typically require a reboot and carry broader stability implications, so organisations apply them through a different process and at a different cadence.
Passing one patching control and failing the other means your overall maturity level for the patching domain falls to the lower of the two.
ML1 Essential 8 patching requirements
At Maturity Level One, the ACSC sets the baseline timelines for both patching controls. The requirements per the ACSC Essential Eight Maturity Model are:
For patch applications at ML1:
- Patches for applications where a working exploit exists must be applied within two weeks of release
- Patches for applications without a known exploit must be applied within one month
- Applications no longer supported by the vendor must be removed from the environment
For patch operating systems at ML1:
- Patches for OS where a working exploit exists must be applied within two weeks
- Patches without a known exploit must be applied within one month
- Operating systems no longer supported by the vendor must be removed or replaced
The one-month window sounds manageable, but it requires a documented process, a mechanism to deploy patches (not just download them), and confirmation that patches landed on every in-scope device. An unpatched laptop that reconnects after sitting offline for three weeks is still a gap.
For Microsoft 365 environments, Windows Update for Business and Microsoft Intune provide the deployment mechanism. Confirming that patches reached every device requires a compliance reporting step that many ML1 implementations overlook.
ML2 Essential 8 patching requirements
ML2 does not change the patching timelines for standard vulnerabilities, but it adds automation and evidence obligations that ML1 does not require.
At ML2, the ACSC requires:
- Patches for exploited vulnerabilities applied within two weeks (matching the ML1 window for this category)
- Patches without a known exploit applied within one month (matching ML1)
- Automated tools used to confirm the patch status of all in-scope devices
- Vulnerability scanning performed at least monthly to identify missing patches
- Patch logs centralised and protected from unauthorised modification or deletion
The meaningful change at ML2 is the shift from process to evidence. Saying "we patch monthly" does not satisfy ML2. The ACSC expects tool output demonstrating that patches were applied within the required window on every in-scope device. Manual patching without centralised reporting fails this requirement outright.
For Microsoft 365 environments, Intune's device compliance reports and Microsoft Defender for Endpoint's vulnerability management module provide the required evidence. A consultant or assessor reviewing ML2 will ask to see these reports, not a description of the patching process.
The centralised logging requirement at ML2 links to broader event log obligations across several of the eight strategies. See the Essential 8 maturity levels guide for how logging obligations build from ML1 through ML3.
ML3 Essential 8 patching requirements
ML3 introduces a 48-hour window for critical patches that rules out weekly patching cycles and most manual patching processes.
At ML3, the ACSC requires:
- Patches for vulnerabilities with a known exploit applied within 48 hours of patch availability
- Patches for vulnerabilities without a known exploit applied within two weeks
- Automated vulnerability scanning continuous, not monthly
- Only supported versions of applications and operating systems permitted anywhere in the environment
The 48-hour requirement is the most operationally demanding aspect of ML3 essential 8 patch management. It requires active monitoring of patch releases from vendors, fast-track testing, and deployment within two days of a critical patch dropping. For Microsoft products deployed broadly, organisations at ML3 often rely on vendor testing confidence rather than in-house compatibility testing to meet the window.
ML3 patching is appropriate for organisations where contracts, agency requirements, or regulatory obligations explicitly demand it. Government entities handling sensitive data and organisations in critical infrastructure are the primary ML3 audience. The operational overhead of near-continuous patching cycles requires dedicated staff or a managed service provider running that function.
Patching tools for Microsoft 365 environments
Australian SMBs on Microsoft 365 can satisfy patch management using Microsoft's own tooling at ML1 and ML2.
Windows Update for Business: Manages Windows 10 and Windows 11 patch deployment, deferral windows, and compliance reporting. Configured through Intune device configuration policies. WUfB handles OS patching with configurable deployment rings that allow staged rollout before organisation-wide deployment.
Microsoft Intune: Manages both OS and application patch deployment across enrolled devices. Provides compliance reports confirming patch status per device, satisfying the ML2 evidence requirement. The Intune device compliance view shows which devices are out of date and by how long.
Microsoft Defender Vulnerability Management: Scans enrolled devices for missing patches across both applications and OS, maps findings to CVEs, and provides a risk-prioritised remediation list. Included in Microsoft 365 Business Premium and higher licences. This satisfies the automated scanning requirements at ML2 and ML3.
Microsoft 365 Apps update channels: Controls when Outlook, Word, Excel, and other Microsoft 365 desktop apps receive updates. The Monthly Enterprise Channel aligns with ML1 timelines; the Current Channel aligns with ML2 and ML3 for Microsoft's own applications.
For third-party applications such as Chrome and Adobe Reader, Intune's Win32 app management can deploy patches, but requires additional configuration beyond the default Microsoft stack.
Four mistakes Australian SMBs make with Essential 8 patch management
Mistake 1: Treating enabled Windows Update as proof of patching. Windows Update being enabled does not mean patches applied within the required window. Devices that are powered off, offline, or in non-compliance will miss updates. ML1 requires confirmation that patches landed, not evidence the mechanism is active.
Mistake 2: Only patching Microsoft products. The patch applications control covers all in-scope applications. Chrome, Adobe Reader, and Java are the most frequently exploited applications in SMB environments and are the ones assessors check first. Leaving these unpatched while keeping Windows current is a common ML1 failure.
Mistake 3: No evidence at ML2. Many organisations complete the patching but produce no time-stamped record that it happened on every device within the required window. An assessor reviewing ML2 compliance will ask for Intune or Defender reports, not process documentation.
Mistake 4: Leaving end-of-life software running. Windows 10 versions past their Microsoft end-of-support date, or Office versions no longer receiving security updates, fail both patch controls regardless of other patching practices. The ACSC is explicit: unsupported software must be removed.
How CYBERWHITE checks Essential 8 patch management compliance
CYBERWHITE's Microsoft 365 compliance scanner connects to your tenant via Microsoft Graph API and reads patch status data from Intune and Microsoft Defender Vulnerability Management. The scan identifies devices out of compliance with ACSC patching windows, flags end-of-life software, and maps findings to the relevant maturity level requirements.
Where Intune policies can be configured automatically, CYBERWHITE's AutoFix engine applies the change through an approval workflow before anything is deployed. CYBERWHITE offers 149 automated remediation actions across Essential 8 and SMB1001 combined. The scanner also checks your SMB1001 patching controls in the same pass, since the two frameworks share significant overlap in this area.
Check your current patching posture using the Essential 8 maturity self-assessment, or see how the full scanner maps your tenant across all eight controls at Essential 8 compliance. For plan details, see /pricing.
Frequently asked questions
What does Essential 8 patch management cover?
It covers two separate controls: patch applications and patch operating systems. Patch applications covers software such as browsers, email clients, and productivity tools. Patch operating systems covers Windows and server OS versions. Both must be satisfied to achieve the claimed maturity level for the patching domain.
What is the ML1 patching window under the Essential Eight?
At ML1, patches for vulnerabilities with a known working exploit must be applied within two weeks of release. Patches without a known exploit must be applied within one month. These timelines apply to both patch applications and patch operating systems. Software no longer supported by the vendor must be removed.
What does ML2 add to Essential 8 patch management?
ML2 requires automated tools to confirm the patch status of all in-scope devices, vulnerability scanning at least monthly, and centralised logs protected from unauthorised modification. The patching timelines match ML1, but the evidence and scanning requirements are substantially stricter. Manual patching without centralised reporting fails ML2.
What is the ML3 patch management requirement under the Essential Eight?
At ML3, patches for vulnerabilities with a known working exploit must be applied within 48 hours of release. Patches without a known exploit must be applied within two weeks. Automated scanning must be continuous, and only supported versions of applications and operating systems are permitted.
Does Essential 8 patching cover all software or only Microsoft apps?
It covers all in-scope applications and operating systems. Browsers (Chrome, Firefox, Edge), PDF readers, Java, and any third-party application with a network-facing surface are all in scope for the patch applications control, regardless of vendor.
What tools satisfy Essential 8 patch management for Microsoft 365?
Windows Update for Business manages OS patching, Microsoft Intune provides deployment and compliance reporting, and Microsoft Defender Vulnerability Management provides automated scanning for ML2 and ML3. Third-party applications require additional tooling such as Intune Win32 app management.
What is the difference between patch applications and patch operating systems in the Essential Eight?
Patch applications covers software running on top of the OS, such as browsers and Microsoft 365 apps. Patch operating systems covers the underlying OS such as Windows 10, Windows 11, and Windows Server. They are separate controls with separate evidence requirements.
Do servers need to be patched to meet Essential 8 requirements?
Yes. Both patch applications and patch operating systems apply to all in-scope systems, including servers. Servers running unsupported OS versions or unpatched applications are a gap assessors will identify.
Can WSUS satisfy Essential 8 patch management?
Windows Server Update Services satisfies the deployment mechanism at ML1. At ML2 and ML3, the automated scanning and centralised reporting requirements are better satisfied by Microsoft Intune and Microsoft Defender Vulnerability Management, which integrate with Microsoft's compliance reporting stack.
Sources: ACSC Essential Eight Maturity Model (cyber.gov.au), ACSC Patch Management guidance (cyber.gov.au), Microsoft Learn Intune documentation (learn.microsoft.com).