Reading the 2026 DBIR Beyond the Patching Headline

Verizon published the 2026 Data Breach Investigations Report a few weeks ago, and one finding has dominated the coverage: for the first time in the report's 19-year history, vulnerability exploitation has overtaken stolen credentials as the most common way attackers break in. Cue a wave of posts concluding that we all need to patch faster. Well, no. The report's own data shows that organisations, including the best-performing ones, have hit a hard ceiling on patching capacity. The findings that deserve your attention sit further into the report: when exploitation recurs, and what attackers do once they're through the door. Those chapters are getting far less airtime, and I think they're the ones that should change how you prioritise.

The headline, briefly

The numbers first. Vulnerability exploitation was the initial access vector in 31% of breaches, up from 20% the year before, a 55% jump. Credential abuse dropped to 13%, though Push Security's review points out it would be 16% on a like-for-like basis, as Verizon reshuffled some of those incidents into a new "pretexting" category this year. Their read, which I share, is that the identity picture barely moved. Vulnerability exploitation surged past it.

What's driving the surge? Volume, mostly. The vulnerability records flowing through Verizon's remediation dataset have grown almost eightfold since 2022; in the report's own words, there are often too many vulnerabilities and not enough time for patching all of them. The entry points are familiar. Attackers are increasingly using the same access paths as legitimate users, VPNs and desktop-sharing tools among them, and the report describes exposed systems as "rolling out the red carpet to cybercriminals rather than being the hardened entry points they were thought to be". The irony of the security stack being the way in does not improve with repetition.

Attackers are winning this race partly because the defending side has stalled. Organisations fully remediated just 26% of the vulnerabilities on CISA's Known Exploited Vulnerabilities (KEV) catalog, down from 38% the year before, and the median time to patch stretched from 32 to 43 days (Help Net Security has a good summary). Those numbers are the backdrop to CISA's new patching directive, which moves US federal agencies from blanket deadlines to risk-based patching.

The ceiling

Here's the first underreported finding. Verizon ran a survival analysis over more than a billion anonymised vulnerability detection records and found that by day 7, 60% to 70% of KEV vulnerabilities remained open, regardless of year, vulnerability volume, or organisational maturity. Even the best performers only closed 30% to 40% of known-exploited vulnerability instances in their first week. By day 28, 35% were still open, which translated to 184 million open vulnerability instances in the dataset (Nucleus Security's write-up collects the page references if you want to check them).

Maturity barely moves the result. Well-resourced teams with serious tooling still leave two thirds of the worst vulnerabilities open after a week. The ceiling is structural, and it's getting worse: the median organisation faced 50% more critical vulnerabilities than the previous year.

So "patch faster" is advice with nowhere left to go. If speed has a ceiling, choice is what you have left. Which bugs you fix first now matters more than how quickly you clear the queue in aggregate.

Exploitation has a half-life

This is the finding I haven't seen anyone else write about, and I think it's the most practical thing in the report. Verizon analysed re-exploitation patterns and found that the probability of a vulnerability seeing resurgent exploitation drops by roughly half at 30 days, halves again around 90 days, and again at about nine months. After roughly a year, Verizon says, the probability of resurgent exploitation is about the same as if the vulnerability had never been exploited at all.

That's a decay curve. Exploitation activity has a half-life.

Why does that matter? Because most prioritisation treats the KEV catalog as binary. A CVE that was exploited once in 2023 and a CVE being hit this week carry the same flag, and most patching SLAs treat them identically. The decay data says they're very different risks. Verizon's own advice is that when choosing between a recent KEV entry that hasn't been exploited lately and a vulnerability not yet on the KEV that your threat intelligence shows under active attack, the one with recent activity could be "a smarter bet". Recency of exploitation is a prioritisation signal in its own right, and very few programmes use it.

There's a counterweight, though, and it's important. Of the KEV vulnerabilities with detectable exploitation over the past year, nearly half were classed as having "persistent" exploitation, and 80% of those had been published for around two years before. Old bugs still earn a living: vulnerabilities in that persistent category were detectable in exploitation traffic on an average of 96% of days. The signal is recency of exploitation activity, which has little to do with how recently the CVE was published. A two-year-old CVE under active attack this month outranks last week's critical that nobody has weaponised.

What happens after the door

The second underreported finding sits in the privilege escalation analysis. Verizon grouped the techniques attackers use to escalate privileges and access credentials by the mitigation that would address them: roughly 65% could be addressed by privilege management, 33% by configuration, 30% by password policy, and about 10% by patches.

Ten percent. And in 83% of the incidents Verizon analysed, the attacker escalated privileges without exploiting a vulnerability at all.

This makes sense once you describe a breach the way an attacker experiences it: as a chain of state changes. Land a foothold, escalate privileges, move laterally, reach the data or systems you came for. Each link in that chain can be made from different material, and the DBIR shows the mix clearly. The foothold is now most often a vulnerability in something exposed to the internet. Almost everything after it is built from credentials, permissions, and misconfigurations. Credential abuse still appears somewhere in 39% of all breaches, and among ransomware victims who had a prior credential or infostealer leak, half saw it within the 95 days before the attack.

Thinking in chains also changes what any individual vulnerability is worth. Its value to an attacker depends on which state change it enables and where it sits, and a severity score can see neither. A middling CVE on a well-connected internal server might be the link that joins a foothold to your domain controllers; a critical on an isolated box might lead nowhere. Same score, different position, completely different contribution to the chain.

The attack graph data shows what happens when nobody measures those chains. In 16% of the organisations Verizon collected attack graphs from, an attacker starting with low-level access had an 80% or better chance of reaching a key administrative account or piece of infrastructure. Better than four chances in five of full compromise from any foothold, in one organisation in six. Patching defends the first link. Everything after it lives in a different queue, usually owned by a different team, often by no team at all.

Where I'd point the effort

Keep patching, obviously, and use the edge-device numbers to argue for shorter SLAs on anything that terminates a connection from the internet. But use the decay curve too: exploitation recency belongs next to KEV status as a first-class input to your prioritisation, and your threat intelligence feed almost certainly already carries it.

Then look past the patch queue. When a tenth of post-entry technique is patchable, the queue cannot carry the whole programme, however healthy it looks. Map the chains an attacker could assemble through your environment, the way Verizon's attack graph contributors do, find the ones that end somewhere expensive, and break each one at its cheapest link. Sometimes that's a patch. More often it's a permission nobody remembers granting.