Patched is not protected: the reboot gap
A machine can be 97% compliant and still carry dozens of patches that are installed but not in effect. The number that matters sits in a different tile.
Patch compliance reporting has a comfortable lie built into it. A patch is marked installed the moment the installer finishes writing files, and on Windows a great many patches do nothing at all until the machine restarts. The kernel is still the old kernel. The driver is still the old driver. The compliance percentage has already moved.
Nobody set out to build it that way. Installed is easy to measure and in effect is not, so the industry measures the easy one and reports it as though it were the hard one. Then a quarterly review shows 97% and everyone moves on.
Two true numbers about the same machine
This device is at 96.7% compliance, which by any normal report is a healthy machine.
407 installed out of 421. One missing. That is where the percentage comes from and there is nothing wrong with the arithmetic.
Now read the bottom right tile. 78 patches, 19% of the machine, sitting in Reboot Pending. Those are counted as installed, because they are, and they are not doing anything yet. The gap between the compliance figure and the security posture of this box is those 78 patches, and it will stay open until somebody restarts it.
The Reboot Pending chip next to the hostname is the same fact stated as a status rather than a count. I have come to think of it as the more honest headline of the two.
One more tile while we are here: 12 failed, at 3%. Failed patches deserve their own post and are not getting one now, but a compliance number that quietly averages them into the total is doing you a disservice too.
Reboots are a people problem wearing a technical hat
Everything above is easy to fix technically. You restart the machine. The reason 78 patches are queued is not that restarting is hard, it is that the machine belongs to someone who is using it.
So the interesting question is not how to force a reboot. It is how to find out whether forcing one right now would interrupt a person, before you do it.
That yellow strip punches above its weight. It is not a permission prompt and it does not stop anything. It tells you that a person is currently signed in, at the moment you are about to act, on the screen where you would act.
The version of this that goes wrong is familiar to anyone who has run patching at scale. A maintenance window opens at 22:00, a script runs, machines restart, and on Monday there are three tickets from people who were mid-shift because their team works nights and nobody told the patching system. The information needed to avoid that existed on the machine the whole time. It just was not surfaced anywhere the person pressing the button would see it.
Every deferral gets an expiry date
The other half is what happens when the answer is “yes, someone is using it”.
Reboots become tracked requests rather than fire-and-forget commands. A request carries a type, and the set of types is the interesting part: schedule it for later, defer it to a date, force it now, notify the person at the keyboard and let them decide, or suppress it entirely. Each one records a status, a scheduled time, a deferred until date, who asked, and when it completed.
The notify path is the one worth dwelling on, because a request also carries a short reason string that can be shown to the end user in the on-device prompt. That turns “your computer will restart” into “your computer will restart, and here is what for”, which is the difference between an interruption people tolerate and one they file a ticket about.
A note on the screenshots: the recording this post is built from has an empty reboot queue, so there is no capture of that table with rows in it. Describing the fields seemed better than showing an empty state and implying otherwise.
Deferral needs to be a first-class record because it is the step where patching programmes usually decay. Somebody defers a restart for a good reason, the deferral lives in a chat message, and four months later that machine has 78 pending patches and no one remembers why. A deferral with an expiry date is a decision. A deferral without one is just an absence.
What the list tracks per patch
Underneath the summary is the per-patch view, and it is worth a look mostly for the columns.
Type is the column I would sort by. Defender definition updates, cumulative security updates and driver updates fail in different ways, need different approvals and carry very different reboot implications, and treating them as one undifferentiated pile of patches is how a driver update ends up in an emergency change.
The size column earns its place for a similar reason. A 1.4 GB update across a few hundred machines is a bandwidth plan rather than a checkbox, and knowing that before the window opens is the difference between a clean night and a queue of half-patched machines.
The number I would actually report
If I were writing the monthly patch summary, I would report installed and reboot-pending together and never one without the other. Not because the compliance percentage is wrong, but because on its own it answers a question nobody was really asking.
The question was never “did the installer run”. It was “is this machine exposed to the thing the patch fixes”, and for a large fraction of Windows patches the answer stays no until it restarts.
We have written before about reducing user impact during maintenance windows and about patch management as an ongoing programme rather than a monthly event. This is the piece that sits between them: the machines you already patched, waiting on the one action that makes it count.
Two servers, free forever. Sign up at app.lynxtrac.com if any of this resonates.
Related posts
Patch management without the pain: a modern IT playbook
Patching is the single most delayed task in IT, for good reasons. Making it feel routine rather than an event is less about tooling than a handful of deliberate process changes.
Ad-hoc scripts still need a paper trail
SSH in, run the fix, close the terminal. It worked, and six weeks later nobody can say what happened. What a script library and a recorded run change about that.
A release is not finished when it is applied
Most deploy tooling ends at apply. A release worth trusting has a verify stage after it, a rollback that is a button, and an approval that is not one person's judgement.