Most of the time, I didn't break into a network so much as let myself in through something with a fix already out (just not installed yet): the VPN concentrator three versions behind, the firewall with a known vulnerability fixed eight months earlier, the internet-facing server still answering on a port nobody remembered opening.

I rarely needed to fool a person. I only needed one unpatched thing facing the internet, and there was almost always one.

For the first time in the 19-year history of the Verizon Data Breach Investigations Report, exploitation of vulnerabilities is the single most common way attackers get their initial foothold. It accounts for 31% of breaches, up from 20% the year before. A single vector climbed eleven points and grew by 55% in one year.

Findings in this report tend to move like a glacier. This one moved like a flash flood.

Why Credentials Held the Top Spot for Two Decades and Why They Just Lost It

The finding it overtook was no soft target. For most of the report's 19-year history, stolen credentials sat at the top, and they held that ground through a fight that never let up. Attackers spent those years getting better at stealing a valid login, and doing it for cheaper: more convincing social engineering, automated password guessing tuned to slip under lockout thresholds, ways to bypass multi-factor authentication, tools to steal login tokens. Every advance on their side pulled a countermeasure out of ours. We built an entire industry around protecting the login because the login kept turning out to be the way in. Year after year of that back-and-forth, and credentials never once surrendered the top spot.

All of it, every layered control and every hard-won lesson, overtaken in a single year. The landscape doesn't lurch like that on its own. Something underneath it gave way.

None of this means the last two decades of security work were wasted. We hardened the perimeter enough that attackers mostly stopped trying to climb the wall and went after the people holding keys instead. Mature organizations followed the threat where it led and made identity the center of the program, because that's where the breaches were coming from. That was the right call.

The Verizon report didn't say identity stopped mattering. It said the weak point moved again, and this time it moved back toward the walls we thought we'd finished building.

The Front Door Attackers Are Walking Through Right Now

This is initial access we're talking about. The very first step in, before an attacker has laid a hand on anything inside. The services taking that 31% are the ones facing the internet, and increasingly they're the edge devices: firewalls, VPN gateways, the security appliances bolted to the perimeter. Think of these as the front doors of a network. The report puts edge devices and VPNs at 22% of vulnerability-exploitation breaches this year, up from 3% the year before. A sevenfold jump to the single category of equipment that's hardest to patch. The fix waits on a vendor. The box can't just be rebooted at noon. And half the time nobody's sure who owns it.

The Patching Gap Is Widening at the Worst Possible Moment

The obvious move is to patch the internet-facing things fast. The uncomfortable part is that the gap between knowing and doing is widening, not closing.

The Verizon report states that the median time to fully fix a vulnerability stretched from 32 days to 43 over the past year. Eleven extra days sounds minor. But set those 43 days beside the other trend, where serious vulnerabilities now get exploited within days of going public, and you can watch the two lines cross. The time to fix is opening up exactly as the time to get hit slams shut.

Most of that widening isn't anybody's decision. It's volume. Organizations faced 50% more entries on CISA's Known Exploited Vulnerabilities catalog this year than last. This catalog is essentially the government's official list of vulnerabilities being actively used in real attacks right now, the ones that need to be fixed immediately. Only 26% of those critical, actively-exploited flaws got fully patched, down from 38%. That's the same set of hands bailing a boat that takes on water faster every quarter.

AI didn't create new classes of vulnerabilities, but it removed the friction that used to slow everything down. Finding a bug used to be slow, and writing code used to be slow enough that human review could keep pace; AI removed both rate limits at once.

Attackers find bugs faster, and unreviewed AI-generated code ships fresh vulnerabilities into production faster than anyone can catalog them. Using AI to speed up triage and sharpen prioritization is the right call. Skipping code review because the machine sounded confident is how you become next year's data point.

The Supply Chain Fear Is Real. It Still Doesn't Change the Math.

There's a second part of the gap, smaller and entirely voluntary. On partner calls and in professional groups, there's a quiet sense that with so much going wrong in the software supply chain, the safer move might be to slow down on patching deliberately. The instinct is understandable. Attackers have been stealing the credentials of legitimate software maintainers and hiding malicious code inside official, signed updates. TeamPCP has been running exactly that play since late 2024, targeting the developers and vendors behind the tools people rely on every day, with stolen credentials still being spent against fresh victims.

The fear has a name: 3CX. In 2023, the company shipped a legitimate-looking desktop app update carrying malware the entire way. The organizations that took the update promptly, the diligent ones doing exactly what the industry preaches, are precisely who let the attackers in.

The fear is fair. It still doesn't survive the arithmetic. 3CX is the exception you remember because it's rare, one poisoned build against millions of clean ones that shipped the same year. On the other side of the ledger sits a known-vulnerable, internet-facing service that's public, documented, and often already on the government's must-fix list with a remediation date behind it. One is a low-probability event you'd have to get unlucky to hit. The other is a door propped open with a sign on it.

Somewhere in the middle of all this, "let me verify this before I deploy it" quietly climbed into the same trenchcoat as "let me hold off on deploying it," and the two started passing themselves off as one responsible adult. Only the top half is doing any real work. The bottom half is negligence in a borrowed coat, and it's been getting waved through as caution.

The Practical Response to the Volume Problem

You're not going to stop patching. And you can't out-work the volume by hand, because 50% more must-patch vulnerabilities landing on the same-sized team isn't a motivation problem. That leaves three levers worth pulling.

Make the fast path safe. "Patch fast" might be the two most nerve-racking words in IT operations, and the flinch is earned. Fast-done-badly looks like an unverified update shoved out to everything at once on pure optimism. Fast-done-well looks like staged rollouts. A small test group gets the patch first and gets watched closely, and the rest of the systems follow in hours rather than weeks. If something breaks or turns out to be malicious, only a handful of machines are affected instead of everything at once. That's the difference between an incident and a catastrophe.

The decision to trust an update also belongs in an automated process, not in the head of a tired administrator on a Friday afternoon. Systems should be able to confirm on their own that a patch is the real, untampered article before it installs, the same way you trust a sealed bottle with the safety band intact without interviewing the factory that filled it. Once that check is automatic, the supply chain fear stops being a reason to wait.

Aim your effort at what's being exploited. With more must-patch vulnerabilities than hands to fix them, treating the queue as a flat list is how you lose slowly. CISA's Known Exploited Vulnerabilities catalog exists so you can patch what's being actively used in attacks right now and let the theoretical stuff wait its turn. The things getting exploited skew hard toward internet-facing systems, so patching what's exploited and patching what's exposed are largely the same short list.

Shrink the pile. The outdated appliance nobody's updated in years, the vendor who's gone dark, the service nobody remembers turning on. Every one of those you decommission or switch off is a patch you never have to apply and an attack surface that no longer exists. Nothing exploits a service that isn't running.

The Pattern Is Clear. The Response Has to Match It.

The services attackers walk in through are almost never exotic. They're the ordinary, well-documented, patch-has-existed-for-months services that someone once looked at, weighed against the hassle of touching, and decided could wait. That call felt responsible in the moment. The Verizon report put a number on how often it becomes the opening move in a breach.

For most of this report's run, the answer to how attackers got in was a stolen login. This year it's an unpatched service facing the open internet, with a fix that shipped long ago. Most of the gap isn't yours to close alone. But one slice of it gets wider every time a patch lands and you weigh the rare chance it's poisoned against the daily certainty that the hole you already have is the one getting used.

The attacker isn't losing sleep over whether the next patch is signed. They're reading the same report you are, and they're counting on you to hesitate.