Patch Less

More bugs, found faster

#

In 2025, 48,185 CVEs were published, about 21% more than in 2024. That’s roughly 130 a day, with a clear preference for Tuesdays. Not all of them are your problem. The biggest single source was a company that reports WordPress plugin bugs, and I’m fairly sure nobody runs WordPress on their CEO’s laptop.¹

The direction matters more than the number, and AI is pushing it from both ends. Google’s Big Sleep agent reported its first 20 vulnerabilities in August 2025, mostly in FFmpeg and ImageMagick. Those aren’t exotic projects. They sit inside a lot of desktop software your users run every day. On the other end, Mandiant’s M-Trends 2026 estimates the mean time to exploit at minus seven days. On average, exploitation now starts before the patch exists. And according to the Verizon 2026 DBIR, organisations took a median of 43 days to fix vulnerabilities, up from 32 the year before.

To be fair to the numbers: a lot of that exploitation hits edge devices like VPN gateways, firewalls and WAFs, and internet-facing servers, not the PDF reader on a user’s device. And counting CVEs helps nobody. If you prioritise by known exploitation, with the CISA KEV catalogue or the exposure view in Defender Vulnerability Management, most of the noise is gone already.

But prioritising only helps if you can act on the result. For your browsers and Microsoft 365 Apps, that’s largely solved. For the long tail of third-party software on user devices, it often isn’t. PDF tools, conferencing clients, runtimes, and that one tool someone installed for a project in 2019. That long tail is what this post is about.

Packaging isn’t where the time goes

#

When third-party patching is slow, packaging usually gets the blame. Someone has to download the new version, wrap it, write a detection rule, test install and uninstall, and publish it. That’s real work, it grows with every app in the portfolio, and it’s exactly what third-party patching (TPP) tools take away.

In the estates I’ve worked in, packaging was rarely the slow part. The slow part came afterwards.

The new version goes to a pilot ring. The pilot ring belongs to business testers, and business testers have a day job. A week later nobody has said anything. Is that a good sign, or did nobody open the app?

IT is now stuck. You can push the update to everyone without real feedback, which quietly accepts a business risk on the business’s behalf. Or you wait for a reply that may come after the next quarterly close, which quietly accepts a security risk instead. Either way, someone made a risk decision, and it probably wasn’t the person who owns the risk.

Faster packaging doesn’t solve that. It just makes the queue in front of the pilot ring longer. What helps is agreeing with the business, before anything breaks, how long a ring lasts and what silence means. For most apps, something like three working days in pilot, and no reported issue means go. For the few apps where that isn’t acceptable, the business names a tester who actually has time for it. That list should be short, and I’ll come back to it below.

The cheapest patch is the app you removed

#

Every app on a device is a patch stream you’ve signed up for, forever. You can automate that stream, but you can’t make it free. Removing the app is the only option that brings its cost to zero, and it’s the one I see used least.

Start with an honest inventory. Intune’s discovered apps and the software inventory in Defender Vulnerability Management will both tell you more than you want to know. Then go through the usual suspects.

Browsers. Edge is there anyway. Is Chrome on every device because a business app needs it, or because people installed it in 2018 and nobody asked? Each extra browser brings its own release cadence, its own policy set and its own extension store to govern. If one web app really needs Chrome, give Chrome to the people who use that app.

Archive tools. Windows 11 has opened RAR, 7z and tar archives natively since version 23H2, using the open-source libarchive library. Meanwhile, both classic archive tools landed in the CISA KEV catalogue in 2025: 7-Zip with a Mark-of-the-Web bypass, CVE-2025-0411, and WinRAR with a path traversal flaw, CVE-2025-8088. Neither updates itself silently, so they stay vulnerable until somebody patches them. The catch is that the built-in support can’t handle password-protected archives. If a team exchanges encrypted archives with a partner, they keep a tool. Everyone else probably doesn’t need one.

PDF tools. Edge reads and annotates PDFs. Acrobat is still the right tool for people who fill complex forms or sign documents for a living, and that’s usually a much smaller group than the install count suggests.

You get the gospel, right?

None of this is technically hard. The hard part is ownership. An app without a named business owner has nobody to ask whether it’s still needed, nobody to test it, and nobody to say no when it should go. A simple rule helps: no owner, no app.² It also gives you the short list of testers from the previous section for free.

Automation, and the keys that come with it

#

Whatever survives consolidation still needs patching, and for most of it automation is the only realistic answer. TPP tools watch vendor releases, package them and publish them to Intune. Microsoft’s own Enterprise App Management does the same from a curated catalogue, with a target of 80 to 90% of updates available within 24 hours. Since July 2026 it’s included in Microsoft 365 E5, which changes the buying conversation for a lot of organisations.

The price is a new link between the software vendor and your devices, and whatever comes through it installs as SYSTEM everywhere. I’ll look at the identity side of that in the next post: which permissions such a tool needs, which ones I wouldn’t grant, and why a vendor-held credential is a different risk from your own. Here I only want to add the supply-chain side.

Supply-chain incidents don’t all look alike, and a patching pipeline helps against some of them and not others. When 3CX shipped a trojanised but properly signed installer in 2023, every check passed, and a fast pipeline would only have delivered the problem quicker. When the Notepad++ updater was hijacked in 2025, a central pipeline with the in-app updater switched off would have protected you. And the trojanised KeePass builds that WithSecure found reached people through malicious search ads and look-alike domains, which a catalogue sourcing from the official URL avoids. So a patching tool moves risk around as much as it adds it, and it concentrates what’s left in one place.

Enterprise App Management has one limit worth knowing before you switch on auto-update. Microsoft states plainly that there are no rollout rings: a new version goes to all targeted devices at once, and there’s no rollback. If Microsoft finds a malicious version, it removes it from the catalogue and notifies you, but finding and fixing the affected devices is your job. You can use the guided supersedence workflow instead and review each update first, which brings you straight back to the ring problem from above.

From an effort question to a risk question

#

The TPP discussions I’ve been part of were mostly about effort and money. How many packaging hours do we save, what does the licence cost, at what portfolio size does it pay off? Reasonable questions, and once the portfolio is big enough, the answer is usually yes.

That calculation leaves out the part that has changed. Bringing in TPP is now a risk decision in both directions. Without it, you accept that some apps stay vulnerable for weeks, in a world where exploitation starts before the patch. With it, you accept a new, concentrated delivery channel to every device you own. Neither risk is zero, so somebody has to decide which one they’d rather carry, and for which apps.

Gartner’s 2027 Planning Guide for the Digital Workplace proposes four update tiers for this (Table 1, “Application Update Tiers”), and I find them a useful starting point. Here’s how I’d place common applications in a Swiss bank. Open a row for the details.

Tier 1 is for apps where the vendor’s own auto-update is faster than anything you could build: browsers, conferencing clients, the WebView2 runtime. You can’t stage the new Teams anyway, so write it down as a vendor-managed exception instead of pretending otherwise. Tier 2 is the long tail of utilities, where a TPP tool, a 24 to 48-hour canary ring and the silence-means-go rule from earlier do the job. Tier 3 is core business software, which goes through deployment rings while telemetry watches for problems.

Tier 4 is where a broken update stops a business process. On the 30th of the month, Adele Vance, the bank’s endpoint engineer, gets a call from finance. Their consolidation model relies on an Excel add-in, the latest Microsoft 365 Apps build broke it, and the month-end close is slipping. Nobody was hacked, and the impact is still real. That add-in also reads the most sensitive numbers in the building, which makes it an attractive target for a supply-chain attack. Business impact and data sensitivity tend to point at the same apps, which is convenient. It also shows how one Tier 4 dependency can slow down a whole Tier 3 suite.

Tier 4 apps still get updated, just deliberately: tested by a named person from the business, with an agreed deadline and a maintenance window. Some are outside your control entirely, like market data terminals that the vendor updates on its own schedule. Those go on the exception list too.

Keep Tier 4 short. If a third of your portfolio ends up there, that’s the old process again, with an extra licence on top.

You’ll still be late sometimes

#

A smaller portfolio and a fast pipeline won’t make you fast enough every time. If exploitation starts before the patch exists, there are days when nobody is on time. So the other half of the job is limiting what a late patch can cost you: attack surface reduction rules, App Control for Business, and stricter settings on the devices that matter most, even when users notice. Those controls come with real user impact, and they deserve more than a paragraph at the end of this post. I’ll come back to them in a separate one.