Essential Eight Control 2: Patch Applications Guide

Why application patching is the highest-return Essential Eight control

ACSC Essential Eight Control 2 applies different application patching timeframes according to product category, maturity level, vendor criticality and whether a working exploit exists. Online services can carry a 48-hour window from Maturity Level 1 when the vendor rates a vulnerability critical or a working exploit exists. At Maturity Level 3, the same 48-hour trigger also applies to office productivity suites, browsers and extensions, email clients, PDF applications and security products.

ACSC Essential Eight Control 2 (Patch Applications) addresses this directly. Unlike operating system patching (Control 6), which is typically managed through well-established Windows Update processes, application patching covers a broader, more heterogeneous set of software. Third-party browsers, PDF readers, collaboration tools, and runtimes each have their own update mechanisms, release cadences, and enterprise management integrations. Getting this right at scale requires a structured approach — one that goes well beyond trusting end users to click "Update now."

This guide covers the current requirements at each maturity level, applications in scope, deployment using Intune and WSUS/MECM, vulnerability scanning and evidence for an Essential Eight assessment.

Where this fits: Control 2 is one of eight mitigation strategies. The pillar guide Essential Eight Maturity Level 2 — the 2026 evidence pack covers all eight and how they sequence. To see whether patching is your current gating control, run the free Essential Eight Maturity Assessment.

1. What ACSC Essential Eight Control 2 requires

The ACSC defines Control 2 as: patching or mitigating security vulnerabilities in applications within a defined timeframe proportional to the risk of the vulnerability. The control applies to applications that process content from untrusted sources — primarily internet-facing applications and those capable of opening files received from external parties.

What "applications" means in the ACSC context

The current ACSC Essential Eight Maturity Model (Australian Cyber Security Centre — Essential Eight maturity model, accessed 3 November 2026) distinguishes online services; office productivity suites, browsers and extensions, email clients, PDF applications and security products; and other applications.

• Web browsers — Chrome, Edge, Firefox, and any embedded browser engines (Electron-based apps)
• PDF readers — Adobe Acrobat, Adobe Reader, Foxit PDF Reader, and any application with built-in PDF rendering
• Microsoft Office and Microsoft 365 Apps — Word, Excel, PowerPoint, Outlook, Access, Publisher, Visio
• Java Runtime Environment (JRE) — any version of Oracle or OpenJDK JRE installed on endpoints
• Media players — VLC, Windows Media Player, and other applications that process internet-sourced media files
• Archive tools — WinRAR, 7-Zip, and tools that extract internet-downloaded archives (a common malware delivery mechanism)
• Collaboration and communication tools — Zoom, Microsoft Teams desktop client, Slack, Webex

Control 2 also covers other applications, with requirements that vary by maturity level. Maintain an inventory that includes server software, database client tools and development runtimes where they are present, then apply the relevant category, vulnerability and scanning requirements from the current model.

2. The three maturity levels for Control 2

Each maturity level broadens or tightens parts of the application patching control set. The following summary reflects the current ISM controls included in the Essential Eight profiles.

Maturity Level 1: online services and high-risk application categories

• Online-service vulnerabilities rated critical by the vendor, or with a working exploit, are patched, updated or mitigated within 48 hours (ISM-1876)
• Other online-service vulnerabilities are addressed within two weeks (ISM-1690)
• Office productivity suites, browsers and extensions, email clients, PDF applications and security products are addressed within two weeks (ISM-1691)
• A vulnerability scanner is used at least weekly to identify missing patches in those specified high-risk application categories (ISM-1699)
• Unsupported online services and unsupported products in those specified categories are removed (ISM-1905 and ISM-1704)

Maturity Level 2: add other applications

• All Maturity Level 1 requirements continue to apply
• Applications outside the specified high-risk categories are patched, updated or mitigated within one month (ISM-1693)
• A vulnerability scanner is used at least fortnightly for those other applications (ISM-1700)

Maturity Level 3: critical and exploited high-risk applications move to 48 hours

• Online-service timeframes remain 48 hours for vendor-critical or exploited vulnerabilities and two weeks otherwise (ISM-1876 and ISM-1690)
• Vendor-critical vulnerabilities, or vulnerabilities with working exploits, in office productivity suites, browsers and extensions, email clients, PDF applications and security products are addressed within 48 hours (ISM-1692)
• Non-critical vulnerabilities without a working exploit in those categories are addressed within two weeks (ISM-1901)
• Other applications retain the one-month timeframe, with weekly scanning for the specified high-risk categories and fortnightly scanning for other applications (ISM-1693, ISM-1699 and ISM-1700)

Assessment should verify the effective patch state as well as management reports, so endpoint and service evidence must reconcile with the central records.

A note on severity bands: the ACSC model sets the 48-hour window on whether a working exploit exists (and gives extra weight to internet-facing exposure), not on a CVSS score. CVSS bands such as 7.0-8.9 or 9.0+ are a useful EDUC4TE triage aid for deciding what to tackle first within the required window, but they are our own prioritisation layer — do not present them to an assessor as the ACSC trigger for the timeframes.

3. Most-patched application categories in Australian environments

Web browsers: Chrome, Edge, and Firefox

Browsers process untrusted internet content and receive frequent security updates, so they warrant close attention under Control 2. Enterprise browser management can enforce update policies and provide deployment evidence across managed devices.

Microsoft Edge (Chromium-based) can be managed through Intune or Group Policy using the Microsoft Edge ADMX templates. The Update/AllowEdgeUpdate policy and Update/UpdateDefault policy control whether automatic updates are permitted and whether the update channel is enforced. An ExtensionInstallBlocklist can reduce unmanaged extension risk, but it is a separate hardening measure rather than proof of patching compliance.

Google Chrome enterprise deployments use the Chrome ADMX templates from Google. The AutoUpdateCheckPeriodMinutes policy sets the interval, in minutes, between update checks — lower values mean more frequent checks. For Level 3, set this to a short interval such as 480 (8 hours) so Chrome checks for updates several times a day rather than leaving it at the long default. Avoid setting it to the maximum value, which stretches the interval to weeks. Use the Chrome Browser Cloud Management console for centralised fleet visibility and patch compliance reporting.

Firefox in enterprise environments uses Mozilla's CCK2 (Client Customisation Kit) or the Firefox ESR (Extended Support Release) channel via Group Policy. The ESR channel receives security updates on a predictable schedule with fewer feature changes, which suits change-averse environments.

Microsoft 365 Apps (formerly Office 365 ProPlus)

Microsoft 365 Apps uses a channel-based update model. According to Microsoft documentation (2025), the available channels are:

• Current Channel: Frequent security and feature updates
• Monthly Enterprise Channel: Monthly updates on a fixed schedule (second Tuesday) — suitable for environments requiring change windows
• Semi-Annual Enterprise Channel: Less frequent feature updates; organisations must still deploy applicable security updates within their required control timeframe

Choose an update channel and deployment design that can meet the applicable two-week or 48-hour window. Monthly Enterprise Channel offers a predictable schedule, but a channel name alone does not demonstrate compliance. Configure and verify it through Intune or the Microsoft 365 Apps admin centre Cloud Policy Service.

Adobe Acrobat and Reader

PDF applications are one of the high-risk product categories named in the Essential Eight patching controls. For Adobe Acrobat and Reader, use supported enterprise deployment tooling or deploy through Intune with a detection rule that checks the installed version; set deadlines from the applicable maturity requirement rather than assuming every release follows a fixed monthly cadence.

At Maturity Level 3, consider whether Adobe Reader is strictly necessary on all endpoints or whether the built-in Microsoft Edge PDF renderer (which updates with Edge) is sufficient for most users, reducing the patching surface.

Java Runtime Environment

Legacy applications often pin to specific JRE versions. EDUC4TE recommends the following risk-treatment sequence:

1. Assess whether the pinned JRE version is genuinely required or whether a newer compatible release is available
2. If a legacy JRE version must remain, isolate the application to a segregated network zone (VLAN or virtualised desktop) with no internet access
3. Engage the application vendor to establish a JRE migration timeline — document this formally
4. Remove vulnerable or unsupported JRE installations from general-purpose internet-connected endpoints and confirm any exception with the assessor

Collaboration tools: Zoom, Teams, Slack

Collaboration platforms rose sharply in prevalence from 2020 and now represent a significant patching surface. Microsoft Teams updates automatically when deployed via Microsoft 365 Apps; however, the standalone Teams installer does not auto-update on older deployment models. Zoom has a known history of high-severity CVEs and must be managed via the Zoom Management Portal or MDM policy. Slack desktop clients should be updated via Intune Win32 app deployment with version-based detection rules.

4. Implementation with Microsoft Intune (primary method for Australian SMBs)

Microsoft Intune is one available patch-management platform for organisations using Microsoft 365. The assessment requirement is the control outcome and its evidence, rather than use of a particular vendor tool.

Windows Update for Business policies for Microsoft 365 Apps

Configure update channels via Intune:

1. Navigate to Intune Admin Centre > Apps > Microsoft 365 Apps for Windows
2. Under Configure App Suite, set the Update Channel to "Monthly Enterprise Channel"
3. Assign the policy to an Entra ID group covering all endpoints

For deadline enforcement, align the deployment ring to the applicable control: a routine ring within the two-week or one-month window, and an emergency ring capable of meeting the 48-hour vendor-critical or working-exploit trigger.

Win32 app detection rules for third-party applications

For third-party applications (Chrome, Zoom, Adobe Reader), deploy via Win32 app packages with detection rules based on the installed product version:

1. Package the installer using the Microsoft Win32 Content Prep Tool (IntuneWinAppUtil.exe)
2. Set the Detection Rule as a Registry detection: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{GUID} with the DisplayVersion key checked against the target version
3. Configure a Supersedence rule so the new version automatically replaces the previous package
4. Set the Install Deadline from the product category and trigger: one day is a useful internal target for a 48-hour obligation, while other deadlines must remain inside their two-week or one-month window

Proactive Remediations for patch compliance reporting

Intune Proactive Remediations (now called Remediations in the Intune Admin Centre) allow scheduled PowerShell detection and remediation scripts to run on endpoints and report compliance status back to the console.

# Intune Proactive Remediation: Detection Script
# Purpose: Detect whether Adobe Acrobat Reader DC is patched to the required minimum version
# Minimum version should be updated to the current release before deployment
# Source: Adobe security bulletins at https://helpx.adobe.com/security/products/acrobat.html

$MinimumVersion = [Version]"24.004.20272"   # Update to current required version before deploying
$AppName        = "Adobe Acrobat (64-bit)"  # Adjust for Reader DC if required

# Read installed software from the Uninstall registry keys (both 64-bit and 32-bit views).
# Do NOT use Get-WmiObject/Get-CimInstance -Class Win32_Product: querying that class forces
# the MSI provider to enumerate and run a consistency check (self-repair) on every installed
# package, which is slow and can trigger unwanted reconfiguration across the fleet.
$uninstallKeys = @(
    "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*",
    "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
)

$InstalledApp = Get-ItemProperty -Path $uninstallKeys -ErrorAction SilentlyContinue |
    Where-Object { $_.DisplayName -like "*$AppName*" -and $_.DisplayVersion } |
    Select-Object @{N='Name'; E={ $_.DisplayName }},
                  @{N='Version'; E={ $_.DisplayVersion }} |
    Select-Object -First 1

if ($null -eq $InstalledApp) {
    # Application not found — may be uninstalled or named differently; flag for review
    Write-Output "NOT_FOUND: $AppName not detected on this endpoint"
    exit 1  # Non-compliant: application not inventoried
}

$InstalledVersion = [Version]$InstalledApp.Version

if ($InstalledVersion -ge $MinimumVersion) {
    Write-Output "COMPLIANT: $AppName version $InstalledVersion meets minimum $MinimumVersion"
    exit 0  # Compliant
} else {
    Write-Output "NON_COMPLIANT: $AppName version $InstalledVersion is below minimum $MinimumVersion"
    exit 1  # Non-compliant: triggers remediation script
}

The companion remediation script triggers an Intune app reinstall or a winget upgrade command. Collect the Remediations results report from the Intune admin centre as part of the evidence set, then reconcile it with vulnerability-scan and version-inventory results.

5. Implementation with WSUS and SCCM/MECM (enterprise)

For larger organisations or those with complex on-premises infrastructure, Microsoft Endpoint Configuration Manager (MECM, formerly SCCM) combined with Windows Server Update Services (WSUS) provides more granular patching control.

Software Update Point and third-party patch catalogues

MECM's Software Update Point (SUP) synchronises with WSUS and can ingest third-party patch catalogues for non-Microsoft applications. Configure the following:

1. In the MECM console, navigate to Administration > Site Configuration > Sites > Configure Site Components > Software Update Point

2. Enable Third-party software updates and add catalogues for key vendors:

   • Dell Command Update catalogue (for Dell hardware driver and firmware patches)
   • HP Client Management Script Library catalogue (for HP endpoints)
   • Adobe enterprise catalogue (for Acrobat and Creative Cloud apps)
   • Google Chrome Enterprise catalogue

3. Subscribe to the catalogue and synchronise. Third-party patches then appear in the MECM Software Updates console alongside Microsoft patches.

Automatic Deployment Rules for urgent patching

Create an Automatic Deployment Rule (ADR) for vendor-critical updates, then use threat intelligence and vulnerability management to identify working exploits that also trigger the 48-hour window:

1. Navigate to Software Library > Software Updates > Automatic Deployment Rules
2. Create a new ADR with:
   • Severity filter: Critical
   • Superseded: No (deploy new patches, not superseded ones)
   • Deployment deadline: 1 day after Software available date
   • Restart behaviour: Force restart if required (with appropriate user notification)
3. Create separate rules and deadlines for non-critical updates according to the applicable product category
4. Assign both ADRs to all-endpoints collection, excluding servers (which should use a separate patching window)

MECM ADRs run on a schedule after the Software Update Point synchronises updates. Test an out-of-band path so vendor-critical or exploited vulnerabilities can be deployed within the applicable 48-hour window.

6. Vulnerability scanning to identify unpatched applications

Patch deployment alone is not sufficient — organisations must verify that patches were actually installed and that no new vulnerabilities have emerged since the last patch cycle.

Microsoft Defender Vulnerability Management

Microsoft Defender Vulnerability Management capabilities vary by Defender and Microsoft 365 licence. Confirm the tenant's entitlement before designing the evidence process. Where licensed and onboarded, MDVM inventories installed application versions and maps them to known vulnerabilities.

Key MDVM capabilities for Control 2:

• Software inventory: Lists every application, version, and number of devices with each version across the fleet
• Recommendations: Flags applications with known vulnerabilities and provides the recommended patch version
• Exposure score: Quantifies overall vulnerability exposure, useful for communicating risk posture to executives
• Risk and severity context: MDVM provides vulnerability severity and exposure information for internal prioritisation

Generate a Vulnerable software report at least weekly for the specified high-risk application categories and at least fortnightly for other applications at Maturity Levels 2 and 3. Retain the timestamp and per-device status as part of the evidence set; a report alone does not prove that every applicable control is met.

Tenable Nessus and Qualys (enterprise scanning)

Organisations that require scanning beyond the Microsoft toolset can evaluate products such as Tenable Nessus and Qualys against their authentication, coverage, evidence-export and deployment requirements.

Configure authenticated scanning (using a service account with local administrator rights) to obtain accurate installed application version data. Unauthenticated scanning misses most application-level vulnerabilities and is not acceptable as sole evidence for an ACSC assessment.

CVSS is useful for internal triage, but it does not replace the Essential Eight triggers. Route vendor-critical findings and vulnerabilities with known working exploits into the 48-hour process where the relevant control applies. Generate ITSM tickets for all findings and assign the due date from the product category, maturity level, vendor rating and exploit status.

7. Evidence collection for ACSC audit

An assessor needs evidence that patch management is operating across the assessed scope, not merely configured. Collect the following artefacts routinely and confirm the final evidence request with the assessor.

Application register

Maintain a register of all in-scope applications with:

• Application name and vendor
• Current approved version
• Deployment method (Intune, MECM, manual, auto-update)
• Last patch date and patch source (vendor advisory URL or CVE reference)
• Any exceptions with business justification and risk acceptance sign-off

Intune and MECM patch compliance reports

Export patch compliance reports monthly. Intune's Device compliance report and App install status report show per-device application versions with timestamps. MECM's Software Updates — Compliance report provides similar data for on-premises managed devices. Store these reports in a dated evidence folder (SharePoint or shared drive) accessible to security staff and auditors.

Defender Vulnerability Management asset inventory

# PowerShell: Export MDVM software inventory for audit evidence
# Requires Microsoft Graph API access with DeviceManagementManagedDevices.Read.All permission
# Run in Azure Cloud Shell or from a management workstation with the Graph SDK installed

# Install the Microsoft.Graph module if not present
# Install-Module Microsoft.Graph -Scope CurrentUser

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"

# Retrieve all managed devices and their application compliance status
$Devices = Get-MgDeviceManagementManagedDevice -All

$ComplianceReport = foreach ($Device in $Devices) {
    [PSCustomObject]@{
        DeviceName        = $Device.DeviceName
        LastSyncDateTime  = $Device.LastSyncDateTime
        OSVersion         = $Device.OsVersion
        ComplianceState   = $Device.ComplianceState
        ManagementAgent   = $Device.ManagementAgent
    }
}

$ReportDate  = Get-Date -Format 'yyyy-MM-dd'
$OutputPath  = "C:\AuditEvidence\Intune-DeviceCompliance-$ReportDate.csv"

$ComplianceReport | Export-Csv -Path $OutputPath -NoTypeInformation -Encoding UTF8

Write-Host "Compliance report exported to: $OutputPath"
Write-Host "Total devices: $($ComplianceReport.Count)"
Write-Host "Compliant: $(($ComplianceReport | Where-Object ComplianceState -eq 'compliant').Count)"
Write-Host "Non-compliant: $(($ComplianceReport | Where-Object ComplianceState -eq 'noncompliant').Count)"

Save the output CSV to the audit evidence folder with the date in the filename. For ACSC assessments, also export the MDVM Vulnerable software report and the Security recommendations report from the Microsoft Defender portal (security.microsoft.com > Vulnerability Management > Recommendations).

8. Common pitfalls and how to avoid them

"We auto-update" without verification

Auto-update mechanisms in Chrome, Edge and Microsoft 365 Apps are valuable, but an organisation still needs evidence that the required versions reached the assessed scope within the applicable timeframe. Offline devices, policy exceptions and failed update clients can create gaps that version inventory and vulnerability scanning should detect.

Always supplement auto-update with centralised reporting that demonstrates fleet-wide coverage and per-device patch dates.

Portable applications and shadow IT

Portable applications — those installed without administrator rights and stored in user profile directories — are invisible to most enterprise patch management tools. WinRAR, older versions of 7-Zip, standalone Python distributions, and many open-source tools are commonly installed by technically capable employees outside the software catalogue. Use Microsoft Defender for Endpoint's Software inventory view or a dedicated asset management tool to detect non-catalogue application installations. Include a clause in your acceptable use policy requiring employees to use only catalogue-approved software and report any business need for additional tools.

BYOD devices with unmanaged applications

BYOD (bring your own device) endpoints enrolled in Intune under a personal device profile may have application installations outside the organisation's management scope. The ACSC does not make an exemption for BYOD devices — if those devices access corporate data, the organisation is responsible for ensuring in-scope applications on those devices are patched. Enforce application protection policies in Intune that prevent access to corporate data if the device does not meet the minimum OS and application version requirements. Consider whether BYOD access is appropriate for systems containing sensitive information given the patching visibility limitations.

Server applications overlooked

Application patching assessments frequently focus on desktop endpoints and overlook server-hosted applications: web server software (Apache, Nginx, IIS modules), database client tools (SQL Server Management Studio, Oracle SQL Developer), and application runtimes (.NET Framework, Node.js) installed on servers. The ACSC's scope for Control 2 includes internet-facing server applications. Ensure your vulnerability scanning scope covers servers — not just workstations — and that server patching timelines align with the same ACSC maturity requirements as endpoint patching.

Internet-facing application patching as the highest priority

Prioritise internet-facing and otherwise exposed applications within each applicable deadline. Document the prioritisation logic in the patch-management policy so assessors can see how exposure, vendor criticality and exploit availability drive the order of remediation.

9. Australian context and compliance obligations

ASD threat intelligence on application exploit vectors

The ASD Cyber Threat Report 2023-24 identifies exploitation of internet-facing applications as the most common initial-access technique used against Australian government, critical infrastructure, and commercial organisations. Browsers and productivity suites (specifically Microsoft Office and PDF readers) were the top two exploit vectors by frequency. The ASD specifically noted that many successful compromises involved vulnerabilities for which patches had been available for well over a month — far beyond the two-week ML1 patching window — highlighting the gap between patch availability and patch deployment in many Australian organisations.

Privacy Act obligations when patch failure leads to a data breach

Under the Australian Privacy Act 1988 (Office of the Australian Information Commissioner — Privacy Act 1988, accessed 16 June 2026) and the Notifiable Data Breaches (NDB) scheme (Office of the Australian Information Commissioner — Notifiable Data Breaches scheme, accessed 16 June 2026), organisations that experience a data breach resulting from a known, patchable vulnerability may face regulatory scrutiny from the Office of the Australian Information Commissioner (OAIC). The OAIC has published guidance indicating that reasonable steps under Australian Privacy Principle 11 (Office of the Australian Information Commissioner — Australian Privacy Principles guidelines, accessed 16 June 2026) include keeping software up to date by applying patches and updates in a timely manner — meaning patch management is not optional for organisations handling personal information. The OAIC has published further guidance indicating that failure to apply available security patches within a reasonable timeframe may constitute a failure to take reasonable steps to protect personal information under Australian Privacy Principle 11 (APP 11).

If a breach occurs because an application vulnerability was exploited and a patch was available but not applied within the required Essential Eight timeframe, the organisation faces both an NDB obligation (to assess a suspected eligible breach within 30 days, then notify the OAIC and affected individuals as soon as practicable once it forms the view that an eligible breach has occurred) and potential OAIC investigation. Demonstrating that a structured patch management programme was in place — even if it failed to catch a specific vulnerability in time — is materially better than having no programme at all.

ACSC advisory recommendation to prioritise internet-facing patching

The current Essential Eight profiles require online-service vulnerabilities rated critical by the vendor, or with a working exploit, to be patched, updated or mitigated within 48 hours from Maturity Level 1. Non-critical online-service vulnerabilities without a working exploit have a two-week window. Maintaining an accurate inventory of online services and monitoring vendor advisories and exploit intelligence are therefore necessary to select the correct deadline.

For organisations seeking alignment with the Australian Government Information Security Manual (ISM), the relevant controls include ISM-1876 and ISM-1690 for online services; ISM-1691, ISM-1692 and ISM-1901 for the specified high-risk application categories; and ISM-1693 for other applications.

10. Before and after: Control 2 patch management posture

Before implementing Control 2 systematically: Applications updated ad hoc when users notice prompts; no centralised visibility over fleet patch status; overdue vulnerabilities on endpoints; no audit evidence available for assessors; shadow IT and portable applications undetected; BYOD patching unknown.

After implementing Control 2 at Level 3: Application register maintained and reviewed; management and vulnerability tools provide fleet-wide patch visibility; applicable vendor-critical and exploited vulnerabilities enter the 48-hour process; vulnerability scanning runs weekly for the specified high-risk categories and fortnightly for other applications; portable and shadow IT applications are detected and remediated; assessment evidence is retained with compliance reports, deployment logs and approved exceptions.

Call to action

Application patching requires current asset visibility, a deployment capability that can meet each deadline, vulnerability scanning and systematic evidence collection. Test the emergency path for vendor-critical and exploited vulnerabilities before it is needed.

Start by inventorying your in-scope applications, deploying Defender Vulnerability Management for fleet-wide visibility, and configuring Intune deployment rings with deadline enforcement. Book an Essential Eight Assessment to benchmark your current patch management maturity, identify gaps across all eight controls, and receive a prioritised remediation roadmap built for your environment and budget.

Sources referenced in this article: ACSC Essential Eight Maturity Model, ASD Essential Eight Assessment Process Guide, Australian Privacy Act 1988 (OAIC), OAIC Australian Privacy Principles guidelines (APP 11), Notifiable Data Breaches scheme (OAIC), Australian Government Information Security Manual (ISM), ASD Cyber Threat Report 2023-24, ACSC Annual Cyber Threat Report, Adobe security bulletins, Tenable Nessus / Qualys.