Essential Eight patching is not one strategy. It is two — Patch Applications and Patch Operating Systems — rated independently from maturity level zero to three. Most teams run them as a single capability with one owner and one tool, then receive two different ratings and spend a week working out why.
The two diverge on the things that actually decide a rating: which assets the scanner reaches, how fast the window closes for different kinds of software, and what you have done about software the vendor no longer supports.
Treat them as one programme operationally. Evidence them as two.
Why Essential Eight Patching Is Rated as Two Strategies
Essential Eight patching is rated as two strategies because the asset classes behave differently under assessment, not because ASD wanted a longer list. Applications and operating systems have different vendors, update mechanisms, exposure profiles and end-of-life dynamics, and an implementation that handles one well can be genuinely weak on the other. They also sit under different objectives in ASD's grouping: Patch Applications with the strategies aimed at preventing malware delivery and execution, Patch Operating Systems with those aimed at limiting the extent of an incident.
So your gap list has two rows. A team with excellent server patching and no visibility into what browser extensions and PDF readers are installed on laptops is not "good at patching" — it is strong on one strategy and weak on the other, and the Essential Eight maturity model will report both.
What Patch Applications Covers
Patch Applications covers software running on top of the operating system, and the scope that matters most for the Essential Eight is software that touches untrusted content or is reachable from the internet: internet-facing services, web browsers and their extensions, the office productivity suite, PDF readers, email clients and security products.
Two features of this strategy catch teams out. The first is breadth — an operating system inventory is short and known, while an application inventory on a real fleet is long, partly self-installed, and includes things nobody remembers approving. You cannot patch what you have not enumerated, and enumeration is the harder half of the job.
The second is that removal counts: where an application is no longer supported by its vendor, the strategy is satisfied by removing it rather than patching it.
What Patch Operating Systems Covers
Patch Operating Systems covers the operating systems themselves across workstations, servers and network devices, and the maturity requirements reach further into the estate as the level rises — which is where most of the gap between an expected and an assessed rating appears. Internet-facing servers and services are treated with the most urgency; the rest of the fleet follows on a longer clock.
Network devices are the recurring omission. Firewalls, load balancers, VPN concentrators and their management interfaces run operating systems, they are frequently internet-facing, and they are often owned by a networking team whose change windows have nothing to do with the endpoint patching cycle. A rating that excludes them is not a rating of this strategy. The same goes for virtual appliances someone deployed from a marketplace image and never touched again.
Two patching ratings, one programme — want to know where yours split?
Share your work email and we'll map your scanning coverage and patch windows against both patching strategies and show which assets are breaking which rating.
How the Patch Timeframes Tighten With Maturity
The Essential Eight patch timeframes tighten as the maturity level rises, and at every level they differ by the exposure of the software rather than applying uniformly. Get those two dimensions right before arguing about any particular window. The direction of travel is consistent:
- Exposure drives urgency. Internet-facing services and the software most likely to meet untrusted content are patched on a materially shorter clock than software sitting behind other controls on an internal workstation. The same patch can be urgent on one asset class and routine on another.
- A working exploit compresses the window further. Where a vulnerability is being exploited in the wild, the expectation is to move faster than the ordinary cadence for that asset class, and at higher maturity that accelerated route has to exist as a defined process rather than an improvisation.
- Higher levels narrow the gap. As maturity rises, the window for the less-exposed asset classes closes toward the one already required for the exposed ones, so the fleet converges on a single tight cadence rather than keeping a slow tier.
- Scanning frequency tightens in step. The timeframe requirements come with detection expectations, and those become more frequent as the level rises too.
ASD publishes the specific windows per strategy, asset class and maturity level in the maturity model itself. Read them from the Australian Cyber Security Centre rather than a vendor summary or an internal wiki page, because they are what your assessment is run against and they have been revised before.
Whatever the figures, build more than one SLA. A single organisation-wide patch SLA cannot satisfy a model that asks different things of internet-facing services and internal workstations; teams that run one number either over-invest everywhere or fail on the exposed tier.
Vulnerability Scanning Sets the Clock
Vulnerability scanning is the foundation of both patching strategies, because a patch timeframe is a clock and scanning is what starts it. You cannot evidence that you patched within a window without a defensible answer to when the vulnerability became known to you — and for most organisations that answer is "when our scanner told us", which makes scanning cadence the thing that decides whether the clock can be measured at all.
Scanning a class of assets infrequently does not slow the clock; it blinds you to when it started. An assessor who sees a scan interval longer than the patch window for that asset class does not need your remediation data, because the detection gap already makes the timeframe unevidenceable.
Three properties decide whether scanning will support a rating.
Cadence by asset class. Internet-facing services and the assets on the shortest patch clock need the most frequent scanning. One scan interval across the whole estate is the same mistake as one patch SLA.
Coverage against an inventory, not against itself. Coverage is the ratio of what the scanner sees to what you own, and that denominator has to come from an asset inventory maintained outside the scanner. Without it, a clean scan report is indistinguishable from a scan that never ran.
Authenticated detection for applications. Unauthenticated network scanning finds exposed services well and installed desktop applications poorly. Application patching ratings usually turn on whether the approach can see third-party software versions on endpoints — credentialed scanning, an agent, or a software inventory feed from the endpoint management platform.
The patch management process you document should state, per asset class, how a vulnerability is detected, when the clock starts, who owns remediation and how an exception is raised. An assessor reads that before looking at a single ticket.
Unsupported Software Is Part of the Strategy
Unsupported software sits inside both Essential Eight patching strategies, and it is where good patching programmes most often lose a level. Software no longer receiving security updates from its vendor cannot be patched, so the strategy asks you to remove or replace it. Identifying it and removing it are both required.
"We have a plan to upgrade" is not the strategy being met. A plan is evidence of intent; the strategy asks about state. An unsupported operating system in production with a migration project behind it is still in production, and it will be assessed that way regardless of how firm the date is.
Finding it is usually harder than removing it. The common hiding places:
- A legacy server kept alive for one reporting integration nobody will sign off retiring
- An embedded operating system inside an appliance, a camera system or a building control system, where vendor support ended before you inherited it
- An application framework or runtime whose major version went out of support while the application on top of it kept working fine
- A browser or PDF reader version pinned by a line-of-business application that will not run on anything newer
Each needs a dated decision, an owner, and either a removal or a compensating isolation you can describe honestly — not a register line rolled forward for two years.
Where Patching Coverage Gaps Live
The coverage gaps that drag a patching rating down live at the edges of the managed fleet rather than inside it, and they are predictable.
Contractor and BYO devices come first. If a contractor's laptop reaches your data it is in scope, and in most organisations it is neither scanned nor patched by you. Decide whether to manage it, replace the access with a managed path, or accept a lower rating — but do not leave it out of the denominator.
Systems outside the standard build come second: the one-off server built by hand for a project, the developer's self-managed virtual machine, the instance a team bought on a credit card. Not in the build means not in the patch pipeline, and frequently not in the scanner either.
Appliances and embedded software come third, and are the asset class most likely to be both internet-facing and unpatched.
Acquisitions are the largest gap in a single step. An acquired environment arrives with its own baseline, its own patch cadence and its own unsupported software, and integration programmes rarely treat reconciling those as a day-one item. Until they do, the acquired estate is setting your patching rating.
Why Running Ahead on Patching Buys Little
Patching moves quickly, which is exactly why it ends up ahead of the rest. The tooling is mature, vendors ship updates on schedules you can plan around, and the owner is obvious — someone already runs patching, even if informally. None of that is true of application control, where the owner is unclear and the deployment needs a learning period before it can be enforced. So the common shape is a respectable level on both patching strategies and level zero on application control, where enforcement never happened.
ASD's guidance is to implement all eight strategies to the same maturity level before advancing any of them, and the logic is simple: an adversary routes around your strongest control. Patching held to a tight window on every asset class buys very little while execution is unrestricted, and an assessment reports the weakest strategy because that is what determines the result.
The useful move once patching is comfortable is to stop improving it and spend the attention on whichever of the eight is furthest behind. That is usually application control, sometimes multi-factor authentication coverage beyond remote access, and occasionally backups that have never been restored.
Essential Eight Patching Questions Teams Ask
These are the Essential Eight patching questions teams ask most often once they see two separate ratings instead of the one they expected.
Because they are two of the eight strategies, sitting under different objectives — application patching under preventing malware delivery and execution, operating system patching under limiting the extent of an incident. They also differ in what decides a rating: scanner coverage, the asset classes involved, and how unsupported software is handled. An organisation can be strong on one and weak on the other, and the assessment shows that rather than averaging it away.
Not on its own. The model asks for different windows depending on the exposure of the software and the maturity level you are claiming, plus a faster route where a working exploit exists. A single fixed cycle across the whole estate is too slow for internet-facing services at any meaningful level and provides no accelerated path. Build separate windows per asset class and a defined process for moving faster when exploitation is known, then check them against ASD's published maturity model.
No. The strategy asks for unsupported software to be removed, so what is assessed is whether it is still there. A dated plan with an owner is the right thing to have, but while an unsupported operating system or application is in production it counts against the rating. If removal cannot happen inside the assessment period, document the isolation you have applied and expect the finding anyway.
Directly, because scanning establishes when a vulnerability became known to you and therefore when the patch clock started. If the scan interval for an asset class is longer than the patch window for that class, the timeframe cannot be evidenced however fast remediation actually was. Scanning cadence is also specified in the model and tightens as maturity rises, so it is a requirement in its own right.
Yes, if they reach your data or your network, and they are the two largest sources of coverage gaps. The options are to bring them into the managed fleet, replace the access with a managed path such as a virtual desktop, or rate yourself lower and say why.
Keep both patching strategies evidenced between assessments
Book a demo and we'll show how Konfirmity tracks scanning coverage, patch windows by asset class and unsupported software against both Essential Eight patching strategies.
Book a demo
Rate Them Separately, Move All Eight Together
Run patching as one programme with one owner, because splitting the operational work across two teams creates the coverage gaps described above. But rate the two strategies separately, with their own coverage figures, windows per asset class and unsupported software registers. The ratings will differ, and the difference is information worth having.
Start on Monday with one table: your asset classes, the patch window and scan interval you currently achieve for each, and a mark against the ones you can evidence rather than assert. It usually exposes the network devices and the acquired estate within an hour.
Then look away from patching. Work through the Essential Eight assessment process across all eight strategies and spend your effort on the lowest one, because that is the number a buyer is told.
