Nine in 10 Australian firms hit by slow patching risks

Nine in 10 Australian organisations have faced a security incident, suspected incident or near miss linked to slow patching, according to research from Azul based on a survey of 200 Australian cybersecurity leaders. The study, published 12 November 2026, measures a widening gap between how fast AI-equipped attackers can weaponise a vulnerability and how long enterprises need to push a fix through production.

The numbers behind that headline figure are blunt. 57% of respondents said their organisation had suffered a confirmed incident attributable to slow patching. The broader 90% figure includes suspected incidents and near misses, which suggests patching delays have become a routine security problem rather than a marginal risk.

The stakes are straightforward: patching speed now determines how long a company stays exposed after a flaw goes public.

How fast can attackers move?

Security leaders in Australia believe AI has compressed the exploitation timeline dramatically. 51% of those surveyed said AI-equipped attackers can develop a working exploit within one to three days of a critical vulnerability becoming public. Another 7% said this could happen in less than 24 hours.

Put simply, most respondents expect a weaponised exploit within days — sometimes hours — of disclosure.

How long do defences actually take?

Deployment timelines tell the other half of the story. 45% of Australian security leaders said their organisation usually needs four to six days to deploy a critical security patch across production. Another 15% said the process can take up to a week.

So even in the best common case, attackers enjoy a multi-day head start before a fix lands.

Testing is the biggest bottleneck. Among those surveyed, 42% said pre-deployment testing adds four to six days to the Java patching cycle. 30% said it adds one to three weeks.

The takeaway: many organisations remain exposed long after vulnerabilities are disclosed, before patch deployment even begins in earnest.

Why Java makes it worse

The research centres on organisations with significant Java estates, and that focus is deliberate. Java environments are difficult for security teams to fully track across large, complex estates. Java often sits behind core business applications, and patching can involve both security fixes and broader code changes. That combination makes testing more burdensome than it is for simpler software stacks.

The timing sharpens the point. The findings arrive soon after an OpenJDK quarterly update disclosed 53 vulnerabilities — which Azul described as the highest number in a single update in more than a decade. That record has raised the question of whether existing patching processes are still suited to a faster attack cycle.

When one quarterly update carries 53 flaws, a testing pipeline that adds weeks per cycle stops being a process detail and becomes a liability.

What about lower-priority flaws?

The survey also found inconsistency in how organisations handle vulnerabilities that fall outside the critical category:

• Only 33% of Australian respondents said their organisation requires non-critical vulnerabilities to be patched within a defined timeframe.
• 32% said such vulnerabilities are patched on a best-effort basis.
• 14% said their organisation has no formal patching policy at all.

That suggests many businesses still lack structured deadlines once an issue drops out of the most severe category — even though attackers don't necessarily respect priority labels.

The gap is governance, not awareness: once a flaw isn't labelled critical, most organisations have no clock running on it.

Why patch cycles stay slow

Patch management remains constrained as much by internal processes as by outside threats. In large organisations, production updates often require multiple rounds of testing, operational sign-off and coordination across application teams. That stretches response times even for urgent fixes.

The result, according to the survey, is a problem of execution rather than awareness. Many security leaders already accept that AI has compressed the time available to respond. But internal patch cycles have not kept pace with that reality.

Security teams are, in effect, balancing speed against the risk that a hasty update disrupts production systems.

Does the US show the same pattern?

Azul also released global findings from a separate survey of 300 US security leaders, and the direction is the same:

• 85% of US organisations reported an incident, suspected incident or near miss due to slow patching.
• 69% said attackers using AI could build an exploit in three days or less.
• Only 13% could deploy a critical patch across production in under 24 hours.
• 32% needed four to six days.
• 12% took longer.

The US data also found that testing alone added four or more days for most respondents.

The Australian and US samples are separate, but both point to the same structural issue: attack timelines are shortening while patch deployment remains tied to slower operational processes.

What does Azul's CEO say?

Scott Sellers, co-founder and chief executive officer of Azul, framed the issue as one of execution. "Agentic AI has collapsed the margin defenders depend on, and most enterprises are still running patch processes built for a much slower adversary," Sellers said.

"Our research shows security leaders understand the threat: awareness is no longer the gap; execution is. No one can eliminate zero-day risk, but every organisation decides how long it stays exposed by how much of its Java estate it can see and how fast a fix can move through it. Azul's Security-only, Stability-first updates include only security patches, with nothing else bundled in that could risk breaking things, so enterprises can move fast and close that exploitation window before an attacker finds it first," he said.

The comment doubles as Azul's pitch — the company sells those security-only updates — but it also names the operational trade-off the survey documents: teams delay patches because updates can break production, and that delay is exactly what attackers exploit.

For enterprises running large Java estates, the practical question the survey leaves open is whether patch pipelines built for a slower adversary can be re-engineered — through better visibility, unbundled security fixes, or automated testing — before the next record-breaking OpenJDK update arrives.