Essential Eight patch applications: the compliance gap sitting outside Microsoft 365

Your school’s Essential Eight patch applications control probably says you’re covered. Ask what it’s actually checking.

Application patching is one of the eight ASD mitigation strategies, and on paper it’s the least controversial. Everyone agrees software should be kept up to date. The governance risk isn’t disagreement, it’s scope. A patching regime built entirely around Microsoft 365 and Windows Update looks complete on a compliance checklist and still leaves a school exposed, because the Essential Eight maturity model doesn’t stop at Microsoft’s own products. It names web browsers, PDF software, email clients and security products as their own category, on the same clock as everything else, and a genuinely large share of that software in a typical school fleet isn’t made by Microsoft at all.

What the control actually asks for

At maturity level one, ACSC’s expectation is that office productivity suites, web browsers, email clients, PDF software and security products are patched within two weeks of release, regardless of severity. Move toward maturity level three and that window compresses to 48 hours for anything critical or with a known working exploit. Software past end of vendor support has to be removed outright, at every level, not patched less often.

That’s a meaningful commitment for a resource-constrained school ICT team, and one a board or executive team should be asking about directly rather than assuming IT has absorbed it quietly. This detail is drawn from Microsoft’s own mapping of the maturity model rather than the ACSC source directly. Cyber.gov.au was blocking automated access to its own maturity model page at the time of writing, worth knowing if you rely on that page for assessment evidence. Microsoft’s Essential Eight patch applications mapping is the most current detailed source available, and the ACSC maturity model page is the primary reference to cite in formal assessment evidence.

Where the free official example runs out

ACSC publishes a free technical example for implementing this control as part of its small business cloud security guides. It’s built around Microsoft Intune managing Microsoft 365 Apps, and it does that job well: Word, Excel, Outlook, Teams and Edge all get patched through it. What it doesn’t reach is everything else. Chrome. Adobe Acrobat Reader. Zoom. The specialist curriculum or administration software every school accumulates over a decade of procurement decisions made by different people for different reasons. The maturity model requires all of that patched too, and the official worked example is silent on how.

This isn’t a criticism of ACSC, a free illustrative example has to draw a boundary somewhere, and Microsoft 365 is a defensible starting point. The governance point is that a school treating that example as the finished answer has a real gap between what the compliance paperwork implies and what the fleet actually has patched.

A licence-tier correction worth noting

A previous edition of this series, on application control, stated that the free Microsoft 365 A1 licence includes Intune for Education, flagged at the time as needing confirmation against a live tenant. Having since checked Microsoft’s own service description tables directly, that was incorrect for the genuinely free A1 most schools run. Intune, and Intune for Education, come with Microsoft 365 A3 or A5. There’s also a separate, confusingly named licence called “Microsoft 365 A1 for devices”, a low-cost but not free, device-based option that does include Intune for Education, distinct from the standard free A1.

Beyond the correction itself, this is a reasonable proxy for how easy Microsoft’s own licensing is to get wrong even carefully. A Business Manager relying on an MSP’s assurance that “you’ve got Intune, it’s included” deserves a specific licence SKU as the answer, not a general impression, and it’s precisely the kind of assumption worth testing before it ends up in a board paper.

Who actually owns this risk

In most schools, “patching” reads as an IT operations task, true at the technical level and misleading at the governance level. The scope decision, which applications sit inside the patch regime and which sit outside it, is a risk acceptance decision, and risk acceptance belongs with whoever holds budget and consequence, not with whoever configures Intune.

The practical test: ask your ICT lead for a list of every application installed across the fleet, then ask which are covered by an active patch policy with a defined timeframe. The gap between those two lists is your actual exposure, usually bigger than the compliance paperwork suggests, not because anyone’s been negligent, but because nobody’s asked the question in those terms before.

The same test applies to vulnerability scanning. Free, non-endorsed tools exist now, Nessus Essentials for a small footprint, Greenbone Community Edition for the whole fleet if someone has the Linux skills to run it properly, so “we can’t afford it” is no longer a complete answer on its own. “Nobody’s set it up” and “nobody reads the output” are the honest alternatives, and both are governance gaps, not technical ones.

Where this leaves you

A patch report covering only Microsoft’s own products can look complete and still be wrong. The question worth putting to your ICT team this term isn’t whether patching happens, it’s what’s excluded from it, and whether that exclusion was a decision or an accident.

Best Practice - This is the way