Essential Eight PO-ML3.3 Apply critical patches to non-internet-facing OS within 48 hours
What it says
Patches, updates or other vendor mitigations for vulnerabilities in operating systems of workstations, non-internet-facing servers and non-internet-facing network devices are applied within 48 hours of release when vulnerabilities are assessed as critical by vendors or when working exploits exist.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishQuickly install critical updates on internal systems to fix security vulnerabilities.
This control is about making sure we quickly update the computer systems inside our organisation that aren't directly connected to the internet. This is crucial because if there's a known weakness, hackers could use it to break into our system. By fixing these vulnerabilities quickly, we prevent bad actors from exploiting them and causing harm.
Free. Save your status, tasks and notes.
Why it matters
Delaying patches on non-internet-facing operating systems can leave known critical flaws exploitable, enabling lateral movement and internal data compromise.
How to implement
The IT team should systematically monitor for new critical updates.
Use a reliable updates monitoring service that alerts your team of critical patches within hours of their release.
System administrators should prioritise the installation of critical patches.
Use an automated patch management tool to apply these updates within the 48-hour window.
Security officers should cross-verify critical updates that need to be applied.
They can refer to trusted security bulletins like Microsoft Security Response Centre to verify the criticality of updates.
Technical staff should routinely assess and adjust the update process.
Conduct regular training sessions to ensure the team follows the correct procedures for fast and efficient patch installations.
Keep it running
Track vendor advisories and prioritise critical/actively exploited OS fixes; deploy to non-internet-facing servers, workstations and devices within 48 hours.
Evidence and audit
- Check 1 of 2What an auditor asks for
Ask for
How does the organisation ensure critical patches are applied within 48 hours?
Look at
Examine the patch management system logs for records of when patches were applied.
Good evidence
Logs show critical patches were consistently applied within 48 hours of their release over the past six months.
- Check 2 of 2What an auditor asks for
Ask for
What process is in place for recognising critical updates?
Look at
Review the protocol documents that outline the criteria for identifying and prioritising critical updates.
Good evidence
The process document clearly defines how updates are classified as critical using vendor assessments and trusted security advisories.
Mappings
Closest match in ASD Information Security Manual: ISM-1696, Apply critical patches within 48 hours, which asks for the same thing.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.8.
E8-PO-ML3.3 requires organisations to apply critical operating system patches to non-internet-facing workstations, servers and network devices within 48 hours when vendor criticality or working exploits are present. Annex A 8.8 requires obtaining information about technical vulnerabilities, evaluating exposure, and taking appropriate measures, which encompasses patching as one treatment option. E8-PO-ML3.3 is a prescriptive subset of Annex A 8.8, adding explicit scope (OS on internal assets) and a defined remediation timeframe (48 hours).
ASD Information Security Manual: 13 mappings
This control is equivalent to ISM-1696.
ISM-1696 requires critical patches, updates or vendor mitigations for operating systems on workstations, non-internet-facing servers and non-internet-facing network devices to be applied within 48 hours when rated critical or when working exploits exist. E8-PO-ML3.3 states the same 48-hour requirement for the same system scope and the same triggering conditions (vendor-critical or working exploit). Implementing E8-PO-ML3.3 would largely satisfy ISM-1696 and vice versa.
This control partially overlaps ISM-1606.
ISM-1606 requires patches/updates/vendor mitigations to be applied in a timely manner to both the software isolation mechanism and the underlying host operating system for shared physical servers. E8-PO-ML3.3 overlaps by imposing a 48-hour timeframe for critical/exploited operating system vulnerabilities on workstations and non-internet-facing servers/devices, which includes typical hypervisor host OSs that are not internet-facing. The shared requirement is timely host OS remediation, but ISM-1606 also explicitly covers the isolation mechanism itself and does not constrain triggering conditions to vendor criticality or exploit availability.
This control partially overlaps ISM-1695.
ISM-1695 mandates applying OS security patches for non-internet-facing workstations, servers and network devices within one month of release. E8-PO-ML3.3 covers the same system types but tightens the requirement to within 48 hours when vulnerabilities are critical or working exploits exist. The two controls overlap on the same patching activity and scope, but they differ materially on timeframes and triggering conditions.
This control partially overlaps ISM-1876.
ISM-1876 requires applying critical patches for vulnerabilities in online services within 48 hours based on vendor criticality or the presence of working exploits. E8-PO-ML3.3 also mandates a 48-hour patch window for critical vulnerabilities, but for operating systems on workstations and non-internet-facing servers/network devices. The time-and-trigger logic is the same, however the technology scope differs (online services vs non-internet-facing OS assets).
This control partially overlaps ISM-1877.
ISM-1877 requires critical patching within 48 hours for operating systems on internet-facing servers and internet-facing network devices when vendor-critical or exploited. E8-PO-ML3.3 applies the same 48-hour criticality/exploit trigger but targets non-internet-facing operating systems (workstations, internal servers, internal network devices). They align on the patch urgency logic, but differ materially on which systems are in scope (internet-facing versus internal).
This control partially overlaps ISM-1878.
ISM-1878 mandates applying critical OS patches within 48 hours for IT equipment other than workstations, servers and network devices, based on vendor criticality or known working exploits. E8-PO-ML3.3 requires the same 48-hour patching outcome but for workstations, non-internet-facing servers and non-internet-facing network devices. They share the patch-timeliness and trigger conditions, but cover different classes of assets.
This control partially overlaps ISM-1902.
ISM-1902 requires organisations to apply non-critical operating system patches to non-internet-facing systems within one month when no working exploits exist. E8-PO-ML3.3 relates by covering the same asset classes (workstations, non-internet-facing servers and network devices) but focuses on critical vulnerabilities or those with working exploits and mandates patching within 48 hours. They overlap on the shared objective of timely OS vulnerability mitigation for non-internet-facing systems, but differ on severity/trigger conditions and timeframes.
This control depends on ISM-0298.
E8-PO-ML3.3 requires critical OS patches on workstations, non-internet-facing servers and non-internet-facing network devices to be applied within 48 hours when vendors rate them critical or working exploits exist. ISM-0298 establishes the centralised, managed patching capability (including integrity and verification of successful deployment) that is typically required to consistently meet that 48-hour SLA at scale. ISM-0298 is broader across asset types (applications, drivers and firmware as well as OS) but does not itself set the 48-hour criticality requirement that E8-PO-ML3.3 mandates.
This control depends on ISM-1143.
E8-PO-ML3.3 mandates a time-bound outcome: critical OS vulnerabilities on internal systems are remediated via patches/updates/mitigations within 48 hours. ISM-1143 requires an organisation to establish and maintain patch management processes and procedures, which are a prerequisite to reliably triage criticality, schedule changes, and drive patch deployment within that timeframe. ISM-1143 is broader and more procedural, while E8-PO-ML3.3 is a specific operational performance requirement focused on OS and a 48-hour window.
This control depends on ISM-1643.
ISM-1643 requires software registers to record operating system versions and patch histories. This supports E8-PO-ML3.3 by enabling organisations to verify and audit that critical patches for non-internet-facing operating systems were applied within 48 hours of release. E8-PO-ML3.3 is about patch deployment SLAs, whereas ISM-1643 is about maintaining authoritative patch history records.
This control depends on ISM-1702.
ISM-1702 requires organisations to run a vulnerability scanner fortnightly to identify missing operating system patches on non-internet-facing assets. E8-PO-ML3.3 focuses on remediation by requiring critical OS patches (or mitigations) for those same non-internet-facing assets to be applied within 48 hours. ISM-1702 supports E8-PO-ML3.3 by providing the detection mechanism that helps identify patching gaps, but it does not set any patch deployment timeframes.
This control depends on ISM-1921.
ISM-1921 requires organisations to frequently reassess compromise likelihood when working exploits exist for unmitigated vulnerabilities. E8-PO-ML3.3 supports ISM-1921 by defining an urgent patching expectation for exploited or critical OS/device vulnerabilities in non-internet-facing environments, which should still trigger reassessment of lateral movement risk, privilege boundaries and compensating controls. E8-PO-ML3.3 is treatment-focused, while ISM-1921 is the reassessment cadence and prioritisation logic that governs what to do while vulnerabilities remain unmitigated.
This control depends on ISM-1981.
ISM-1981 requires replacement of non-internet-facing network devices that are no longer supported, reducing the number of devices that cannot be effectively patched or mitigated. E8-PO-ML3.3 requires applying critical patches (or vendor mitigations) to operating systems on non-internet-facing network devices within 48 hours. Replacing unsupported devices under ISM-1981 strengthens E8-PO-ML3.3 because patch timeliness is only achievable when the device/OS remains vendor-supported.
ASD Essentials for enterprise IT: 2 mappings
- IT.PRO-06.2Apply security patches within risk-based timeframes and automate low-impact updatesPartially overlaps
This control partially overlaps IT.PRO-06.2.
IT.PRO-06.2 requires security patches to be applied within risk-based timeframes; E8-PO-ML3.3 sets 48 hours to patch operating systems of workstations and non-internet-facing servers and network devices when vendors rate vulnerabilities critical or working exploits exist, one specific case of that.
- IT.PRO-06.3Remediate or mitigate above-threshold vulnerabilities within defined timeframes and verify effectivenessPartially overlaps
This control partially overlaps IT.PRO-06.3.
IT.PRO-06.3 requires vulnerabilities above risk thresholds to be remediated or mitigated in set timeframes; E8-PO-ML3.3 sets 48 hours to patch operating systems of workstations and non-internet-facing servers and network devices when vendors rate vulnerabilities critical or working exploits exist, one such timeframe.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.