Back in June I wrote a piece over on the Patch My PC blog about the [Five Eyes joint statement](https://patchmypc.com/blog/five-eyes-intelligence-alliance-says-its-time-to-speed-up-patching/) you know, the one where five national cyber agencies got together and, among other things, told everyone to patch their computers. I've been stuck on something ever since, something that after a number of conversations with people in the industry is really starting to haunt me. >[!Quote] >"If your patch management process requires a week of testing on average, you're living with 97 vulnerabilities. For every week that goes by after, every machine that fails to patch has another 97 vulnerabilities for a single application. This. Ends. Poorly." I don't think I pushed the idea far enough. We all know updates will come and they either will or wont have vulnerabilities. What I want to focus on is what happens when your time to compliance is longer than the vendor's time to next release, and the challenges of N-1 based patching. ## We've debated patch cadences for years what changed? When writing that article for work, I pulled Chrome's security fix counts in the months leading up to the Mythos release, and then the months following. Here's what it looked like: | Window | Days | Security fixes | | ------------------- | ---- | -------------- | | 20 Jan – 6 Apr 2026 | 77 | ~117 | | 7 Apr – 23 Jun 2026 | 78 | ~1,074 | That's about nine times the fixes with ~400 of them in a [single build on June 2nd](https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop.html). That second window works out to roughly **13.8 security fixes per day**, every day, in one browser. ## Math is hard, hates you, and says screw you I think this gets skipped in every patch-management conversation I've ever sat in on. There's a piece of queueing theory called Little's Law: >[!Note] Little's Law >**L = λW** > >The average number of items in a system equals the arrival rate multiplied by the average time each item spends in the system. If you start to plug in some familiar numbers, around patching and, well it becomes uncomfortable fast: **Your Vulnerabilities = (vulnerabilities arriving per day) × (days to reach compliance)** Your organizations risk is not just a function of how hard your team works, how good your tooling is or how risky taking down your infrastructure is. It's the arrival rate of vulnerabilities times your cycle time, and you only control one of those two. ## Example of what it looks like with real-ish numbers Below is chart to showcase the difference between the industry average, and what the goal times of an organization that is "COMPLIANT" with the PCI-DSS critical window an the CISA-BOD requirements, of note though is that this chart treats all vulnerabilities equally. Those frameworks do not. In the world of AI - almost all vulnerabilities should be treated equally due to the ability of vulnerability chaining. ![[vulnerability_chart.png]] >[!Danger] Reminder Attackers are Lazy >Remember, attackers are lazy shits just like you and me. If I'm an attacker I know which company I'm going to chase after, based on this chart. The one that's closest to Industry MTTR. > | Your time to compliance | Carried vulnerabilities | Where that number comes from | | ----------------------- | ----------------------- | --------------------------------------------- | | 3 days | **41** | CISA BOD 26-04, issued 10 Jun 2026 | | 7 days | **96** | A "fast" internal testing cycle | | 30 days | **413** | PCI DSS critical-patch window | | 90 days | **1,239** | NIST 800-53 / FedRAMP outer bound | | 160 days | **2,203** | Industry MTTR for complex apps (Qualys, 2025) | Qualys benchmarked the average mean time to remediation for complex enterprise applications at **5 months and 10 days**. Not for obscure software for things like Java, .NET, and Citrix Workspace App. The stuff running your line-of-business apps. If your organization performs at the industry average, you are carrying roughly 2,200 known Chrome vulnerabilities at any given moment. Not because anyone was lazy. Because 13.8 × 160 = 2,203. Again, this chart is a little bit misleading because those other frameworks ONLY care about timelines of high severity vulnerabilities and you have to care about all of them now. ## Backlog versus divergence A **backlog** is a pile. It's finite. You can throw a weekend at it, hire a contractor, work it down to zero, and be done. **Divergence** is what happens when the input rate exceeds the service rate. There is no weekend that fixes it. The pile doesn't shrink, it grows, forever, at a rate set by the difference between the two. Chrome's stable channel ships roughly every two to three weeks, plus security and non stable releases. Call it 21 days between stable releases. - If you reach compliance in **7 days**, you finish each release before the next one lands. You're on a treadmill, but you're keeping pace. - If you reach compliance in **160 days**, you have roughly **7.6 releases in flight simultaneously**. You are never working on the current version. You are perpetually deploying something that was superseded five times over. That second state isn't "behind." It's a steady state of permanent non-compliance that produces compliance reports. >[!Warning] The uncomfortable reframe >Most organizations I've talked to think they have a resourcing problem. They have a cycle-time problem. Doubling your team doesn't help if your change process still takes 160 days, because the constraint isn't hands, it's calendar. ## Now multiply it Everything above is one application. Go count what's actually installed on your endpoints. Windows. Edge. Chrome. Firefox. Java. .NET. Visual C++ redistributables. Acrobat. Zoom. 7-Zip. Notepad++. Citrix. Your VPN client. Your EDR agent. Your line-of-business app and its three dependencies. Sixty to a hundred distinct products is normal for a corporate image. Each with its own release cadence, its own vulnerability count per release, and critically **its own time-to-compliance in your environment**, because the LOB app with the fragile installer takes twelve weeks and Chrome takes three days. Your total carried exposure is the sum across all of them. And August's Patch Tuesday alone 421 CVEs from Microsoft, 236 of those in Windows is a single line item in that sum. Acceleration of patches, is number two on the list for a reason. ## So what do you actually do The formula has exactly two inputs and you don't control the arrival rate. Which means every available move is a cycle-time move: 1. **Measure your actual time-to-compliance per application.** Not your SLA. Your observed p50 and p95. Most teams have never calculated this and are shocked by the p95. 2. **Automate the applications where testing adds no information.** Qualys reported that 40 million of the 150 million patches they deployed last year went out with no human in the loop. Chrome does not need a change advisory board. 3. **Find the applications with the worst cycle time and treat them as architecture problems, not patch problems.** If an app takes twelve weeks to patch, the app is the finding. If you want somewhere concrete to start pulling that data, I've written up getting vulnerability info straight out of Defender for Endpoint before: [[Query Defender for Endpoint Vulnerability Info Part 1]] and [[Query Defender for Endpoint for Vulnerability Info Part 2]]. Want a way to go faster without caring about it? Checkout a third party patch automation solution. Expediting your patches in an automated fashion is likely the fastest way to start driving remediation on your endpoints. >[!Warning] Disclosure >I'm Director of Security and IT at Patch My PC, and we sell third-party patch management. A post about patch cycle time is obviously convenient. Weigh it accordingly. ## Part 2 The math is the easy part. The hard part is, every organization knows this and does it anyway. Change-management, ITIL and other frameworks were all built around the idea that change, of any type represents risk. In Part 2 I want to get into why that framing persists, what it costs regulated industries specifically, and the part I think about most: what it does to the career of the individual technician who has to make the call. --- **Sources** - [Patch My PC — Five Eyes Intelligence Alliance Says It's Time to Speed Up Patching](https://patchmypc.com/blog/five-eyes-intelligence-alliance-says-its-time-to-speed-up-patching/) - [NSA — Five Eyes cyber security agencies statement, 22 Jun 2026](https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/4523810/five-eyes-cyber-security-agencies-statement/) - [Qualys — Enterprise Patch & Remediation Benchmark 2026](https://blog.qualys.com/qualys-insights/2026/04/20/enterprise-patch-remediation-benchmark-2026) - [Cloud Security Alliance — CISA BOD 26-04: AI threat forces 3-day critical patch mandate](https://labs.cloudsecurityalliance.org/research/csa-research-note-bod-2604-ai-accelerated-patch-mandate-ente/) - [Chrome Releases — Stable channel update, 2 Jun 2026](https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop.html) - [SecurityWeek — August 2026 Patch Tuesday: Microsoft fixes 421 CVEs](https://www.securityweek.com/august-2026-patch-tuesday-microsoft-fixes-421-cves-one-exploited-zero-day/) - [Barracuda — The Mythos Hype Index](https://blog.barracuda.com/2026/05/12/mythos-hype-index-ai-vulnerability-discovery)