microsegment.io

segment all the things

The Math Nobody Wants to Do

March Patch Tuesday: 84 vulnerabilities. Including two zero-days already under active exploitation.

February: APT28 was exploiting CVE-2026-21513 in MSHTML before the patch even shipped. A Russian state-sponsored group had your number before Microsoft did. Source

Every month, the same ritual plays out across enterprise IT:

  1. Vendor drops patches
  2. Security team triages
  3. Testing begins
  4. Change advisory boards convene
  5. Deployment rolls out in waves
  6. Stragglers get chased down
  7. Next Patch Tuesday arrives

Repeat forever.

That’s not strategy. That’s a treadmill.

The Numbers Tell the Story

Cisco Talos reports that 40% of all intrusions in Q4 2025 came through exploited vulnerabilities. Not phishing. Not stolen creds. Unpatched flaws.

Rapid7’s 2026 Global Threat Landscape Report reveals the median time from vulnerability disclosure to CISA KEV inclusion dropped from 8.5 days to 5.0. Oracle EBS and React2Shell were weaponized within hours. Source

Hours.

Now look at the other side of the equation:

  • Attackers automate exploitation via patch diffing in 24-48 hours
  • Responsible patch management requires testing cycles of 1-2 weeks
  • The median enterprise patch time across all vulnerabilities is 60+ days

The structural gap between exploit availability and patch deployment is growing, not shrinking. You’re not falling behind. The game was rigged from the start.

Why Patching Alone Can’t Win

Don’t get me wrong - you absolutely need to patch. Patching reduces your attack surface, removes known entry points, and is a baseline hygiene requirement for any security program.

But if patching is your primary defense, you’re betting everything on perfect execution with zero margin for error.

Consider:

  • Zero-days exist. APT28 exploited MSHTML before the patch shipped. No patch cycle in the world helps when the patch doesn’t exist yet.
  • Testing takes time. Production environments can’t absorb untested patches without risking outages. Every day of testing is a day the attacker has access.
  • Coverage is never 100%. Shadow IT, legacy systems, OT environments, third-party appliances - there are always systems outside your patch management reach.
  • Prioritization is imperfect. CVSS scores don’t account for your specific environment. A “medium” severity vuln in a system with unrestricted network access can be more dangerous than a “critical” in an isolated segment.

The Question That Actually Matters

The real question isn’t “how fast can we patch?”

It’s: “When the attacker exploits the vulnerability we haven’t patched yet - what stops them from moving laterally?”

This is where architecture takes over from operations.

Microsegmentation as Patch Insurance

Think of microsegmentation as insurance for the patches you haven’t deployed yet - and the vulnerabilities you don’t know about.

When a vulnerability is exploited on a segmented network:

  1. The initial compromise is contained. The attacker gets a foothold on one system, but that system can only communicate with a defined set of other systems on specific ports. The rest of the network is unreachable.

  2. Lateral movement requires additional exploits. In a flat network, one exploit gives you the run of the environment. In a segmented network, the attacker needs to find and exploit vulnerabilities in each adjacent segment. That’s exponentially harder.

  3. Dwell time becomes visible. When traffic patterns are constrained by policy, anomalous connections stand out. An exploited system trying to reach systems it shouldn’t creates detectable signals.

  4. The blast radius is architecturally bounded. Even in the worst case - a CVSS 10.0 unauth RCE - the damage is limited to what that system can reach. In a flat network, that’s everything. In a segmented environment, that’s one segment.

The Practical Reality

Nobody patches perfectly. Nobody patches fast enough. And the gap between attacker speed and defender speed is accelerating, not closing.

The organizations that survive aren’t the ones that patch fastest (though fast patching helps). They’re the ones where an unpatched vulnerability doesn’t give the attacker the keys to the entire environment.

Patch what you can. Contain what you can’t.

That’s not resignation. That’s architecture.

The Numbers in Context

Let’s put this in practical terms:

Metric Time
Vulnerability disclosure to weaponized exploit Hours to days
Median time to CISA KEV inclusion 5 days
Responsible patch testing cycle 1-2 weeks
Median enterprise patch deployment 60+ days
Time for attacker lateral movement (CrowdStrike 2026) 27 seconds

That 27-second number from CrowdStrike’s RSAC presentation is the one that should keep you up at night. Once the attacker is in, they can move laterally in under 30 seconds. Your patch cycle doesn’t help at that point. Your architecture does.


This is the second installment in the Hard Truths series. The first covered why your security tools are the attack surface. Originally published as a LinkedIn post.

Hard Truths. No filter.