Verizon DBIR 2026 shows vulnerability exploitation is overtaking credential abuse

At a glance

What this is: The 2026 Verizon DBIR finds that vulnerability exploitation has overtaken credential abuse as the leading breach vector, while remediation performance continues to deteriorate.

Why it matters: This matters because IAM, AppSec, and security engineering teams have to rebalance control priorities when attack paths increasingly begin in unpatched code rather than stolen identities.

By the numbers:

• exploitation of vulnerabilities has risen to 31% of initial access vectors
• 13%
• only 26% of critical vulnerabilities were fully remediated by organizations in 2025
• 43 days

👉 Read Veracode's analysis of the 2026 Verizon DBIR and application security trends

Context

Application security is increasingly a governance problem as much as a tooling problem. When vulnerabilities become the most common foothold, existing models that over-index on identity controls leave a gap in the part of the stack attackers are exploiting first. This article uses the 2026 Verizon DBIR to argue that the organisation’s security posture is not keeping pace with exploitability, patch debt, and the speed of modern attack chains.

For IAM and NHI programmes, the intersection is indirect but real. Identity controls remain essential, yet they do not compensate for exposed application flaws, especially where service accounts, API tokens, or cloud workloads can be reached once an exploit succeeds. The practical question is no longer whether identity or application security matters more, but whether the enterprise can reduce exposure across both layers quickly enough.

Key questions

Q: What fails when vulnerability remediation is slower than AI-assisted exploitation?

A: Patch-first security fails when exploit generation outpaces validation, change control, and deployment. The practical failure is not that teams cannot detect issues, but that they cannot close exposure before an attacker can operationalise it. In that environment, containment and blast-radius reduction become the only controls that still work reliably.

Q: Why do vulnerabilities now matter as much as identity controls in breach prevention?

A: Because attackers increasingly start with application weaknesses, then move into identity, privilege, and data access once they are inside. Identity controls still matter, but they no longer represent the only or even primary first line of defence. A mature programme has to reduce both exploitability in code and abuse potential in identities.

Q: How do security teams know whether Teams remediation is working?

A: They should measure dwell time, removal latency, and the percentage of malicious messages removed before any user interaction. If detection is happening but content stays visible long enough to be clicked, the control is not effective enough. Audit trails should show fast, consistent containment.

Q: Should organisations rebalance investment from identity controls to application security?

A: They should rebalance, not replace. Identity controls are still necessary, especially where attackers pivot from application flaws into tokens, sessions, and privileged accounts. But if vulnerabilities are the main entry point, the programme needs more investment in detection, prioritisation, and rapid remediation across the application layer.

Technical breakdown

Why exploitation of vulnerabilities now drives initial access

Initial access is the first successful foothold an attacker gains, and the DBIR’s shift toward vulnerability exploitation shows that exposed code paths are now delivering more entry opportunities than credential theft. In practice, this happens when internet-facing systems, application components, or libraries remain unpatched long enough to be found and weaponised. The control failure is usually not one flaw but a chain of late detection, slow prioritisation, and incomplete remediation.

Practical implication: security teams need exposure-aware patch prioritisation, not just broad vulnerability counts.

Why remediation time is the real control variable

Remediation time measures how long a known flaw remains available to an attacker after discovery. The DBIR’s longer resolution windows show that finding vulnerabilities is not enough if the organisation cannot clear them quickly. As patch queues grow, the operational problem becomes triage, ownership, and change capacity. In governance terms, the security team is being asked to prove that a defect can be removed before it becomes a viable exploit path.

Practical implication: measure mean time to remediate by severity and exploitability, not by ticket volume alone.

Why application risk still intersects with identity governance

Application vulnerabilities often become identity problems once they expose sessions, tokens, service accounts, or privileged workflows. An exploit may begin in code, but the blast radius expands through credential reuse, over-privileged access, and weak workload boundaries. That means AppSec and IAM cannot operate as separate programmes when compromise can move from an application defect into NHI abuse, cloud privilege escalation, or API misuse.

Practical implication: map high-risk application paths to the identities and secrets they can reach.

Threat narrative

Attacker objective: The attacker aims to turn a software flaw into durable access that can be leveraged for broader compromise, data theft, or operational disruption.

1. Entry occurs when an attacker exploits an unpatched application vulnerability to gain an initial foothold.
2. Escalation follows if the compromised application can reach privileged tokens, service accounts, or cloud-bound secrets.
3. Impact occurs when the attacker uses that access to expand control, move laterally, or exfiltrate data before the flaw is fully remediated.

NHI Mgmt Group analysis

Application exploitation has become a governance problem, not just a coding problem. When the leading breach vector shifts to vulnerabilities, the organisation’s weakness is no longer limited to a specific line of code. It includes prioritisation, ownership, change capacity, and cross-functional accountability. AppSec teams should treat exploitability as an enterprise risk metric, not a developer-only issue.

Remediation latency is the more important metric than vulnerability volume. A large backlog is only part of the story. The real question is how long a critical flaw remains exploitable after discovery, because that window defines attacker opportunity. Security leaders should focus on reducing exposure time across the most reachable systems first.

Exploit-to-identity spillover is the control gap this report highlights. Application flaws increasingly become identity incidents when attackers reach tokens, sessions, service accounts, or cloud permissions through compromised code paths. That means IAM and AppSec programmes need shared visibility into which apps can touch high-value identities and secrets. The practitioner conclusion is simple: identity governance must extend into application risk paths.

GenAI will increase both discovery pressure and remediation stress. Faster vulnerability discovery is useful only if the organisation can absorb findings without widening the backlog. The market signal is that security teams need operational models that can scale with more findings, not just better scanners. Practitioners should prepare for higher volume, shorter decision cycles, and tighter prioritisation discipline.

What this signals

Application security teams should expect board-level pressure to move from awareness to measurable exposure reduction, especially where critical flaws sit in public-facing systems. The practical shift is toward faster triage, tighter ownership, and clearer linkage between exploitability and business criticality, reinforced by guidance such as the NIST SP 800-53 Rev 5 Security and Privacy Controls.

Exploitability backlog: the organisation’s real risk is not how many vulnerabilities are known, but how long the most reachable ones remain exploitable. That framing should change reporting, funding, and remediation decisions across security and engineering.

For identity and NHI programmes, the next step is to track where application risk can spill into privileged access. Once a flaw exposes tokens, service accounts, or cloud roles, the issue becomes a combined application and identity governance problem, not a single-domain fix.

For practitioners

• Prioritise exploitable vulnerabilities over raw backlog size Build a remediation queue that weights internet exposure, exploit evidence, and business criticality so teams close the defects most likely to become active attack paths first. Use this to replace ticket-count reporting with exposure-based governance.
• Shorten the time a critical flaw remains reachable Set service-level objectives for critical flaws that are measured in days, not weeks, and assign clear ownership for approvals, testing, and deployment so remediation does not stall in handoffs.
• Map application paths to reachable identities and secrets Identify which applications can access service accounts, API keys, tokens, or elevated cloud roles, then treat those paths as combined AppSec and IAM risk surfaces rather than separate control domains.

Key takeaways

• The DBIR shows a clear shift from credential-led breaches to vulnerability-led breaches, which changes how security teams should prioritise control investment.
• Long remediation windows are now a material exposure problem, because a known flaw remains an attacker opportunity until it is fully closed.
• Identity security still matters, but AppSec and IAM now need shared visibility wherever exploits can reach secrets, sessions, or privileged workloads.

Key terms

• Initial Access: Initial access is the first successful entry point an attacker gains into a target environment. In application security, that foothold often comes from an unpatched flaw rather than a stolen password, which is why exploitability and exposure time matter as much as control coverage.
• Mean Time to Remediation: Mean time to remediation is the average time it takes to fix systems that are out of compliance. It measures how fast a team can move from detection to closure. Lower values usually indicate better process discipline, clearer ownership, and fewer hidden exceptions.
• Exposure Window: The period in which a credential, session, or privilege grant can be exploited before it is revoked or expires. Shorter windows help, but they do not solve the deeper question of whether the access remains justified for the full time it is active.

What's in the full report

Veracode's full article covers the operational detail this post intentionally leaves for the source:

• A deeper walkthrough of the 2026 Verizon DBIR findings on application-layer risk and breach vector shifts
• The full remediation analysis behind the 26% critical vulnerability fix rate and 43-day median resolution time
• Context on code flaw survival analysis and how GenAI may change vulnerability discovery volume
• Veracode's commentary on what security and development teams should do next with the report's findings

👉 Veracode's full article expands on remediation trends, code flaw survival, and GenAI's impact on vulnerability discovery.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect identity controls to the broader risk decisions their programmes need to make.