Cyber Essentials Patch Compliance

Overview

Directed macOS endpoint compliance against UK Cyber Essentials requirements, building the workflows that keep operating system and third-party application updates inside the certification’s remediation window across the Mac fleet.

Problem

Cyber Essentials sets a hard rule: high-risk and critical updates must be applied within 14 days of vendor release. Not “on a reasonable cadence” — 14 days, for the operating system and for third-party applications, on every in-scope device.

macOS makes that genuinely difficult. Updates are user-consented on managed devices, third-party applications each carry their own updater, and a laptop that is closed for two weeks is simply not patchable during the window. The compliance requirement is absolute and the enforcement surface is not, so the entire problem is closing that distance without breaking people’s working day.

Approach

Split enforcement by what is being patched.

Third-party applications run on App Auto-Patch, which discovers the patchable software already installed on a device and keeps it current on a schedule. That matters because the third-party surface is where the long tail lives — browsers, clients, utilities, each with its own updater and its own idea of when to bother the user. Cyber Essentials counts all of it, and none of it should depend on someone noticing an update badge.

Crucially, AAP writes a per-app receipt for every attempt. That turns patching from something you hope happened into something with per-title evidence, which is what the reporting side is built on.

Restart enforcement closes the gap nobody talks about: a patch that is downloaded and staged but never restarted into is not applied, while the dashboard may well call the device compliant. Laptops that only ever sleep routinely run for weeks.

I handle that with escalating pressure keyed to actual uptime, not a blanket forced reboot:

Uptime	What happens
6 days or less	Nothing. No prompt, no interruption.
7–13 days	A dialog with Restart now and Defer, on a 15-minute timer. Deferring is legitimate and reminds again in 24 hours.
14 days or more	No defer button. I understand, then a 10-minute countdown to an automatic restart.

The point of the middle tier is that almost everyone restarts during it. People given a real choice and a visible deadline handle it themselves; the hard tier exists so the deadline is credible, not because it gets used often.

Architecture

Jamf smart groups scope devices by current OS and application version, so the population needing a given patch is a live query rather than a static list.

App Auto-Patch handles third-party currency and drops a latest.json receipt per title under /Library/Management/AppAutoPatch/receipts/. The restart tiers run from a swiftDialog script that computes uptime from kern.boottime and only reaches for the network once a dialog is actually warranted — a machine under the threshold never touches anything.

Reporting closes the loop: a companion extension attribute reads those AAP receipts and reports each title’s version, timestamp and exit code into Jamf inventory, split into successes and failures. That distinction is the whole value. “App Auto-Patch is deployed” and “App Auto-Patch is succeeding on this device” are different claims, and only the second one is evidence for an auditor.

Outcome

Full OS patching and application update SLA compliance within 14 days of every release, sustaining the endpoint posture Cyber Essentials certification depends on — with per-title patch evidence in inventory rather than an assumption that the tooling ran.

Lessons Learned

Patch compliance is a user-experience problem wearing a security costume. Every technical mechanism for forcing an update exists already — the actual engineering is in applying pressure that escalates predictably, so people update on their own terms before the deadline instead of having a restart imposed on them at the worst possible moment. Fight the user and you get deferrals; give them a visible clock and they patch themselves.