Verizon’s 2026 Data Breach Investigations Report (the 19th edition, built on more than 22,000 confirmed breaches) flipped the order on how attackers actually get in. Vulnerability exploitation is now the number one initial access vector at 31% of breaches, overtaking credential abuse, which fell to 13%. The report’s own theme says it plainly: “keeping a strong foundation in the face of change.”
The same report shows the foundation slipping. Only 26% of the critical, actively exploited vulnerabilities in CISA’s Known Exploited Vulnerabilities catalog were fully remediated in 2025, down from 38% the year before. The median time to fully resolve one stretched to 43 days. And the median organization had 50% more critical vulnerabilities to patch than the year before.
When companies have been told the last few years that the whole game is phishing and passwords, this is a real change. Identity is still important. But the data says the unpatched, internet-facing system is back to being the thing most likely to get you breached.
What this actually means for your security program #
Here is the part I want to be blunt about: this almost always comes down to fundamentals. If you are doing the basic controls well, a report like this is not scary. New attacks show up, your existing discipline absorbs most of them, and you move on. The companies that panic at every new headline are usually the ones that skipped the boring work.
Patch management is a solved problem. We have known how to do it for twenty years. There is exactly one real objection, and it is legitimate: a patch might break something. That is a genuine risk. But you have to weigh it against the other side of the ledger. Attackers now turn a fresh CVE into a working exploit in days, sometimes hours. So the honest question is whether you would rather take some downtime from a bad patch or get breached because you waited. I know which one I would choose, and it is not close.
My advice: autopatch, autopatch, autopatch. Patch automatically, everywhere you can, as often as you can. Endpoints, browsers, operating systems, dependencies. Be careful in production, obviously. But “careful” does not mean “manual.” You can still patch production automatically if you do it selectively: stage your rollouts, patch the low-risk systems on their own, and gate the riskier ones behind a little more validation.
The thing that makes aggressive patching safe is automated testing, and it is the part most teams skip. It is also why they stay afraid of patching. If a patch lands in staging and your test suite tells you within minutes whether anything broke, the “it might break something” objection mostly disappears. Automated testing is not a nice-to-have bolted onto your patch process. It is the safety net that lets you move fast without flying blind. Spend there and everything else gets easier.
What to do now #
You do not need a tool purchase or a new hire to start. You need to decide that patching is a default-on automated process, not a manual chore someone gets to when there is time.
- Turn on automatic updates everywhere it is already free: operating systems, browsers, endpoint agents. Most teams have this available and simply have not flipped it on.
- Put dependency updates on an automated pipeline (Dependabot, Renovate, or your platform’s equivalent) so they flow in continuously instead of piling up.
- For production, define rings: patch the low-risk systems automatically, stage the critical ones, and let automated tests be the gate instead of someone’s calendar.
- Have an emergency patch path. Routine autopatching handles the steady stream, but you also need a defined out-of-band process for the actively-exploited critical bug that cannot wait for the next ring: who decides, who tests, who approves the off-cycle deploy, and how fast it has to ship. When CISA adds something to the Known Exploited Vulnerabilities catalog, that is the trigger to invoke it, not the start of a debate.
- If you are choosing where to spend, make automated testing the priority. It is what converts “we are afraid to patch” into “we patch constantly and barely think about it.”
- Track one number: how long it takes you to fully fix a known-exploited vulnerability. If it is anywhere near the DBIR’s 43-day median, automation can cut that dramatically.
The 2026 DBIR is not telling us something new. It is reminding us that the fundamentals still decide who gets breached. Patch management is solved. The only thing left is to actually do it, automatically, and to build the testing that lets you do it without fear.
Not sure where your patch SLAs actually stand? A security assessment will tell you →