Patch Compliance Is a UX Problem Wearing a Security Costume
Notes from the patching program I ran at Ontinue, 2025-26.
The constraint
Cyber Essentials says high-risk and critical updates get applied within 14 days of vendor release. OS and third-party apps, every in-scope device. There is no “reasonable cadence” wording anywhere in it. You either hit 14 days or you fail the control.
The problem
On a managed Mac the install is still user-consented. I can push, prompt, schedule and nag, but a person still has to click. Each third-party app ships its own updater with its own behaviour. A laptop that spent two weeks closed in a bag was unpatchable for those two weeks no matter what the policy said.
So the requirement is hard and the enforcement surface is soft. The job is closing that gap.
What I tried first
- Silent forced installs. It works once. Then a restart eats someone’s work in the middle of a meeting and you have spent the goodwill you need for every later rollout.
- Unlimited deferrals. Everyone defers, because today is always a bad day. Day 14 arrives with part of the fleet unpatched and you end up forcing the same restart you were trying to avoid.
- One mechanism for everything. OS updates and app updates fail for different reasons, so they need different handling.
What ended up running
Third-party apps are automated. App Auto-Patch covers the long tail of browsers, clients and utilities, so nobody has to notice an update badge. That is most of what the framework counts, which makes it the biggest win for the least friction. An extension attribute reads the AAP receipts back into Jamf, split into success and failure, so the report shows what actually installed instead of “policy ran”.
OS updates turned out to be a restart problem more than a download problem. An update that is staged but never restarted into is not applied, and a naive report will still call the device compliant. Several weeks of uptime is normal on a machine that only ever sleeps.
So the pressure is keyed to uptime, in tiers people can see coming. One swiftDialog script:
| Uptime | What the user sees |
|---|---|
| 6 days or less | nothing |
| 7-13 days | Restart or Defer, 15-minute timer, asks again in 24 hours |
| 14 days or more | no Defer. Acknowledge, then a 10-minute countdown and a restart |
Most people restart in the middle tier. Given a real choice and a visible deadline, they pick their own moment. The hard tier is there so the deadline is credible; it rarely fires.
Scoping uses smart groups on current OS and app version, so the set of devices needing a given patch is always current. The same groups drive both enforcement and the compliance report, which keeps the two from drifting apart.
Where it landed: compliance went from 82% to 98% across 300+ Macs.
What I would argue
Patch compliance usually gets framed as a security discipline and staffed like one. I think the hard part is elsewhere.
The technical levers for forcing an update have existed for years. The difficult bit is escalation that people find predictable and fair, so they update on their own terms inside the window instead of having a moment picked for them. That is a user experience problem. The framework only sets the deadline.
If you fight your users you get deferrals and workarounds, and every later rollout gets harder. If you give them a visible clock and a real choice of when, they patch themselves, and that is the only version of this that scales.