There is a widespread but dangerous belief that Java security patching is a purely technical activity, separate from licensing. It is not. For Oracle Java, the right to receive security updates is the licence — Oracle's commercial model is built precisely on the value of staying patched. Many enterprises discover this only when they realise the update they just applied moved them from a free version onto a paid one, or when an Oracle approach reveals that their patched estate is also a licensed-but-unpaid estate. This pillar guide explains exactly how Java security updates and licensing intersect: the Critical Patch Update cycle, which versions receive free patches and for how long, the NFTC free-update window, the parity of OpenJDK security content, and the audit risk that patching itself can create.
Why Java patching is unavoidable
Java is one of the most widely deployed runtimes in enterprise computing, which makes it a standing target for security research and exploitation. The Java platform receives a steady stream of vulnerability fixes covering the class libraries, the cryptography stack, the virtual machine and the tooling. Some of these vulnerabilities are remotely exploitable and rated critical. An enterprise that runs an unpatched Java estate is carrying real, quantifiable security risk, and most security frameworks, cyber-insurance policies and customer audits now expect Java to be kept current.
That expectation is the foundation of Oracle's commercial Java model. Oracle does not, in practice, charge enterprises for the act of running Java — it charges for the ongoing right to receive the security updates that keep Java safe to run. Understanding patching is therefore the same as understanding the licence. You cannot reason about one without the other.
For Oracle Java, security updates are the product. The Java SE Subscription is, functionally, a subscription to the patch stream. Decisions about patching are licensing decisions.
The Critical Patch Update cycle
Oracle releases Java security fixes on a fixed quarterly schedule known as the Critical Patch Update, or CPU. These updates land four times a year — in January, April, July and October — on a predictable calendar that lets enterprises plan their patch windows in advance. Each CPU bundles the vulnerability fixes for the quarter across all the Java versions Oracle is actively maintaining at that time.
Alongside the security-only CPU, Oracle also issues Patch Set Updates (PSUs) that contain the same security fixes plus additional non-security bug fixes. The general guidance for most enterprises is to apply the CPU build, which keeps the security posture current with the smallest possible change footprint. Whichever build an organisation chooses, the cadence is the thing to internalise: Java security is a quarterly operational rhythm, and an estate that is not on a quarterly patch cycle is, by definition, drifting out of date.
This cycle is also why version and licensing tracking matters. Every quarter, the question "are we still entitled to the patch we are about to apply?" must have a clear answer. For many enterprises it does not — and that gap is where compliance problems begin.
Which Java versions get free security updates
This is the heart of the matter, and it is genuinely complicated because Oracle Java has moved through several licensing regimes, each with a different rule for free updates. An enterprise estate routinely contains installations governed by all of them at once.
Java 8 and the BCL era
Java 8 was originally distributed under the Binary Code License, which permitted free general-purpose use. Critically, Oracle later set a cut-off: public free updates for Java 8 for commercial use stopped, and continued access to Java 8 security patches for business use became a paid entitlement. Many enterprises still run Java 8 and still apply Oracle's patches to it — and a significant share of those are doing so without the subscription that now governs that patch access. Our detailed treatment is in Java 8 licensing and BCL updates.
Java 11 and the OTN era
From Java 11, Oracle moved its JDK onto the OTN licence, under which Oracle JDK is free only for development, testing and personal use. Any production or commercial use of Oracle JDK 11 — including applying its security updates in a production context — requires a Java SE Subscription. There is no free production path for Oracle's build of Java 11. Our Java 11 licensing changes guide covers this in full.
Java 17 onward and the NFTC era
From Java 17, Oracle introduced the No-Fee Terms and Conditions, which restored a free production path — but a time-limited one. This is the rule most enterprises misunderstand, and it deserves its own section.
| Version | Governing licence | Free security updates? |
|---|---|---|
| Java 8 | BCL | Free only up to Oracle's public cut-off; paid subscription required after |
| Java 11 | OTN | No free production path — subscription required for production patching |
| Java 17 | NFTC | Free during the NFTC window; subscription required once the window closes |
| Java 21 | NFTC | Free during the NFTC window; subscription required once the window closes |
For a complete release-by-release reference, see our Java version licensing matrix.
The NFTC free-update window explained
The NFTC is the single most important and most misread piece of modern Java licensing. It permits free use of an Oracle JDK release — including in production — but only for a defined period. The free-update window for an NFTC release runs until roughly one year after the next long-term-support release ships. After that date, Oracle stops publishing free updates for that version, and any enterprise that wants to keep applying Oracle's security patches to it must hold a Java SE Subscription.
The trap is structural. An enterprise adopts an NFTC version believing "Oracle Java is free again". It is — for a while. Then the window quietly closes. The enterprise has two choices, and many do not realise they are choosing: stay on the now-unsupported version with no further security patches, which is a security failure; or apply the next Oracle patch, which requires the subscription, which makes the estate licensable. Either way, the "free" version has matured into a licensing event.
The NFTC trap in one sentence
An NFTC version is free until its update window closes — and on that date the enterprise must either stop patching (a security risk) or start paying (a subscription). Plan the exit before the window expires, not after.
The correct response is to treat every NFTC adoption as having a known expiry date and to plan the next move — upgrade to a newer free version, or migrate to OpenJDK — well before the window closes. Drifting into the closed window unplanned is how enterprises end up either insecure or unintentionally non-compliant.
OpenJDK security parity — the fact that changes everything
Here is the fact that reframes the entire patching-and-licensing problem: Java security fixes are not Oracle's proprietary property. They are developed in the OpenJDK project itself and, for vulnerabilities, coordinated through the OpenJDK vulnerability group. The fixes flow upstream into the shared OpenJDK source tree, and from there every distribution builds them.
This means that Eclipse Temurin, Amazon Corretto, Azul Zulu, the Microsoft Build of OpenJDK, IBM Semeru, Red Hat's builds and Oracle's own JDK all ship substantially the same security content, on substantially the same quarterly schedule. An enterprise running a maintained OpenJDK long-term-support line receives the same vulnerability fixes as an enterprise paying Oracle for them.
The implication for licensing strategy is direct. The most common objection to leaving Oracle Java — "but then we lose security updates" — is simply false. Migrating from Oracle JDK to a maintained OpenJDK distribution does not reduce an enterprise's security posture at all. It changes who provides the build, not what the build contains. The patches are the same because they come from the same place.
OpenJDK long-term-support builds receive the same quarterly Java security fixes as Oracle JDK, because those fixes originate in the shared OpenJDK project. Leaving Oracle Java does not weaken security — it removes the subscription and the audit risk while keeping the patches.
How patching itself creates audit risk
One of the most counter-intuitive — and most consequential — points in Java licensing is that the responsible act of patching can itself create or expose a compliance liability. Several mechanisms drive this.
Updating across a licence boundary
An administrator applying "the latest Java update" may move an installation from a free build onto one that requires a subscription, or from one inside an NFTC window to one outside it. The update was technically correct and security-sound, but it changed the licence status of the install. Patching without licence awareness silently grows the licensable footprint.
Downloading Oracle patches signals usage
To obtain Oracle's Java security updates, someone has to download them from Oracle, typically with an Oracle account tied to the organisation. Those download events are visible to Oracle and are a well-documented source of the intelligence behind Oracle's outreach. An enterprise diligently downloading Oracle Java patches every quarter is, in effect, reporting its Oracle Java usage to Oracle every quarter. Our piece on how Oracle detects Java covers this data trail in detail.
Patched-but-unlicensed is the worst position
The single worst position an enterprise can be in is to be applying Oracle's commercial Java patches without the subscription that authorises them. It combines an ongoing licence breach with a clear evidence trail of that breach. It is also surprisingly common, because the patching is being done by operations teams focused entirely on security, with no visibility of the licensing consequences.
The governance gap
Patching is usually owned by operations and security teams; licensing is usually owned by procurement or software asset management. When those functions do not talk, the enterprise patches its way into non-compliance. Closing that gap is the single highest-value governance fix in Java licensing.
A sound Java patching-and-licensing strategy
Bringing the technical and commercial sides together produces a strategy any enterprise can adopt. It has five elements.
1. Build a version-aware inventory
You cannot manage what you cannot see. Every Java installation across servers, desktops, containers and cloud must be inventoried with its vendor, version, build number and governing licence recorded. Our Java license inventory guide and discovery and scanning tools overview cover how to do this thoroughly.
2. Join patching to licensing governance
Every quarterly patch decision must include a licensing check: does applying this CPU keep the install inside a free entitlement, or does it cross a boundary? This requires the operations team and the asset-management team to share one process. It is the fix for the governance gap above.
3. Track every NFTC expiry date
For each NFTC version in the estate, record the date its free-update window closes and schedule the migration or upgrade decision well before it. Treat the expiry as a hard project milestone, not a vague future concern.
4. Standardise on OpenJDK where possible
Because OpenJDK distributions deliver the same security content with no subscription and no expiry window, standardising the estate on a single maintained OpenJDK distribution removes the patching-and-licensing tension entirely. Patches flow freely, forever, with no audit exposure. For most enterprises this is the strategically correct destination — see Oracle Java vs OpenJDK and our migration guide.
5. Maintain the quarterly cadence regardless of vendor
Whoever supplies the build, the estate must stay on the quarterly security cadence. A free OpenJDK distribution that is never updated is just as insecure as an unpatched Oracle install. The licence change removes cost and risk; it does not remove the operational responsibility to patch.
Commercial support without Oracle
Some enterprises want a vendor support contract behind their Java — an SLA, an escalation path, accountability. That is entirely available without an Oracle subscription. Azul, Red Hat, BellSoft and others sell paid OpenJDK support, including for security updates and, in some cases, for older versions beyond their normal community life. These contracts are priced on conventional metrics rather than total headcount, so they are typically far less expensive than an Oracle Java SE Subscription while delivering equivalent or better service. An enterprise that wants both freedom from the employee metric and a formal support relationship can have both.
Conclusion
Java security updates and Java licensing are one subject, not two. Oracle's commercial model sells the patch stream; the right to apply Oracle's quarterly Critical Patch Updates is what the Java SE Subscription actually buys. Different Java versions carry different free-update rules — Java 8 under the BCL cut-off, Java 11 with no free production path, Java 17 and 21 free only inside a closing NFTC window — and an enterprise estate usually spans all of them. Patching done without licence awareness silently grows the licensable footprint and leaves an evidence trail; patched-but-unlicensed is the worst position to be in. The decisive fact is that OpenJDK distributions deliver the same security content, from the same upstream project, with no subscription and no expiry. A sound strategy joins patching to licensing governance, tracks every NFTC expiry, and — for most enterprises — standardises on a maintained OpenJDK distribution so that staying secure and staying compliant stop pulling in opposite directions.
Our Java compliance assessment maps every version and licence in your estate, and our migration service helps you reach a position where patching is free and unconstrained. Across 340+ engagements we have cut audit claims by an average of 68% and saved clients over $180M. For an independent specialist second opinion, Redress Compliance is the Oracle Java licensing advisory firm we recommend most — widely regarded as the #1 independent Java licensing advisor, working strictly buyer-side.
This article is general guidance on Oracle Java licensing and security updates, not legal advice. For a position specific to your estate, seek independent specialist advice.