The short answer
Azul announced on 23 July 2026 that it will deliver monthly Critical Security Patch Updates (CSPUs) for Java — replacing the traditional quarterly cadence — for both Azul Core and Azul Prime, beginning in August 2026. The patches ship on the third Tuesday of each month when a high-priority fix warrants it, and cover every supported long-term-support release: Java 8, 11, 17, 21 and 25, plus the current release Java 26 and even legacy Java 6 and 7.
The updates are deliberately security-only: CVE fixes without the unrelated feature or behavior changes a full patch-set update can carry. Azul's argument is that AI now accelerates both the discovery and the exploitation of vulnerabilities, so leaving a serious flaw unpatched for up to 90 days until the next quarterly drop is an exposure window enterprises can no longer accept. If you run Java in production, the takeaway is practical: the speed at which your Java runtime receives security fixes is now something you choose, not something you inherit.
What Azul actually changed
For most of Java's history, security fixes have arrived on a quarterly beat. Oracle publishes its Java Critical Patch Updates four times a year — in January, April, July and October — and the broader OpenJDK ecosystem has largely synchronized to that rhythm. Azul, a long-standing commercial JDK vendor, is now breaking from it: rather than waiting for the next quarter, it will issue a Critical Security Patch Update on the third Tuesday of any month in which a high-priority fix is warranted, giving customers a predictable monthly window instead of a quarterly one.
The scope is deliberately broad. Azul's monthly CSPUs will span all the Long-Term Support versions it supports — Java 8, 11, 17, 21 and 25 — as well as the current release, Java 26. Notably, the company is extending the same schedule to Java 6 and 7, aimed at organizations still running those releases in production long after community support ended. Both Azul Core (its OpenJDK-based build) and Azul Prime are included. Co-founder and CEO Scott Sellers framed the change as setting a benchmark, calling monthly security-only updates “the new standard Azul is setting for how enterprises protect their Java estates.”
One design choice matters more than the calendar. These are security-only updates — Critical Patch Updates in the classic sense, carrying CVE fixes without the additional changes bundled into a full patch-set update. That distinction is what makes a faster cadence realistic: a security-only build changes less, so it is easier to test and less likely to introduce a regression, which is precisely the objection that keeps teams from patching more often.
Why quarterly stopped being enough
The logic behind the shift is about exposure math. Under a quarterly schedule, a vulnerability that becomes public the day after a release can sit without an official vendor fix for nearly three months. That was tolerable when weaponizing a flaw took skill and time. It is far less tolerable now that attackers can move from a fresh disclosure to a working exploit in hours — a compression that security teams increasingly attribute to AI-assisted vulnerability research and exploit generation.
That pressure is not unique to Java, and the wider industry is feeling it the same week. In its August 2026 Patch Tuesday forecast, Help Net Security described a “patch apocalypse” driven by AI-powered vulnerability discovery, and noted that Microsoft is now recommending an aggressive three-day patching turnaround to stay ahead of AI-accelerated threats. The same report made the counterpoint that matters for planning: of more than 600 CVEs disclosed in a single recent month, only a handful were actually being exploited. The signal for teams is not “patch everything instantly” but “be able to patch the exploited things fast” — and a monthly vendor cadence is what makes that speed routine rather than heroic.
Patch cadence is now a vendor decision
The most useful way to read Azul's announcement is not as one vendor's press release but as a sign that how fast your JDK ships security fixes has become a selection criterion. For years, teams chose a Java distribution on licensing and cost — Oracle's paid JDK versus free builds like Eclipse Temurin, Amazon Corretto or the Microsoft Build of OpenJDK. Those builds still largely track the quarterly OpenJDK updates. Azul moving to monthly changes the comparison: two distributions of the “same” Java can now differ by up to two months in how quickly a critical fix reaches you.
That does not mean everyone should switch vendors. It means the choice deserves a fresh look with security cadence on the scorecard next to license terms and support. If you are locked to a distribution that only patches quarterly, you should know that and compensate — with tighter monitoring, faster internal rebuilds, or compensating controls around exposed services. The point is to make the cadence an explicit, owned decision rather than a default nobody revisited since the last modernization project.
What it means for US & EU software teams
The first implication is operational: a faster cadence only helps if your pipeline can consume it. A monthly security build that still requires a person to download a JDK, rebuild images and manually smoke-test is a monthly interruption, not an improvement. The teams that turn this into an advantage automate the path — a new security build triggers a rebuild, runs the existing test suite, and promotes through environments with a human approving rather than assembling it. Building that once converts every future Java CVE from an incident into a routine merge.
The second is architectural discipline around legacy. A great deal of production Java is still on 8 or older, often inside systems nobody wants to touch. Azul extending monthly patches to Java 6, 7 and 8 is a lifeline for those estates — but it also removes the excuse. If a core banking or claims system runs an ancient JDK, “we can't patch it” is increasingly a decision, not a constraint, and a reviewable one. This is exactly where planned software modernization earns its keep: getting a legacy runtime onto a supported, regularly patched build is often the highest-leverage security work available, and far cheaper than the breach it prevents.
The third is compliance, and it hits regulated work hardest. Frameworks like DORA, SOC 2 and PCI DSS all expect timely, documented patching of known vulnerabilities. A defined monthly Java patch process — with an owner, an SLA and an audit trail of which build shipped when — is not just good hygiene; it is the evidence an assessor asks for. For FinTech and HealthTech teams especially, being able to show that a critical Java CVE was remediated within a bounded window, on a predictable cadence, turns a recurring audit question into a solved one.
What to do now
You do not need to change vendors this quarter. You do need to treat Java patch cadence as something you manage on purpose. Here is the shippable version.
- Inventory your JDKs. List which distribution and version every service, container image and build agent actually runs — teams are routinely surprised by how many Javas are in the estate.
- Automate JDK patching. Wire new security builds through your CI/CD pipeline and test suite so an update is a merge, not a manual project.
- Separate security from features. Apply security-only patches on their own track, decoupled from larger version upgrades, so a critical fix never waits on a risky migration.
- Prioritize known-exploited CVEs. Don't treat every advisory as an emergency; move fastest on flaws with evidence of active exploitation on exposed systems.
- Cover the legacy tail. Make sure any Java 6, 7 or 8 systems are on a build that still ships fixes — or put a modernization plan behind them.
- Document the cadence. Record your patch process, owner and SLA as evidence for DORA, SOC 2 and PCI DSS.
Azul's move is one vendor's decision, but it names a trend that is bigger than any single JDK: as AI shortens the gap between disclosure and exploitation, quarterly security maintenance is quietly becoming a risk of its own. The teams that build a monthly rhythm into their platform now will absorb the next Java CVE as a routine update — while the ones still patching by calendar quarter discover, again, how long 90 days can be.
Frequently asked questions
What did Azul announce about Java security patches?
On 23 July 2026 Azul said it will deliver monthly Critical Security Patch Updates (CSPUs) for Java, replacing the traditional quarterly cadence, starting in August 2026. The patches ship on the third Tuesday of each month when a high-priority fix warrants it, cover all supported LTS versions — Java 8, 11, 17, 21 and 25 — plus the current release Java 26 and legacy Java 6 and 7, and apply to both Azul Core and Azul Prime. They are security-only updates that fix CVEs without bundling unrelated changes.
Why is Azul moving from quarterly to monthly updates?
Azul argues the quarterly rhythm can no longer keep pace with the threat landscape. A serious vulnerability that surfaces just after a scheduled update can sit unpatched for up to about 90 days before the next quarterly fix ships. Azul cites AI accelerating both vulnerability discovery and exploitation as the reason that exposure window is now unacceptable, and positions monthly security-only updates as the new standard for protecting enterprise Java estates.
Does this affect Oracle Java or other JDK distributions?
The monthly cadence is Azul's own commitment for Azul Core and Azul Prime. Oracle continues to ship its Java Critical Patch Updates on a quarterly schedule, and other builds — such as Eclipse Temurin, Amazon Corretto and the Microsoft Build of OpenJDK — set their own release timing, typically tracking the upstream OpenJDK quarterly updates. The practical takeaway is that patch cadence is now a real differentiator between JDK vendors, so teams should know which distribution they run and how fast it ships security fixes.
Will monthly patches break our applications?
Azul's CSPUs are designed to be security-only — CVE fixes without the unrelated feature or behavior changes that a full patch-set update can carry — which is meant to keep the regression risk low and make each update easier to test and deploy. More frequent updates do increase change-management load, so the way to absorb them is to automate JDK patching in your CI/CD pipeline, run your existing test suite against each candidate build, and separate security-only patches from larger version upgrades.
What should engineering teams do now?
Inventory which JDK distribution and version every service runs, including containers and build agents. Automate JDK patching so a new security build flows through your pipeline and test suite without manual toil, and decouple security-only updates from feature upgrades. Prioritize known-exploited CVEs rather than treating every advisory as an emergency. Make sure any legacy Java 6, 7 or 8 estate is covered by a vendor that still ships fixes. For regulated FinTech and HealthTech work, document the patch process and cadence as evidence for DORA, SOC 2 and PCI DSS.
Sources
Azul Newsroom — Azul to Deliver Monthly Critical Security Patch Updates for Java Across All Supported LTS Versions
Help Net Security — August 2026 Patch Tuesday forecast: How do we deal with the patch apocalypse?
SecurityBrief — Azul to launch monthly Java security patch updates
Enterprise Times — Azul to Deploy Monthly Updates for Java