Patch Management for Essential Eight: Timelines, Tools, and What Auditors Actually Check

The Essential Eight doesn't just say "patch your systems." It tells you exactly how fast. And the timelines are aggressive.

Critical vulnerabilities: 48 hours. Internet-facing applications: two weeks. Operating systems on servers exposed to the internet: two weeks. Miss those windows and you fail the assessment. Not eventually. Immediately.

Most Australian businesses aren't close to meeting these timelines. Not because they don't patch. They do. But they patch quarterly, or monthly, or "when IT gets around to it." That doesn't cut it at any maturity level.

This guide covers the actual patching requirements at each maturity level, the tools that help you meet them, and the specific things that trip businesses up during an assessment.

Two Separate Strategies, Not One

The Essential Eight treats patching as two distinct strategies: Patch Applications and Patch Operating Systems. They have different timelines, different scanning requirements, and different rules about end-of-life software. Your auditor will assess them separately.

This trips up a lot of businesses. They set up Windows Update and think patching is handled. It's not. Your operating system patches are one strategy. Chrome, Adobe, Zoom, your accounting software, your CRM. Those are the other strategy. And the other strategy is usually harder.

If you're not familiar with the Essential Eight framework or how the maturity levels work, start there. This post assumes you know the basics.

What Each Maturity Level Requires

The timelines differ based on three things: what you're patching (applications vs operating systems), where it sits (internet-facing vs internal), and how critical the vulnerability is.

Patch Applications

ML3 tightens the core apps deadline to 48 hours (same as online services) and requires running the latest or previous version of all applications. That's a different game entirely.

"Core apps" in the ASD's terminology means office productivity suites, web browsers and extensions, email clients, PDF software, and security products. These are the applications that routinely interact with untrusted content from the internet. They're the highest-risk targets.

Patch Operating Systems

ML3 drops everything to 48 hours and adds drivers and firmware to the patching scope. It also requires you to run the latest or previous release of each operating system.

Notice the split: internet-facing servers have the tightest deadlines. Workstations and internal servers get more breathing room at ML1 and ML2 (one month). This is by design. The ASD prioritises assets that attackers can reach directly from the internet.

Why 48 Hours Matters

Forty-eight hours sounds impossible. It's not comfortable, but it's based on real data about how fast attackers move.

Two real examples show why:

Log4Shell (December 2021). A critical vulnerability in Log4j, a Java logging library used in hundreds of millions of devices. It was publicly disclosed on December 9, 2021. Exploitation started within hours. By December 11, state-sponsored groups from multiple countries were actively using it. The vulnerability had existed unnoticed since 2013 and received the maximum severity score of 10.0 from Apache. Organisations that couldn't patch within 48 hours were exposed for weeks.

MOVEit (May 2023). The Cl0p ransomware group exploited a zero-day SQL injection vulnerability in Progress Software's MOVEit file transfer tool. They started exploiting it on May 27, before anyone knew the vulnerability existed. Progress Software published an advisory on May 31. But by then, Cl0p had already compromised organisations globally and was extracting data. When the patch is available, the clock is already running.

The 48-hour requirement exists because attackers don't wait. The window between "vulnerability is known" and "attackers are exploiting it at scale" has compressed from weeks to hours.

Vulnerability Scanning

You can't patch what you don't know about. The Essential Eight requires automated vulnerability scanning at every maturity level. The frequency depends on what you're scanning.

Daily scanning is required for online services and internet-facing servers across all maturity levels. These are your highest-risk assets.

Weekly scanning covers core applications (browsers, Office, PDF readers, email clients, security products) at all maturity levels.

Fortnightly scanning picks up other applications at ML2 and ML3, plus workstations and internal servers at all levels.

Manual scanning doesn't scale. For a 50-person business with mixed Windows and Mac endpoints, you're looking at dozens of applications across every machine. Automated scanning is the only way to maintain the required cadence.

Common tools for vulnerability scanning include Tenable Nessus, Qualys VMDR, Rapid7 InsightVM, and Defender for Endpoint (which includes Threat and Vulnerability Management). Most of these can double as your scanning and reporting solution for audit evidence.

End-of-Life Software: The Hidden Audit Failure

Every maturity level requires that unsupported software is removed. That means if the vendor has stopped releasing security patches, the software needs to go. No exceptions at ML1 or ML2. ML3 goes further and requires running the latest or previous release.

This catches more businesses than any other patching requirement. Here's why.

Windows 10 reached end of support in October 2025. If you still have Windows 10 machines in your environment, they're receiving no security updates. They fail the Essential Eight at every maturity level. This is the single most common compliance gap I see in assessments right now.

Legacy line-of-business applications. Your industry-specific software, your old accounting package, that Access database from 2009. Many of these applications haven't had a security update in years. If the vendor no longer supports them, they need to be removed, migrated, or isolated with compensating controls and a documented risk acceptance.

Browser plugins and extensions. Java, Silverlight, old PDF plugins. These often linger on machines long after they've reached end of life. A vulnerability scan will flag them, but only if you're scanning.

The fix isn't always removal. Sometimes a critical business process depends on end-of-life software and there's no immediate replacement. In those cases, you isolate the system (dedicated machine, no internet access, restricted network segment), apply compensating controls (enhanced monitoring, limited user access), and document a risk exception with a planned migration timeline. Auditors accept documented, compensated exceptions. They don't accept "we didn't know it was there."

Patching Tools: What Actually Works

This is where it gets practical. Which tools meet the Essential Eight patching requirements and which leave gaps?

WSUS (Windows Server Update Services)

WSUS was the default Windows patching tool for years. It's free and included with Windows Server. But it was deprecated in September 2024. It's still functional and supported through at least 2035, but it won't receive new features.

What it does well: Distributes Windows updates on-premises. Gives you control over which patches get approved. No per-device licensing cost.

Where it falls short for E8: Windows-only. No third-party application patching (Chrome, Adobe, Zoom). No macOS or Linux support. Limited reporting for audit evidence. Requires on-premises infrastructure and manual maintenance. The reporting alone makes it difficult to produce the compliance evidence auditors want.

Intune (with Windows Update for Business)

Cloud-based device management that handles Windows OS patching through Windows Update for Business policies. You configure update rings with deferral periods, enforcement deadlines, and restart schedules.

What it does well: Cloud-managed, no on-premises infrastructure. Configurable update rings with 0-day deferral for security patches and forced installation deadlines. Good reporting through Endpoint Analytics. Covers Windows and macOS.

Where it falls short for E8: Third-party application patching is limited. Winget integration helps but doesn't cover the breadth of applications most businesses run. No Linux support. You'll still need a dedicated third-party patching tool to reach ML2 compliance across all your applications.

Third-Party Patch Management Tools

These fill the gap that WSUS and Intune leave: patching non-Windows, non-Office applications.

NinjaOne is another strong option, particularly for businesses that also need remote monitoring and management (RMM). Pricing runs $4-$8 per device monthly, but it includes help desk, remote access, and backup features alongside patching.

ManageEngine Patch Manager Plus offers a free tier for up to 50 devices, making it attractive for smaller businesses. Cross-platform patching for Windows, macOS, and Linux.

Which Combination Works for E8 Compliance?

For most Australian SMEs already using M365 and Intune, the practical answer is Intune for OS patching + Patch My PC for third-party apps. This gives you:

• Windows and macOS OS patching through Intune update rings
• 900+ third-party applications through Patch My PC
• Unified reporting through Intune for audit evidence
• No on-premises infrastructure to maintain

If you're cross-platform or want a single tool for everything, Automox handles OS and third-party patching across Windows, macOS, and Linux in one agent.

The Hardest Part: Third-Party Applications

Windows patches itself through Windows Update. Office auto-updates through Click-to-Run. Chrome and Edge auto-update in the background. These are the easy ones.

The hard ones are everything else.

Your ERP system. Your accounting software. Your practice management platform. The industry-specific application that only runs on a specific Java version. The tool your finance team installed five years ago that nobody remembers but everyone uses.

These applications cause the most E8 patching failures for three reasons:

1. They don't auto-update. Many line-of-business applications require manual downloads, staged deployments, and sometimes database migrations to update. A Chrome update takes seconds. An ERP update can take a weekend.

2. You don't know what's installed. Without a proper software inventory, you can't patch what you can't see. Most businesses have dozens of applications installed that IT didn't deploy and doesn't manage. Your vulnerability scanner will find them. Better to find them first.

3. Vendor update cycles are slow. Some vendors release security patches quarterly. Some don't have a regular patch cycle at all. If a critical vulnerability drops in their product, your 48-hour clock is running and the vendor might not have a fix yet. In those cases, you need compensating controls: network isolation, access restrictions, enhanced monitoring. Document everything.

What Auditors Actually Check

When an assessor evaluates your patching compliance, they're not just asking "do you patch?" They're looking for evidence across four areas.

1. Patch compliance reports. A snapshot showing what percentage of your devices are fully patched. Anything below 95% for security patches will get flagged. They want to see this from your patch management tool, not a spreadsheet someone put together the week before.

2. Vulnerability scan results. Recent scan results showing known vulnerabilities in your environment. They'll check the scan date (must be within the required frequency), the vulnerability database date (must be current), and what you've done about identified vulnerabilities.

3. Evidence of patching cadence. Logs showing when patches were deployed relative to when they were released. If a critical patch was available on Monday and you deployed it Wednesday, that's within 48 hours. If it took three weeks, that's a finding. The auditor will pull a sample of recent critical patches and check the deployment timestamps.

4. Exception documentation. For systems that can't be patched within the required timeline, documented risk exceptions with: the reason, compensating controls in place, a target remediation date, and management sign-off. A well-documented exception is far better than an undocumented gap.

Building a Patching Process That Actually Works

Tools are half the equation. The other half is process. Here's a practical approach for an SME targeting ML2.

The 48-hour workflow for critical patches: When a critical vulnerability drops, you need a fast-track process. That means: automated alerting (your scanner or vendor advisory), pre-approved deployment to internet-facing systems (no waiting for a change advisory board), and a rollback plan in case the patch breaks something. If you're waiting for Friday's change window to deploy a critical patch, you've already missed the deadline.

Testing vs speed: There's a tension between testing patches and deploying them fast. At ML2, the ASD doesn't mandate formal testing for every patch. But it does require that patches don't break production systems. The practical answer for most SMEs: auto-deploy security patches to a pilot group (10% of devices), wait 4-8 hours for any issues to surface, then push to the rest. This keeps you within the 48-hour window while catching showstoppers.

Is Your Patching Cadence Compliant?

What This Means for Your Cyber Insurance

If you carry cyber insurance, your insurer is already asking about patching cadence. "How fast do you patch critical vulnerabilities?" is on nearly every underwriting questionnaire. If you can answer "within 48 hours for critical, two weeks for everything else" and back it up with reports, that's a better insurance application. If you can't, expect higher premiums or coverage restrictions.

The connection between Essential Eight and cyber insurance goes deeper than patching. But patching is one of the controls insurers check most directly, because unpatched vulnerabilities are one of the most common initial access points in breaches.

Getting Started

Patching isn't glamorous. It's not the security control people want to talk about. But it's one of the two most impactful things you can do (alongside MFA) and it's one of the easiest to measure.

Three things to do this week:

1. Run a vulnerability scan. If you don't have a scanner, Defender for Endpoint (included in Business Premium) has Threat and Vulnerability Management built in. Run it. See what comes back.

2. Check for end-of-life software. Windows 10 machines, legacy applications, unsupported browser plugins. These are automatic failures at every maturity level.

3. Assess your third-party patching. Are Chrome, Adobe, Zoom, and your line-of-business apps being patched automatically? If not, that's your biggest gap.