Four architectural bets and five things you can finish before the next patch wave
In my last post, I argued that this summer’s patch wave exposed an assumption most security programs were built on: that we have time between a vulnerability’s disclosure and its exploitation. That time is gone. Exploitation is measured in hours, remediation in weeks, and effort alone won’t close that gap.
Back in July, the whole conversation, mine included, was about velocity: Move faster, patch faster, shrink the window. That was the right alarm, and I'd raise it again. But two months of watching this play out has made the limit clear. Speed was only ever half the sentence. You can be the fastest team in your sector and still lose a step some nights. So the honest advice is to patch faster and build so that when you lose that step, you lose a little instead of everything.
Get that right and a patch you miss becomes an incident you contain rather than a headline you explain. The whole point is to make sure no single failure is ever a total failure.
Where I’d put the money: Four architectural bets
The teams that stopped reacting didn’t simply resolve to patch faster. They made a handful of deliberate architectural bets. When a client asks where to spend now, these are the four I push hardest. Each one shrinks the blast radius rather than just shortening the queue.
Segment like you already assume a breach
Flat internal networks are the single biggest reason a small compromise becomes a company-wide one. Microsegmentation and a real zero-trust posture inside the perimeter are no longer a maturity nice-to-have. They are the control that decides how far an attacker gets on the day one of your patches is late. It’s the direct, physical answer to the blast-radius question, and it’s the work I would start before anything else on this list.
Put AI on the defensive side, deliberately
Attackers closed the speed gap by handing slow, mechanical work to machines. We can’t answer that with human hours alone. Agentic detection and response that triages the flood, correlates signal, and cuts your time to notice and act isn’t about replacing your people. It’s about matching machine speed with machine speed, so your analysts spend their judgment on the decisions that need a human rather than drowning in a queue.
Prioritize by reachability, not raw severity
Patching down a list sorted by CVSS score is exactly the model this summer broke. Prioritize by what’s exposed and chainable to something you can’t afford to lose. A medium on an isolated box can wait. Two mediums and a misconfiguration that together form a path to your crown jewels cannot, and no severity score will tell you that. Your program has to reason about paths, not just parts.
Measure your blast radius instead of guessing
Tooling to continuously map attack paths and safely simulate a breach now exists. It’s the difference between believing your segmentation works and knowing it does. I would prefer a client find the open path in a Tuesday-afternoon exercise than have an attacker find it on a Friday night. Rehearse the failure on your own terms, before someone else schedules it for you.
Notice the thread. None of these is about patching faster; they’re all about making sure that when a single thing fails, and it will, it fails small.
The clock is the easy part
Regulators are pushing in the same direction regardless of jurisdiction: new reporting obligations with tighter windows for raising your hand after an incident. The clock is the easy part. The hard part is the capability underneath it: knowing what happened and deciding what to do fast enough to say anything truthful inside that window. That takes far longer to build than the compliance document does, and the time to start building it is before the clock starts.
Most teams are simply too small for the surface they defend. When a July hits, the first thing to run out is hours, not knowledge. That’s the honest case for co-management, which is what we do. Keep the judgment, context, and authority in-house, where they belong; let a partner carry the volume and after-hours weight. That way, your people are making decisions at 3 a.m. instead of triaging a queue.
What to do in the next 30 days
You don’t need a fancy-looking strategy deck. You need steps you can start tomorrow and finish inside a month. Most are about knowing your environment rather than buying anything:
- Prove your inventory on a small scale. Take your 10 most exposed Internet-facing systems and confirm owner, version, and support status for each. Include collaboration, identity, and virtualization platforms, not just network gear. The finding you least want (and are most likely to get) is that one went end-of-life and nobody noticed.
- Draw the blast radius for your top five systems. One page each, one question: If this is compromised tonight, what else can the attacker reach? That page is worth more than most risk registers, yet very few organizations have one.
- Make the emergency path real and name it. Decide who can approve an out-of-cycle change at midnight, tell them plainly that they hold that authority, then walk the path once against a same-day clock. With this approach, you find the friction before an attacker does.
- Teach triage to see chains. Two medium findings and a tolerated misconfiguration on the same host aren’t three small problems. They’re one serious one, and no single scanner will reliably add them up for you. Someone who understands the paths has to.
- Change one number you show the board. Put how long we stayed exposed and how far it could have spread next to how many patches we applied. The first honest version of that slide is uncomfortable. (That’s the point.)
The window closed; the posture is still open
The wave was survivable, and most of our clients came through it. But a lot of well-run programs walked out of July having learned something they didn’t want to know: They had been running for years on an assumption about time that had stopped being true. The good news is that this problem, unlike the threat landscape itself, is entirely within our own control. This is where I’d put your energy.
If you want to pressure-test your patch cadence, your emergency authority, or the assumptions buried in the numbers you report upward, this is work our teams do every day across financial services, retail, manufacturing, healthcare, the public sector, and utilities, often for organizations running one environment across more than one jurisdiction. Reach out to initiate a conversation, If you’re attending the Banff Cyber Summit, November 3–5, come hear Ryan Hamrick, OnX Senior Director of Cybersecurity, speak about what it takes to build a security operating model for a world where critical vulnerabilities can be weaponized in hours - not days. Ryan will share how OnX translated the Cloud Security Alliance’s “AI Vulnerability Storm” into an operational response model spanning patching, SOC, compute and network, including what worked, where the model met resistance, and what organizations should be pressure-testing now.
And while you’re there, be sure to stop by the OnX booth to connect with our team.