The hardest patching problem is not the patch
Microsoft just shipped the largest Patch Tuesday on record: 622 CVEs, three zero-days, two of them already being exploited.
After a career in Microsoft patching, I can tell you the harder question is a different one: deploy to what? The updates are the easy part most of the time with modern software, at least for the well know Microsoft patches and at least most of the time, well maybe not on servers but all the for a different time. Knowing which machines actually need them, and which machines quietly did not install them, is where folks get hurt.
There are three versions of this problem, and all of them like to hide.
A story I have never forgotten
Long ago, longer than I will admit, a bank did not properly patch a set of servers. An attack reached them, and once it did, nothing could stop it. The servers went down, and they stayed down. My team spent the recovery working shoulder to shoulder 7x24 with the customer, hand-rebuilding those machines one at a time. That is what recovery actually looks like when patching fails: not a console and a progress bar, but people rebuilding servers by hand while a business waits. This is something we all want to avoid.
Here is the part that stayed with me. Proper patching would have made those servers immune to that attack. The fix existed. And this was not a careless team; they were hardworking, dedicated people, the kind every one of us has worked beside. They still had a set of servers that missed the patch, and they paid for it in the hardest way. And I use that experience to this day when I create tech management software.
That story is old, but it is not history. It has repeated over and over across the decades, with new attack names and new server names and the same root cause every time. The problem has not changed, and it taught me the lesson this piece is named for: the unpatched machine is the one that gets you just like the miss configured one, that forgotten long gone admin who still has an account, or more likey their main account and the secret back up admin account maybe not using MFA just in case. But they left the company 2 years ago, the accounts did not, but this too is for another time. So its not the thousand you patched on time or the user audits you have done. The one that missed, the machine not running right so patches were not installed, that server setup for temp use that is on the internet unpatched and unmanaged somewhere on your network. Helping teams like that one prevents the next rebuild is, as plainly as I can say it, why we do this work.
The machines you cannot see
The first version is the machine that is not in Intune or Configuration Manager at all. It exists, it is on the network, it authenticates, it runs software, and it appears in no patching console anywhere. Nobody is deploying anything to it, and no dashboard is turning red about it, because dashboards only report on what they know.
These machines accumulate in every organization I have ever looked at. The lab server somebody stood up for a project that ended two years ago. The conference room PC. The box a vendor installed and manages “remotely.” The virtual machine that was cloned from a template and never enrolled. The laptop that was rebuilt by hand one urgent afternoon and never joined back to management. The old server everyone is afraid to touch because nobody remembers what it does, but it does something.
None of these machines are refusing patches. They were simply never invited.
This is worth saying plainly: Configuration Manager and Intune are excellent deployment engines, but they are not complete patch managers on their own. They cannot see a machine they are not on, so the machines most likely to be unpatched are exactly the ones they will never report. And servers are their own story: Intune is built for the client world, and if your servers are waiting for Intune to patch them, they are mostly still waiting. We have been working on this gap specifically, and there is more coming from Senserva on it soon.
The machines you can see that still do not patch
The second version is sneakier: the machine that IS enrolled, shows up in every console, and still is not patching. In my experience these are the usual suspects:
Pending reboots that never happen. The update installed weeks ago and is not protecting anyone, because the machine has not restarted. Servers with “reboot windows” that keep getting deferred are the classic case.
Broken update plumbing. A corrupted component store or a wedged Windows Update service fails every cycle, forever, until a human intervenes.
Disk space. Small system drives, packed with logs or profiles, silently fail updates month after month.
Conflicting management. Group Policy pointing at a dead WSUS server while Intune thinks it owns updates. The machine obeys the wrong master and gets nothing.
Paused or misassigned rings. A deferral somebody set during a bad week and never unset; a device sitting in a pilot ring that no longer exists.
Offline during the window. Laptops that sleep through every maintenance window, or field machines that only connect briefly on cellular or metered connections where updates do not download.
Safeguard holds and driver blocks. Microsoft itself holding an update back for a known incompatibility, invisibly, while the console shows green everywhere else.
Out of support. Versions past end of servicing that will never get another update no matter what deploys to them. They cannot patch, and unless you track lifecycle dates, nothing tells you.
Long Turned off Old PC that just rejoins the work via the airport lounge.
Every one of these produces the same dangerous condition: a machine everyone believes is patched, and is not. A patch you shipped is not the same as a patch that landed.
The patches nobody knew about
The third version is the one that stings the most, because no machine and no console is at fault: the patch nobody knew existed. Out-of-band emergency fixes that ship on a random Wednesday, like the July 9 fix this month, do not wait for your Patch Tuesday routine. Server products like Exchange, SharePoint, and SQL Server follow their own update paths and quietly sit outside the rings that handle Windows. A fix gets re-released with a new KB and the old one you deployed no longer counts. If your process is “we deploy what the console offers on the second Tuesday,” everything in that gap is invisible, and this month one of the actively exploited zero-days lives exactly there, on SharePoint servers.
You cannot deploy what you never heard about. Awareness is part of patching.
We all know how this story ends
I will not pretend anyone reading this needs convincing, but a reminder never hurts, because the biggest incidents of the last decade were mostly not zero-day wizardry. They were unpatched machines.
WannaCry tore through hundreds of thousands of systems in 2017 using a vulnerability Microsoft had patched two months earlier; the victims were the machines that had not installed MS17-010. Equifax was breached through a web framework vulnerability with a patch available for months. The 2021 Exchange Server attacks turned into a global cleanup operation precisely on the servers that had not applied the fixes. And this month, one of the two exploited zero-days is a SharePoint Server vulnerability, which means o
n-premises servers that lag on updates are once again the target of choice. In the patch world 2017 is not that long ago, old machines keep on running.
The pattern is boringly consistent: attackers do not need to beat your patching process. They need to find the machines your patching process never reached.
Once you can see it, you can fix it
Here is the encouraging part: this is a visibility problem before it is a patching problem, and visibility problems are solvable. The moment you have a trustworthy list of machines that are not patching, and the reason, the fixes are usually mundane: enroll the unmanaged box, schedule the reboot, clear the disk, repair the update service, fix the conflicting policy, retire the unsupported version. None of it is glamorous. All of it closes real attack surface.
This is exactly what we built our product for. Siemserva by Senserva scans your patch state straight from Intune and Defender (with Windows Autopatch and Azure Update Manager data too). It is quick to set up, and it reliably surfaces the machines that are not patching properly, ranked by what attackers are actually exploiting, so the scariest gaps come first. The demo runs without registration, and scanning your own tenant takes a free registration: https://senserva.com/quickstart.html
Patching by priority: the way we think it should work
Here is the vision we have organized Senserva around, and where we intend to change the market. At 622 CVEs in a single month, “patch everything immediately” is not a strategy, it is a wish. The strategy that actually works is priority-based patching driven by market conditions: patch what attackers are exploiting first, then what they are most likely to exploit next, then the rest on your normal cadence, and always against a device list you actually trust. That applies to Microsoft and beyond. The doctrine fits in one sentence: keep up as you can, but avoid the crisis first.
That means the order is set by evidence, not by fear or by raw counts: confirmed exploitation (CISA KEV) at the top, exploit probability (EPSS) next, then Severity and your own exposure. It also means awareness is built in: the out-of-band fixes, the server products outside the rings, and the re-released updates all surface in the same ranked view instead of hiding between Tuesdays.
We have put a serious amount of effort into making that priority view available to everyone, because CVEs, KBs, EPSS, KEV, and Severity bands form a fog of jargon that keeps smart people from acting. Every one of these pages is free, no sign-up, refreshed three times a day:
The Patch Tuesday page: every release, every update, the zero-days by name, the out-of-band fixes, the trends and the history, plus the voices of the other trackers we read ourselves. https://senserva.com/patch-tuesday.html
The Microsoft patch tracker: every update (KB), ranked by real-world risk, so the deploy order is already worked out. https://senserva.com/microsoft-patch-tracker.html
The Microsoft CVE reference: 13,000+ vulnerabilities, each tied to the update that fixes it, each with its own plain-language page: what it is, whether it is exploited, and how to fix it. https://senserva.com/microsoft-cve-vulnerability-management.html
Exploited this week: what CISA confirmed attackers are using right now, the top of every priority list. https://senserva.com/exploited-this-week.html
Senserva Live: the whole picture on one page. https://senserva.com/security-dashboard.html
If those pages help you decide what to patch first, they have done their job. And if you want to know which of your machines did not get the memo, that is the part we would love to show you.
The count is never the story. The story is the machines that missed it, the patches nobody knew to send, and whether the ones being exploited right now are at the top of your list. A bank taught me that a long time ago, and every headline since has agreed: the unpatched machine is the one that gets you.