The Essential Eight: Patching Applications and Operating Systems at Maturity Level Two

Why do so many patching programs pass every internal check and still come back from an Essential Eight assessment rated at Maturity Level One? The answer is rarely speed. Teams that miss the mark are usually patching their servers, browsers, and office suites on schedule, then losing the rating on the fifty applications nobody put on a list.

Maturity Level Two is where the Essential Eight stops asking how fast you patch and starts asking how much you can see. Each patching strategy carries its own scan cadence, its own deadline clock, and its own definition of scope. Miss one class of software and your overall maturity drops to your weakest strategy, however good the rest looks.

This article works through both patching strategies control by control, separating what carries over from Maturity Level One from what is genuinely new. If your patch management program is being assessed this year, that distinction decides your result. In this blog, you will see what Level Two asks for, where programs lose the rating, what evidence an assessor accepts, and what the framework's announced retirement changes.

What Are the Essential Eight, and Which Two Controls Cover Patching?

The Essential Eight are eight prioritized mitigation strategies published by the Australian Signals Directorate through the Australian Cyber Security Centre, designed as a baseline for internet-connected corporate networks. Two of them deal with keeping software current: patch applications and patch operating systems. Essential Eight patch management means those two strategies working together, and they are the subject of this article.

The full set runs to eight strategies:

1. Application control

2. Patch applications

3. Configure Microsoft Office macro settings

4. User application hardening

5. Restrict administrative privileges

6. Patch operating systems

7. Multi-factor authentication

8. Regular backups

These belong to the same family of technical baselines as the control sets behind broader cybersecurity compliance programs, with an Australian scope and a maturity ladder attached. You will see the framework written as ASD Essential Eight, ASD Essential 8, or ACSC Essential 8 in vendor material. The Essential 8 maturity model and the Essential Eight Maturity Model are the same document under different spellings.

What Is the Essential Eight in Practical Terms?

The Essential Eight in practical terms is a procurement requirement before it is a technical project. That is the plain answer to "what is Essential Eight cybersecurity" for most organizations. Under the Protective Security Policy Framework, non-corporate Commonwealth entities must implement all eight strategies to Maturity Level Two, and contractors, service providers, and suppliers inherit the same expectation through tenders and customer contracts.

The maturity model runs across four levels:

1. Maturity Level Zero: One or more Maturity Level One requirements are not met

2. Maturity Level One: Protection against opportunistic actors using widely available tradecraft

3. Maturity Level Two: Protection against actors willing to invest more time and effort in a chosen target

4. Maturity Level Three: Protection against adaptive actors using advanced tradecraft

One rule shapes every program built on the ACSC Essential Eight maturity model. Your overall rating is the level of your least mature strategy, so seven at Level Two and one at Level One produces Level One. Patching is the strategy most likely to be that weak link, because its scope grows every time somebody installs something.

Why Does Maturity Level Two Trip Up Programs That Patch on Schedule?

Maturity Level Two exposes coverage gaps rather than timing gaps, and coverage is harder to fix than cadence. ASD's 2025 posture report shows the scale of it from two directions:

• 22% of entities reached overall Level Two: Up from 15% in 2024 and below the 25% of 2023, a drop ASD attributes to the November 2023 hardening

• 59% said legacy technology held them back: Down from 71% the year before

Those two figures describe the same problem from opposite ends: software you cannot patch, and software you did not know you had.

Both register as vulnerability management gaps long before an assessor writes them up as patching gaps.

What Does Missing Maturity Level Two Cost the Business?

Missing Maturity Level Two costs revenue access before it costs anything in security terms, because the rating is written into procurement documents rather than into your security policy. Tenders, prime contractor deeds, and enterprise supplier questionnaires name a maturity level and a date, and a Level One result can remove a bid from consideration before price is discussed.

Three business consequences follow, and none of them show up on an engineering dashboard:

1. Contract eligibility: Tenders and deeds that specify Maturity Level Two treat the rating as a gate rather than a scoring factor

2. Assessment cost: Evidence rebuilt from scratch each cycle turns a short assessment into a quarter of internal effort

3. Budget misdirection: Programs that read Level Two as a speed problem buy deployment tooling when the gap is in discovery

Consider a managed services firm bidding to supply a state government agency, with several years of recurring revenue attached. Its server patching is current and its Windows cycle is disciplined, so leadership treats the maturity question as settled. The assessment returns Level One on a long tail of departmental software, and the bid never reaches the commercial evaluation.

The budget read is the one that matters at leadership level. Coverage is largely a data problem that IT asset management solves once and then maintains, while deadline compliance is a recurring operational cost. Level Two rewards spending on the first, which is also the cheaper of the two to sustain.

What Changes Between Maturity Level One and Maturity Level Two?

Maturity Level Two changes patch applications and leaves patch operating systems untouched. This surprises most teams, because the framework's reputation suggests every level tightens every deadline. Under the current model that is not how the two patching strategies are structured.

The table below maps the patch applications requirements across all three levels so you can see exactly which two rows are new at Level Two.

Both tables reflect the November 2023 release of ASD's maturity model, which remains the version in force. Now compare the operating system strategy, where the Level Two column is a copy of the Level One column.

Two conclusions follow, and both change how you spend budget:

1. Operating systems: A program already at Level One needs no new deadline work here

2. Applications: Everything gained at ACSC Essential Eight maturity level 2 comes from covering the long tail

Coverage is an inventory problem before it is a deployment problem, which is the opposite of where most patching budgets go.

What Does ACSC Essential Eight Maturity Model Level 2 Require for Patch Applications?

The ACSC Essential Eight maturity model level 2 requirement for patch applications extends both scanning and patching beyond the high-risk software categories to every application in the environment. Nine controls apply in total, and the last two are the additions:

1. An automated method of asset discovery runs at least fortnightly to feed subsequent scanning

2. The vulnerability scanner in use carries an up-to-date vulnerability database

3. Online services are scanned for missing patches at least daily

4. Office productivity suites, web browsers and their extensions, email clients, PDF software, and security products are scanned at least weekly

5. Online services are patched within two weeks, or within 48 hours when the vendor rates the vulnerability critical or a working exploit exists

6. The high-risk application categories are patched within two weeks of release

7. Unsupported online services and unsupported high-risk applications are removed

8. New at Level Two: All other applications are scanned at least fortnightly

9. New at Level Two: All other applications are patched within one month of release

Two details in that list cause more assessment failures than any deadline:

1. "All other applications" carries no exclusions: Departmental tools, contractor software, and anything installed outside the standard build all count

2. The scanner requirement is about the database behind it: A scanner running on a stale feed fails the control even when it runs on schedule

Consider a finance team's reporting add-in, installed on eleven machines through a vendor download link. Under Level One it falls outside the named categories and nothing is required. Under Level Two it needs a fortnightly scan, a one-month patch window, and a place in an inventory somebody maintains.

What Does Maturity Level Two Require for Patching Operating Systems?

Maturity Level Two requires the same six operating system controls as Maturity Level One, with no additional scanning frequency and no shortened deadline. Internet-facing servers and network devices carry the tight end of the requirement:

• Scan: Daily

• Patch: Within two weeks of release

• Escalate to 48 hours: When the vendor rates the vulnerability critical or a working exploit is announced

Workstations, non-internet-facing servers, and non-internet-facing network devices carry a fortnightly scan and a one-month patch window. Operating systems no longer supported by their vendor must be replaced rather than mitigated, which is where legacy systems turn a patching task into a capital project.

Where Operating System Coverage Slips

Network devices are the assets most often missing from an operating system inventory. Switch, router, and firewall firmware falls under this strategy when the device is internet-facing, and an unsupported switch image fails the control as surely as an unsupported server. Teams already running network device compliance checks hold most of this evidence, and the same records support Cisco switch management reviews.

Multi-platform coverage matters here in a way the framework does not spell out. The requirement makes no distinction between platforms, so a Linux fleet needs the same fortnightly scan and one-month window as the Windows fleet. Programs that run mature Windows patch management and treat Linux as a manual exercise usually discover the gap during assessment rather than before it.

How Do You Build a Patch Window Calendar That Survives an Assessment?

Build the calendar from release dates rather than detection dates, because every Essential Eight patching deadline starts on the day the vendor publishes. Your scanner picks the vulnerability up later, and that later date carries no weight with an assessor. This single arithmetic decision separates programs that pass from programs that spend the assessment arguing.

The scanning cadence explains why. ASD generally sets scan frequency at roughly double the patch frequency, so a fortnightly scan on a one-month deadline gives you two chances to catch a missing patch. Detection-based clocks quietly extend every deadline by up to one scan interval.

Four clocks run in parallel at Maturity Level Two, and each needs its own queue:

• 48-hour clock: Online services and internet-facing operating systems where the vendor rates the vulnerability critical or a working exploit is announced

• Two-week clock: Online services, internet-facing servers and network devices, plus office suites, browsers and extensions, email clients, PDF software, and security products

• One-month clock: Workstations, non-internet-facing servers and network devices, and every application outside the high-risk categories

• Replacement clock: Unsupported operating systems, unsupported online services, and unsupported high-risk applications, which no patch window can satisfy

Deferment settings interact with these clocks in ways that catch people out. A seven-day deferral, a two-day deadline, and a two-day reboot grace period consume eleven of the fourteen days on a two-week control. Tracking patch metrics against each window shows which ring is running too close to the edge.

Why Does Asset Discovery Decide Whether You Reach Maturity Level Two?

Asset discovery decides the outcome because every scanning control at Maturity Level Two depends on a complete inventory. The framework makes that dependency explicit by requiring automated discovery at least fortnightly.

A scanner reports on what it can see. An assessor asks what it cannot.

Where Manual Inventories Break Down

Manual inventories record the standard build accurately and miss most of what surrounds it. The assets that go unrecorded tend to fall into four groups:

• Contractor and consultant laptops: On the network, absent from the asset register

• Rebuilt machines: Reimaged outside the standard provisioning process

• Departmental purchases: Software bought on a card and installed without IT

• Inherited systems: Anything that arrived through an acquisition or merger

Automated asset discovery reports what responded on the network rather than what somebody remembered to record. The systems that satisfy this control cheaply share one property. Asset discovery, software inventory, and patch deployment write to the same record, so the scanner and the deployment tool cannot disagree about what exists.

What Software Inventory Has to Capture

Software inventory carries the same weight as hardware inventory at Level Two, and this is the part most programs underbuild. The "all other applications" requirement rests on two things:

1. Installed software per device: What is running on the machine, version included

2. A refresh cadence inside the fortnightly cycle: New installations found before the next scan falls due

Keeping software license records aligned to that inventory also surfaces the applications you pay for but no longer support.

Discovery feeds the removal controls too. Unsupported applications and operating systems have to be found before they can be removed or replaced, and vendor end-of-support dates rarely appear in a scanner's output on their own. Mapping installed versions against support dates is what turns ITAM compliance work into Essential Eight evidence.

What Evidence Will an Essential Eight Assessment Accept?

An Essential Eight assessment accepts evidence in a ranked order, and ASD publishes that ranking in its assessment process guide. Meeting the ACSC Essential Eight maturity model level two requirements on paper counts for nothing if the proof is the wrong grade. Programs collecting the wrong evidence fail controls they have already implemented.

The four evidence grades run as follows:

1. Simulated control test: Rated excellent, because the assessor watches the control operate

2. Live configuration inspection: Rated good, because the setting is verified in place

3. Reports and screenshots: Rated fair, because they show a moment rather than a mechanism

4. Policy documents or verbal assurance: Rated poor, because intent is not implementation

That ranking is not unique to Australia. Assessors working against NIST compliance requirements apply much the same preference for tested controls over documented intent, so evidence built for one regime usually travels.

For patching, that hierarchy translates into specific artifacts. Three artifacts carry a control further than a patching policy ever will:

• Dated scan output: Coverage across the full inventory, not a sample

• Deployment records: A patch tied to a device and a date

• Audit log: Approvals, exceptions, and who signed them

The practical test of any platform here is narrow. Ask whether it can produce a dated coverage report per patch class, on demand, without somebody merging three exports the night before.

Exceptions need their own paperwork, and this is the piece most often assembled the week before an assessment. Five things make an exception defensible:

1. Named risk owner: A person, not a team mailbox

2. Documented justification: Why the control cannot be met today

3. Compensating controls: Protection of equivalent strength

4. Formal risk acceptance: Signed off at the right level

5. Review date: No more than twelve months out

Building that record as part of routine patch compliance reporting is cheaper than reconstructing it later. The same deployment history answers the change-control questions that SOX compliance audits ask of financial systems.

One question sits underneath all of this evidence work, and it became a board-level question in June 2026.

Is the Essential Eight Being Retired, and Should You Still Target Maturity Level Two?

The Essential Eight is being retired, and you should still target Maturity Level Two. The most significant Essential Eight news of 2026 arrived in June, when ASD opened consultation on a replacement body of guidance called the Essentials series and confirmed a transition timeline.

The published plan runs in three stages:

1. Parallel running: Both documents stay live through a handover period

2. Deprecation: The Essential Eight starts being wound back at roughly the twelve-month mark

3. Retirement: Full retirement follows at roughly twenty-four months

Consultation on the first chapter, Essentials for enterprise IT, closed on 12 July 2026, with chapters on operational technology and cloud expected to follow. ASD has not published a fixed retirement date.

ASD's position on existing work has been consistent, and it matters for anyone weighing a pause. The controls carry across, the investment stays relevant, and the Essential Eight remains the standard in force today for every contract and tender that references it. Patching applications and operating systems will not become less important under threat-informed guidance built for cloud and AI-era environments.

The practical read for an IT director is straightforward. Any successor framework will ask for the same three things, and a Maturity Level Two uplift builds all of them:

1. Coverage: A complete inventory of devices and installed software

2. Cadence: Scan and patch cycles that run without being chased

3. Evidence: Dated records showing the controls operating

The organization that reaches Level Two before the transition starts is the one with a working inventory when the new chapters land.

Bring the Long Tail of Applications Under Control with Motadata ServiceOps

Most patching tools handle the operating system well and treat third-party applications as an afterthought, which is backwards for Essential Eight compliance. Level Two asks nothing new of your operating systems and everything of your application coverage. A tool that cannot inventory and patch the long tail leaves you at Level One however disciplined the Windows cycle is.

Motadata ServiceOps unifies IT asset management and patch management on a shared configuration management database, the single record of what you own and what runs on it. That one record drives:

• Automated asset and software discovery: New devices and new installations appear without a manual update

• Patch discovery and deployment: Windows, macOS, and Linux distributions from one console

• Controlled rollout: Test groups, approval workflows, maintenance windows, user deferment, and forced reboots

• Coverage and completion reporting: The dated output an assessor asks for

Each of the four patch clocks then gets its own policy rather than its own spreadsheet.

No platform delivers a maturity level on its own, and it would be misleading to suggest otherwise. Scope decisions, exception records, risk acceptance, and the assessment itself stay with your team, and legacy systems that cannot be patched still need compensating controls. What tooling changes is how much of the year you spend finding out where you stand, which is usually the difference between reaching Level Two and planning to.

FAQs