Essential Eight patching: hitting the two-week and 48-hour windows

Two of the eight mitigation strategies are patching, and both are graded on elapsed time rather than effort. It does not matter that you patch diligently. It matters whether a specific class of system was patched inside a specific number of days, repeatedly, and whether you can show it.

That shift — from "we patch" to "we patched within the window, and here is the report" — is what most organisations underestimate.

The windows, by asset class

The two strategies split the estate into classes and give each its own clock:

• Internet-facing online services and internet-facing servers and network devices: 48 hours where the vendor assesses the vulnerability as critical or a working exploit exists, two weeks otherwise.
• Office productivity suites, browsers and their extensions, email clients, PDF software and security products: two weeks from Maturity Level One.
• Operating systems of workstations, non-internet-facing servers and network devices: one month at Level One, tightening at higher levels.
• All other applications: enters scope at Level Two, one month.

At Maturity Level Three the 48-hour rule broadens: where an exploit exists, the shorter window applies across the classes rather than only to internet-facing services.

The 48-hour clause is the one that breaks change processes. It cannot wait for a Tuesday CAB meeting. If your only path to production runs through a weekly approval board, you cannot meet it, and no amount of good intent changes that.

Scanning is a requirement too

Patching fast is not enough — the model separately requires that you look:

• Automated asset discovery at least fortnightly, feeding the scanning.
• A vulnerability scanner with an up-to-date vulnerability database.
• Scanning at least daily for internet-facing online services.
• Scanning at least weekly for the productivity and browser layer.
• Scanning at least fortnightly for operating systems, and for all other applications from Level Two.

Asset discovery is listed first for a reason. A scanner that covers 80% of the estate produces a clean report and an incomplete picture, and the assessor will compare your scan coverage against your inventory.

Unsupported software is a hard fail

Both strategies require software and operating systems no longer supported by their vendor to be removed or replaced. Not isolated, not risk-accepted, not compensated for.

This is where a mature ISO 27001 mindset actively works against you. A documented risk acceptance for a legacy application, signed off by the right people and reviewed annually, is good practice under ISO and an outright failure here. One end-of-life system is enough to fail the strategy, and therefore to set your whole Essential Eight rating.

Find these early. The usual suspects: a line-of-business application on an old runtime, a network appliance past end-of-support, a server kept alive for one report, and anything inherited through an acquisition.

What "an exploit exists" should mean for you

The 48-hour trigger needs a definition you set in advance, because the decision will otherwise be made under pressure by whoever is available. A workable one: a public working exploit, credible reporting of exploitation in the wild, or inclusion in a widely used exploited-vulnerability catalogue. Write it down, apply it consistently, and record the decision each time it fires — that record is itself evidence.

The reporting that proves it

Assessors look for the timeframe met over a period, not on the day they visit. Build a report that shows, per asset class, time from vendor release to deployment across the last several months, with the percentage inside the required window. If you cannot produce that today, instrument it before you try to speed anything up — you cannot demonstrate a window you were never measuring.

Keep alongside it: the asset inventory the scanning covers, scanner configuration showing the database is current, records of expedited patching under the 48-hour rule, and the end-of-life register with removal dates.

Where programmes go wrong

• Measuring from detection rather than vendor release. The clock starts at release. A weekly scan can silently consume half your window before you have even noticed.
• Excluding the appliance layer. Network devices and security products are named explicitly and are frequently outside the standard patch process.
• Third-party browser extensions. In scope, rarely inventoried.
• Counting deployment as completion without confirming installation and reboot where required.

Key takeaways

• The clock starts at vendor release, not at your detection.
• The 48-hour rule is incompatible with a weekly-only change board.
• Unsupported software must be removed or replaced — risk acceptance does not pass.
• Instrument patch-age reporting before trying to patch faster.