TL;DR: The 2026 Verizon DBIR says exploitation of vulnerabilities rose to 31% of initial access vectors while credential abuse fell to 13%, and only 26% of critical KEV flaws were fully remediated in 2025, according to Veracode’s summary of the report. The signal for practitioners is that remediation speed, not awareness, is now the limiting control.
At a glance
What this is: The 2026 Verizon DBIR shows application-layer vulnerability exploitation has overtaken credential abuse as the leading breach vector, while remediation performance continues to lag.
Why it matters: For application security, IAM, and engineering leaders, the report shifts attention from perimeter and credential controls toward fix velocity, SDLC governance, and exposure window management.
By the numbers:
- Exploitation of vulnerabilities rose to 31% of initial access vectors in the 2026 Verizon DBIR.
- Credential abuse fell to 13% of initial access vectors in the 2026 Verizon DBIR.
- Only 26% of critical vulnerabilities in CISA’s KEV catalog were fully remediated by organizations in 2025.
- The median time to full resolution climbed to 43 days in 2025, up from 32 days the year before.
Context
Application security now sits at the point where detection, remediation, and release velocity determine whether a weakness becomes a breach path. When attackers can pivot from identity abuse to vulnerability exploitation, the control question becomes how fast exposed code can be identified, triaged, and fixed before it is operationally useful.
The 2026 Verizon DBIR frames that shift clearly for security and engineering teams. The article also adds a governance angle: if code flaws remain open for months, the problem is not just application security tooling but the operating model that decides what gets fixed first and who owns that decision.
Key questions
Q: What breaks when application vulnerabilities are not remediated quickly?
A: Attackers gain more time to move from a small code weakness to data theft, privilege abuse or service disruption. In practice, long remediation cycles turn scanning into an inventory exercise while the exposed application remains reachable. The risk is highest when the flaw sits in an internet-facing app, API or third-party service that handles sensitive data or authenticated sessions.
Q: Why do unresolved code flaws increase breach risk even when IAM is strong?
A: Strong IAM limits credential abuse, but it does not remove application defects that create their own footholds. If a reachable service or flaw is exploitable, attackers may never need stolen credentials at all. The risk comes from overlapping control layers that are managed separately even though they determine the same exposure outcome.
Q: What are the signs that vulnerability management is not working well enough in an enterprise?
A: Common warning signs include long remediation cycles, weak visibility into where vulnerabilities exist, and inconsistent prioritisation of high-risk findings. If teams keep repeating the same issues, rely on ad hoc reports, or lack a clear treatment path, the programme is probably underperforming. Another signal is when vulnerabilities are discovered only after attackers or audits surface them.
Q: How should security teams respond when known exploitable flaws keep recurring?
A: Teams should treat recurring exploitable flaws as a governance and prioritisation problem, not just a scanning problem. The right response is to tighten ownership, force faster remediation for KEV-listed issues, and block release paths that repeatedly reintroduce the same weakness. The objective is to shorten the period in which a known flaw can be used operationally.
Technical breakdown
Why vulnerability exploitation now outpaces credential abuse
Initial access is shifting from stolen identity material toward exploitable code paths because attackers go where the exposure window is widest. In practical terms, a vulnerability only needs one unpatched reachable instance, while credential abuse depends on usable secrets, valid sessions, or successful social engineering. Once defenders harden authentication, adversaries often move to application flaws, exposed services, and known weaknesses that remain unresolved long enough to be reliable entry points. The report’s finding reflects a broader reality: application security is now a front-line control, not a downstream engineering concern.
Practical implication: Treat exploitable code paths as primary access risk and feed them into the same prioritisation model you use for identity compromise.
Why remediation backlog becomes the real attack surface
Remediation backlog is the practical measure of exposure, because a vulnerability that stays open keeps offering the same entry path day after day. The article’s figures on low full-remediation rates and longer resolution times show that the issue is not only how many flaws exist, but how long they remain exploitable after discovery. That creates a compounding effect: more findings, slower closure, and a widening gap between detection and actual risk reduction. For AppSec governance, the control failure is not merely missing findings. It is the inability to turn findings into reduced exposure fast enough to matter.
Practical implication: Use fix-age, not discovery volume alone, as the operational metric for whether vulnerability management is reducing risk.
How GenAI changes vulnerability discovery and response
GenAI changes the economics of both offense and defense by increasing the speed and scale at which code issues can be found. That does not automatically make systems less secure or more secure. It does mean remediation pipelines will face more candidate issues, more false urgency, and more pressure to separate exploitable weaknesses from noise. If organizations already struggle to clear known critical flaws, a faster discovery engine will widen the gap unless triage, ownership, and release integration are already mature. The article’s point is not that discovery should slow down, but that response capacity must scale with it.
Practical implication: Build triage rules and ownership paths that can absorb higher vulnerability discovery rates without creating a larger unresolved backlog.
NHI Mgmt Group analysis
Application vulnerability exposure has become a governance problem, not just a code-quality problem. The report shows that exploitation is now displacing credential abuse as the leading access path, which means security teams can no longer treat AppSec as a secondary control layer. If the organisation cannot reduce exposure before release or shortly after discovery, the vulnerability itself becomes the standing access condition. Practitioners should treat fix velocity as a governance outcome, not a developer productivity metric.
Remediation latency is the real control gap the article exposes. Only 26% of critical KEV vulnerabilities were fully remediated in 2025, and the median time to resolution climbed to 43 days. That is long enough for known weaknesses to remain operationally useful, especially when attackers are choosing targets based on persistence of exposure. The named concept here is fix-window drift: the period where known flaws stay open long enough to outlive their intended risk window. Security leaders should measure and manage that drift directly.
The article also shows why identity-first security is necessary but no longer sufficient. Strong authentication reduces one class of attack, but it does not compensate for application defects that create independent entry points. That matters for IAM, PAM, and NHI programmes because service-to-service access, API gateways, and application credentials all depend on code being secure enough to enforce policy consistently. The practitioner conclusion is straightforward: identity controls and application security must be governed as a single exposure model.
GenAI will widen the discovery gap before it narrows it. Faster vulnerability discovery is only useful if remediation capacity and ownership can keep pace. Otherwise, security teams produce more findings without materially reducing exposure. That is especially relevant for organisations trying to scale AppSec across development teams. Practitioners should prepare for higher signal volume, shorter decision cycles, and more pressure on prioritisation.
Application-layer risk is increasingly the place where security investment proves itself. The report’s trajectory suggests that broad credential controls are losing relative value when exploitable code stays open. This does not diminish IAM, but it does force a reset in programme weighting. Teams should expect boards and engineering leadership to ask for evidence that vulnerability management is reducing actual exposure, not just generating tickets.
From our research library:
- Stolen credentials were involved in 22% of breaches overall and in 88% of basic web application attacks, according to Verizon's 2025 Data Breach Investigations Report.
What this signals
Fix-window drift: the gap between finding a vulnerability and removing its exploitability is now a primary security metric. When that gap stretches into weeks or months, application security stops being a preventative function and becomes an exposure-management function.
For identity and application teams, the practical consequence is that control ownership has to be shared. IAM can reduce credential abuse, but application teams own the code paths that attackers increasingly prefer, so governance has to measure both access policy and code exposure in the same operational view.
For practitioners
- Rebalance AppSec and IAM priorities Shift governance focus toward unpatched code paths, reachable services, and fix-age rather than relying on credential controls as the main breach-prevention layer.
- Track remediation by exposure window Measure how long critical flaws remain exploitable after discovery, and use that metric in executive reporting instead of counting findings alone.
- Create a KEV triage path Route Known Exploited Vulnerabilities into an accelerated ownership process so critical issues are assigned, verified, and closed without waiting for normal backlog cycles.
- Align AppSec with release governance Embed vulnerability closure expectations into release decisions so code carrying unresolved high-risk issues cannot move forward by default.
- Prepare for higher discovery volume Set thresholds for triage, deduplication, and business risk scoring before GenAI-driven discovery expands the number of issues arriving into the pipeline.
Key takeaways
- The report shows a structural shift in attack economics, with exploitable application flaws becoming a more attractive route than stolen credentials.
- Remediation lag is the critical weakness because known vulnerabilities remain usable long after discovery and can outlast normal release cycles.
- Security programmes need to measure exposure window, fix velocity, and release governance together if they want vulnerability management to reduce real risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0001 — Initial Access | The article centres on how attackers gain first footholds through exploitable vulnerabilities. |
| Recommendation — Map exposed application flaws to Initial Access and prioritise reachable paths that can be weaponised first. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The report is fundamentally about detection-to-remediation lag and backlog growth. |
| Recommendation — Use Continuous Vulnerability Management to shorten fix windows for KEV-listed and high-risk flaws. | ||
| NIST CSF 2.0 | PR.PS-01 — Configuration Management | Keeping software and services hardened is central to reducing exploitable exposure windows. |
| Recommendation — Apply configuration and patch governance so vulnerable services cannot remain reachable by default. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The article focuses on code-level flaws that persist into production and drive breach exposure. |
| Recommendation — Use secure coding and architecture requirements to prevent recurring flaw classes from shipping. | ||
Key terms
- Fix-window drift: The period between vulnerability discovery and the point at which the weakness is no longer exploitable. In practice, this is the window attackers target, and it becomes a management problem when remediation lags behind discovery.
- Known Exploited Vulnerability: A Known Exploited Vulnerability is a flaw that has confirmed active exploitation in the wild and is tracked for urgent remediation. In governance terms, KEV status turns patching from a general hygiene task into a time-bound operational obligation.
- 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.
- Application-layer risk: Security risk created through code, services, APIs, or runtime application behaviour rather than through identity abuse alone. It matters because application flaws can give attackers a direct foothold even when authentication and access controls are otherwise strong.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org