Vulnerability Exploitation Just Overtook Credential Theft as the #1 Breach Vector. But Is It Really This Bad?

The 2026 Verizon DBIR landed last week and the headline is stark: vulnerability exploitation is now the number one initial access vector, accounting for 31% of confirmed breaches. This is the first time in the report's 19-year history that credential theft has been displaced from the top spot. Credentials dropped to 13%. Phishing sits between them at 16%.

The reason isn't that exploitation got harder to defend against. The reason is that organizations got slower at patching. Median time to patch a critical vulnerability increased from 32 days to 43 days. Only 26% of vulnerabilities in CISA's Known Exploited Vulnerabilities catalog were fully remediated, down from 38% the year before. The volume of vulnerability instances Verizon recorded jumped from 69 million in 2022 to 527 million in 2025.

Every publication this week is writing about what the numbers mean. This post is about what you do with them. Specifically: five queries you can run today in your M365 tenant to find out whether the DBIR's problem is your problem, and what to fix first.

1. Find out how many CISA KEV vulnerabilities are live in your environment right now

The CISA Known Exploited Vulnerabilities catalog is the closest thing the industry has to a prioritized patch list. Every entry represents a vulnerability that has been exploited in confirmed attacks. CISA publishes the full catalog as a CSV. Defender for Endpoint's DeviceTvmSoftwareVulnerabilities table tracks every unpatched CVE on every onboarded device. The query joins the two.

// CISA KEV exposure — devices with known-exploited vulnerabilities
let KEV = externaldata(
    cveID: string, vendorProject: string,
    product: string, vulnerabilityName: string,
    dateAdded: datetime, shortDescription: string,
    requiredAction: string, dueDate: datetime,
    knownRansomwareCampaignUse: string
)
[h@'https://www.cisa.gov/sites/default/files/csv/known_exploited_vulnerabilities.csv']
with(format='csv', ignoreFirstRecord=true);
DeviceTvmSoftwareVulnerabilities
| project DeviceName, OSPlatform, CveId,
    SoftwareName, SoftwareVersion,
    VulnerabilitySeverityLevel
| join kind=inner KEV on $left.CveId == $right.cveID
| summarize
    KEV_Count = dcount(CveId),
    Vulnerabilities = make_set(CveId),
    RansomwareLinked = countif(
        knownRansomwareCampaignUse == "Known")
    by DeviceName, OSPlatform
| sort by KEV_Count desc

The output tells you which devices have unpatched vulnerabilities that attackers are actively exploiting in the wild. Pay attention to the RansomwareLinked column. It counts how many of those KEV entries have confirmed use in ransomware campaigns. If that number is anything other than zero, you have a device running software that ransomware operators are targeting with known, proven exploits.

Run this query. If the result set is empty, your patch posture on CISA KEV is clean. If it isn't, sort by KEV_Count descending and start with the device at the top.

2. Measure how long your critical vulnerabilities have been public and unpatched

The DBIR says the median organization takes 43 days to patch. The DeviceTvmSoftwareVulnerabilities table shows every unpatched CVE on every device. The companion DeviceTvmSoftwareVulnerabilitiesKB table has the CVE publish date. Joining the two tells you how long each critical vulnerability has been publicly known while your devices remain unpatched.

// Unpatched critical/high CVEs by age since disclosure
DeviceTvmSoftwareVulnerabilities
| where VulnerabilitySeverityLevel in
    ("Critical", "High")
| summarize
    DeviceCount = dcount(DeviceName),
    Software = make_set(SoftwareName, 3)
    by CveId, VulnerabilitySeverityLevel
| join kind=inner (
    DeviceTvmSoftwareVulnerabilitiesKB
    | project CveId, PublishedDate, CvssScore,
        IsExploitAvailable
) on CveId
| extend DaysSincePublished =
    datetime_diff('day', now(), PublishedDate)
| where DaysSincePublished > 14
| sort by DaysSincePublished desc
| project CveId, VulnerabilitySeverityLevel,
    CvssScore, DaysSincePublished,
    DeviceCount, IsExploitAvailable,
    Software = tostring(Software)

The DaysSincePublished column is what you compare against the DBIR's 43-day median. It measures how long the CVE has been publicly known while remaining unpatched in your environment. The IsExploitAvailable column flags CVEs where public exploit code exists. A critical vulnerability that's been public for 60 days with a known exploit and 15 affected devices is the exact profile the DBIR describes.

The query filters to vulnerabilities published more than 14 days ago. Everything under that threshold is within a reasonable patch cycle. What you're looking for are the CVEs that have been sitting in your environment for weeks or months because they fell off someone's list.

3. Find internet-facing devices with critical unpatched vulnerabilities

The DBIR data shows that edge devices are the primary exploitation targets: VPNs, firewalls, web servers, remote access gateways. An unpatched vulnerability on an internal workstation is a risk. An unpatched vulnerability on an internet-facing device is an invitation.

Defender for Endpoint's DeviceInfo table includes IsInternetFacing when the device has been assessed by Defender Vulnerability Management. Joining this with the vulnerability table surfaces the worst combination: internet-exposed and critically vulnerable.

// Internet-facing devices with critical vulnerabilities
DeviceTvmSoftwareVulnerabilities
| where VulnerabilitySeverityLevel == "Critical"
| join kind=inner (
    DeviceInfo
    | where isnotempty(DeviceName)
    | summarize arg_max(Timestamp, *) by DeviceId
    | where IsInternetFacing == true
) on DeviceId
| summarize
    CriticalVulns = dcount(CveId),
    CVEs = make_set(CveId, 10),
    Software = make_set(SoftwareName, 5)
    by DeviceName, OSPlatform
| sort by CriticalVulns desc

If this returns results, those devices are your top priority this week. An internet-facing device with a critical unpatched vulnerability is the exact profile the DBIR's 31% exploitation vector targets. These don't go into a sprint backlog. They go into today's change window.

4. Check whether exploitation attempts are already hitting your tenant

Knowing you're vulnerable is one thing. Knowing attackers are already trying is another. Defender for Endpoint logs exploitation attempts as alerts. The AlertInfo and AlertEvidence tables in Advanced Hunting capture these. This query filters for exploitation-category alerts in the last 30 days and correlates them with the device and CVE.

// Exploitation alerts — are attackers already trying?
AlertInfo
| where Timestamp > ago(30d)
| where Category == "Exploit"
    or AttackTechniques has "Exploitation"
    or Title has_any ("exploit", "vulnerability",
        "CVE-", "remote code execution")
| join kind=inner (
    AlertEvidence
    | where EntityType == "Machine"
) on AlertId
| summarize
    AlertCount = count(),
    Titles = make_set(Title, 5),
    Severities = make_set(Severity),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by DeviceName
| sort by AlertCount desc

An empty result set means Defender hasn't observed exploitation attempts against your devices in the last 30 days. A populated result set tells you which devices are actively being probed or attacked, which CVEs are being targeted, and how frequently. Cross-reference any hits against Query 1. If the same device appears in both your KEV exposure list and your exploitation alert list, the attacker has already found what the DBIR predicted they would find.

5. Build the exposure summary your leadership needs to see

The DBIR is a report that CISOs and security leaders read. When yours asks "are we affected by what the DBIR describes?" you need to answer with your numbers, not Verizon's. This query builds the summary: total critical and high vulnerabilities, CISA KEV exposure, internet-facing risk, and patch velocity.

// Executive exposure summary — your DBIR response
let KEV = externaldata(cveID: string)
    [h@'https://www.cisa.gov/sites/default/files/csv/known_exploited_vulnerabilities.csv']
    with(format='csv', ignoreFirstRecord=true);
let kev_count = toscalar(
    DeviceTvmSoftwareVulnerabilities
    | join kind=inner KEV on $left.CveId == $right.cveID
    | summarize dcount(CveId)
);
let kev_devices = toscalar(
    DeviceTvmSoftwareVulnerabilities
    | join kind=inner KEV on $left.CveId == $right.cveID
    | summarize dcount(DeviceName)
);
let avg_age = toscalar(
    DeviceTvmSoftwareVulnerabilities
    | where VulnerabilitySeverityLevel == "Critical"
    | join kind=inner (
        DeviceTvmSoftwareVulnerabilitiesKB
        | project CveId, PublishedDate
    ) on CveId
    | summarize round(avg(
        datetime_diff('day', now(), PublishedDate)), 0)
);
DeviceTvmSoftwareVulnerabilities
| summarize
    TotalCritical = dcountif(CveId,
        VulnerabilitySeverityLevel == "Critical"),
    TotalHigh = dcountif(CveId,
        VulnerabilitySeverityLevel == "High"),
    DevicesWithCritical = dcountif(DeviceName,
        VulnerabilitySeverityLevel == "Critical")
| extend
    AvgDaysUnpatched_Critical = avg_age,
    CISA_KEV_Unique_CVEs = kev_count,
    CISA_KEV_Affected_Devices = kev_devices

The output is a single row with six numbers: total critical CVEs, total high CVEs, devices carrying critical vulnerabilities, your average patch window for critical vulnerabilities, CISA KEV CVEs present in your environment, and devices affected by KEV vulnerabilities. Those six numbers tell your leadership whether the DBIR's 31% exploitation vector is a headline you're reading or a risk you're carrying.

What the DBIR actually changed

Nothing. The DBIR didn't change the threat landscape. It measured what was already happening. Exploitation has been rising for years. Patching has been slowing for years. The 2026 report is the year the lines crossed.

What the report does change is the conversation. When your CISO reads that 31% of breaches start with vulnerability exploitation and that the median organization takes 43 days to patch, the next question is whether your organization is above or below that line. The five queries above give you the answer before anyone asks.

The priority order for this week

Run Query 1 first. If you have CISA KEV vulnerabilities on production devices, that's your starting point. Those are vulnerabilities with confirmed exploitation in the wild. Run Query 3 next and cross-reference. Any device that's both internet-facing and carrying a KEV vulnerability is the highest-priority remediation target in your environment.

Run Query 4 to check whether exploitation attempts are already hitting your tenant. If Defender has logged exploitation-category alerts in the last 30 days, compare the targeted devices against Queries 1 and 3. An exploitation alert against a device that's internet-facing and carrying KEV vulnerabilities is not a hypothetical risk. It's an active attack path.

Query 2 gives you your own patch velocity number. Compare it against the DBIR's 43-day median. If your critical vulnerabilities are sitting open for 60 or 90 days, the conversation shifts from "should we patch faster" to "here is what we're exposed to while we wait."

Query 5 packages all of it into a single row your security leader can present to the board. The DBIR provides the industry context. Your numbers provide the organizational reality. The gap between the two is the risk conversation.

The five queries don't require new tools, new licenses, or new budget. They use telemetry your M365 tenant is already collecting. The DBIR says vulnerability exploitation is winning. Your Advanced Hunting console tells you whether it's winning against you.