Security Patching Cadence by Distribution

Security updates for Java follow a predictable quarterly schedule, and credible distributions publish their fixes on that cadence at no charge. The risk is not that free Java goes unpatched, it is that a free support window quietly ends, so the buyer job is to track cadence and window together.

The quarterly schedule that governs Java security

Java security fixes follow a fixed quarterly rhythm. Critical patch updates land in January, April, July, and October, on dates published well ahead of time. This schedule comes from upstream and flows to every credible distribution, so the cadence itself is not a point of difference. What differs is whether a given distribution publishes its build of those fixes on time, and for how long it keeps doing so for free on the release you run.

How distributions track the upstream fixes

Because the fixes originate upstream and the distributions share that source, a well run build publishes its patched release within the same window as the quarterly update. The major vendors do this reliably on their supported releases. The question for a buyer is not whether the fix exists, since it is the same fix everywhere, but whether your chosen distribution ships it promptly and whether your release is still inside its free window. Both of those are published policies you can check.

The real risk is a window that closes quietly

The failure mode is rarely a missed patch. It is a release whose free support window has ended without anyone noticing, so the quarterly fix simply stops arriving for that build. The runtime keeps working, which is what makes it dangerous, because the gap is invisible until a scanner or an auditor finds it. The buyer job is to track two things together for every release in the estate: the cadence, which is shared, and the free window, which is per distribution and per release. Our look at long term support across Java distributions goes deeper on how those windows differ.

What risk teams should check

1. Which distribution and release each workload runs, in a current inventory.
2. Whether each release is still inside its free support window.
3. How quickly the distribution publishes its quarterly fix after the upstream date.
4. Who owns applying the update, and on what schedule after release.
5. Where an older release needs a paid agreement to keep receiving fixes.

Patching is an audit posture, not just a security one

Staying current matters for more than security. A patched, well governed estate is also a stronger position in an Oracle Java audit, where the examination intensified in 2026 with a three year lookback over deployment history. Being able to show a clean, documented patch trail on a free distribution demonstrates control and undercuts the case for paying a per employee fee. For the framework that ties distribution choice to patch discipline, see our guide to how to choose a Java distribution.

Where this fits

A clean patch record on a free distribution strengthens both security and your Oracle Java negotiating position. For the licensing context and the per employee numbers, read our Oracle Java licensing guide for 2026.