85% of Security Leaders Report Patching-Delay Incidents, Azul Survey Finds

Eighty-five percent of surveyed U.S. security leaders reported an incident, suspected incident, or near miss attributable to slow patching, according to Azul's 2026 AI Vulnerability Gap Report. The survey of 300 security leaders, commissioned by Azul and conducted by Censuswide, also found that 69% believe AI-equipped attackers can build a working exploit within three days, while 44% said their own organizations need four days or longer to patch a critical vulnerability across production.

The report documents a structural mismatch in enterprise security: defenders recognize how fast attackers might move, but their deployment pipelines cannot match that speed. The fieldwork ran August 3–7, 2026, among security leaders at organizations with at least 1,000 employees and significant Java/JVM (Java Virtual Machine, the runtime engine that executes Java applications) production use. The stakes are operational rather than theoretical — patch velocity and runtime visibility now determine how long a known vulnerability stays exploitable.

What do the numbers actually show?

The survey separates leaders' expectations about attackers from their own patching capabilities:

• 69% believe AI-equipped attackers can build an exploit in three days or less, including 22% who put that window below 24 hours.
• 56% say their organization can deploy a critical patch across production within three days: 13% in under 24 hours and 43% in one to three days.
• 44% need longer: 32% require four to six days and 12% need more time.

These figures are distributions of survey responses, not measurements of attackers racing specific organizations on the same vulnerabilities. They support concern about readiness, but they do not establish a precise three-day exposure window for every enterprise. The imbalance persists at the one-day threshold: 22% of respondents expect attackers to move that quickly, while only 13% say their organization can deploy a fix within that window.

A further 59% of respondents acknowledge greater exposure from AI-powered attack tools without having changed their security posture.

How much of the delay is testing?

A substantial share of the patch cycle sits in validation. Testing Java runtime updates adds four or more days at 58% of surveyed organizations — 36% report four to six days and 22% report a week or longer. Another 33% report one to three days, and 9% report less than 24 hours. No respondent said testing was skipped.

Testing serves a practical purpose. Runtime changes can affect many applications at once, and a security update that disrupts a critical service creates a second operational problem on top of the original vulnerability. The report argues that update scope contributes to the burden because full OpenJDK (the open-source reference implementation of the Java platform) quarterly releases can include non-security changes alongside vulnerability fixes.

Azul separately assessed 26 quarterly OpenJDK updates spanning more than six years and classified six — 23% — as causing a serious regression (a change that breaks existing application behavior). That figure is the vendor's release assessment, not a survey estimate of how often an individual customer's application will break.

Among the biggest reported barriers to faster patching, 44% of respondents cite extensive testing, 40% cite the complexity or age of affected systems, and 36% cite limited visibility into known vulnerabilities. Vendor patch delays were cited by 25%. The pattern places most of the remediation challenge inside the enterprise's own deployment process.

How should the incident figures be read?

The incident data requires careful interpretation. Fifty-five percent of respondents report a confirmed incident attributable to slow patching, and 53% report a near miss. Respondents could select multiple answers, so these overlapping figures should not be added together. The broader 85% headline also includes suspected incidents.

The survey does not establish that all those events involved Java vulnerabilities. Participants work in Java-heavy organizations, but the research asked about software patching broadly as well as Java runtimes specifically. The 85% figure describes reported experience, not an independently verified breach rate, and it does not establish that AI caused those events.

Inventory presents a second, quieter problem. Only 19% of respondents say at least 90% of their production Java runtime estate runs the latest security patch level. That means 81% fall below that threshold — but it does not mean 81% have no current runtimes. About one in five respondents say half or less of their estate is current.

Separately, 51% acknowledge partial or limited visibility into critical Java runtimes, including embedded, legacy, and unmanaged instances. Finding a vulnerable runtime inside a packaged application or container can be harder than identifying a centrally managed installation. A patch cannot close exposure on a system the deployment process never reaches.

What does Azul's technology contribute?

Azul, the report's sponsor, sells products that address the problems the report measures. Its security-update offering limits selected releases to security fixes on a previously stabilized OpenJDK baseline. The company provides quarterly, targeted monthly, and out-of-cycle updates, aiming to reduce the amount of unrelated change enterprises must evaluate when deploying an urgent fix.

That is a narrower intervention than eliminating the need for change control (the formal review process for modifying production systems). Limiting code changes can reduce the scope of validation, while application-specific checks, deployment ownership, and rollback preparation still matter.

Azul's Java inventory and vulnerability tooling addresses the other side of the workflow: identifying runtimes, versions, and exposure so a new disclosure can be mapped to affected systems. The report does not provide a controlled comparison demonstrating how much the surveyed organizations would improve by adopting those products.

"Our research shows security leaders understand the threat: awareness is no longer the gap; execution is," said Scott Sellers, Azul's co-founder and CEO.

What are security leaders prioritizing next?

For the coming year, 32% of respondents identify faster and more frequent patching as their primary strategy for reducing exposure, while 26% favor better software and runtime inventory. Another 17% prioritize detection and response over faster patching.

The research suggests tracking the whole path from disclosure to remediation: which systems are affected, who owns them, what testing is required, and whether the fix actually reached production. A deadline is useful only when teams can verify completion across the relevant estate.

The findings are self-reported responses from a defined population, rather than a census of enterprises or direct measurement of exploit development. The full 2026 AI Vulnerability Gap Report details the findings and methodology. Its clearest implication is that patch speed and runtime visibility need to improve together — a rapid fix has limited value if the organization cannot identify every affected deployment or confirm that the update reached it.