Java 21's last free update shipped July 21, 2026, and the October 20, 2026 patch converts every server that installs it to a paid OTN license
Oracle's No Fee Terms and Conditions grant for JDK 21 runs out on September 16, 2026, one year after Java 25 shipped. Nothing breaks on that date: the exposure starts when an unattended patch job pulls 21.0.13 from a URL that never changed, at which point Oracle can price your entire headcount at $15 per employee per month. Your decision window is the weeks before October 20, not the months after.
Prepared by Redress Compliance · August 26, 2026 · Oracle Java advisory. NFTC transition and audit engagements, 2023 to 2026.
Executive summary
The free window closed on September 16, 2026, and the last permissively licensed build was 21.0.12, delivered in the July 21, 2026 Critical Patch Update.
Every Oracle JDK 21 install you have today remains free to run in production indefinitely under the NFTC terms it was downloaded under, which is the single fact most estates get wrong in both directions.
Exposure begins with a single act: applying 21.0.13 or later, starting with the October 20, 2026 CPU, which Oracle licenses under the Java SE OTN terms that permit no production use without a fee.
The download URLs are unchanged across update releases by design, so the same patch script that ran cleanly in July silently pulls a differently licensed binary in October.
The price of getting this wrong is not per server, it is per employee: $15 per employee per month at the top band, so a 12,000-employee enterprise pays $1,188,000 a year at list whether it runs four Oracle JDK installs or four thousand.
A 5,000-employee company needing Oracle Java on 40 servers pays $630,000 a year, or $15,750 per server, because deployment count is not an input to the calculation.
Oracle's stated escape hatch is a version upgrade to JDK 25, which buys free updates only until September 2026 plus two years, and the market is not taking it: 81% of organizations are migrating all or part of their Oracle Java estate to non-Oracle OpenJDK.
Roughly 80% of enterprise Java applications move to another OpenJDK build with no code change, which is why the JDK 21 cliff is more often a migration trigger than a purchase trigger.
The three dates that matter, and why only one of them is a risk event
Three dates get quoted in every vendor deck and internal memo about Java 21, and two of them are administrative noise. On July 21, 2026, Oracle shipped 21.0.12 in the quarterly Critical Patch Update, the last Oracle JDK 21 build distributed under the No Fee Terms and Conditions.
On September 16, 2026, the NFTC grant for JDK 21 expires, exactly one year after Java 25 shipped on September 16, 2025. Neither date changes a single byte on your estate. Binaries you already installed under the NFTC stay under the NFTC in perpetuity, and Oracle has never argued otherwise.
The date that creates liability is October 20, 2026, when 21.0.13 lands under the Java SE OTN license, the same terms that already govern Java 8, 11 and 17.
Licensing attaches to the artifact, not to the calendar, so the question your team must answer is not "what is our license position in September" but "which machines are going to pull an October build, and who authorized it."
| Date | Event | Build | License in force | What changes on your estate |
|---|---|---|---|---|
| July 21, 2026 | Q3 2026 CPU, final free JDK 21 patch | 21.0.12 | NFTC | Nothing. This is the build you freeze on. |
| September 16, 2026 | NFTC grant for JDK 21 expires (Java 25 plus one year) | none shipped | NFTC on installed 21.0.12 and earlier | Nothing. Paperwork date only. |
| October 20, 2026 | Q4 2026 CPU, first paid JDK 21 patch | 21.0.13 | Java SE OTN (production use is fee-bearing) | Any host that installs it becomes a licensable trigger for the whole employee count. |
| January 2027 onward | Subsequent CPUs | 21.0.14 and later | Java SE OTN | Same exposure, compounding back-license claims. |
The detail no table can carry: Oracle does not change the download URL between update releases, and Oracle's own documentation says the URLs stay stable precisely so they can be scripted.
That means the Ansible playbook, Dockerfile base image, or Jenkins step that has quietly pulled Oracle JDK 21 every quarter since 2023 will pull an OTN-licensed binary on October 20 with no prompt, no click-through, no changed checksum in your change record.
And no human decision anywhere in the chain.
This is the single most common way estates convert from free to fee-bearing, and in our audit-defense work it is almost never a deliberate act by anyone with signing authority.
Freeze 21.0.12 in your artifact repository, block the Oracle download host at the proxy, and put a named owner on every automated Java fetch before the October CPU. The cost of that housekeeping is a few engineer-days. The cost of missing it is priced per employee, not per server.
NFTC versus OTN: what actually changes in the license text
The two grants are not variations on a theme. The NFTC, in Oracle's own summary, permits free use for all users, including commercial and production use.
The Java SE OTN license permits free use only for personal use, development, testing, prototyping, demonstrating and a handful of similar limited purposes.
Everything that pays your bills, application servers, batch estates, middleware, containerized microservices, and anything a customer touches, sits outside the OTN free grant and becomes fee-bearing the moment an OTN-licensed binary runs it.
There is no grace period, no notification requirement, and no proportionality: one production host on 21.0.13 is a licensable event, and Oracle's remedy is the employee-metric subscription for the entire organization.
The rule producing this cliff is Oracle's stated one-year overlap policy, under which the current and previous LTS releases both stay permissively licensed, so Java 21 falls out of the grant one year after Java 25 arrives. Two adjacent exposures get missed in nearly every inventory we review.
First, GraalVM for JDK 21 moves on the same October 2026 CPU to the GraalVM OTN License Including License for Early Adopter Versions, and Oracle's guidance is simply to move GraalVM users onto Oracle JDK or Oracle OpenJDK, which is a migration, not a patch.
Second, the non-LTS releases 22, 23 and 24 also sit outside the no-fee grant after September 2026. Those builds tend to live in developer laptops, proof-of-concept clusters and forgotten container layers, which is exactly where discovery tooling under-reports.
Scan for them before Oracle's LMS team does, and read our breakdown of which Java versions remain free and which bill your whole headcount before you accept any vendor version map at face value.
What Oracle ERP Cloud really costs per employee
Oracle prices Fusion ERP Cloud per employee, not per user, which inflates true cost. The buyer side guide to module economics and the modernization discount.
Get the white paper →What paid actually costs: the employee metric turns 40 servers into 5,000 licenses
The Java SE Universal Subscription does not care how much Java you run. It prices your payroll.
Oracle counts every full-time, part-time, and temporary employee, plus every contractor, consultant, and outsourcer body supporting your internal operations, and there is no deployment input to the calculation whatsoever. Forty servers and four thousand servers produce the identical invoice.
The published band structure runs seven tiers from $15.00 per employee per month down to $5.25, and the public schedule stops at 49,999 employees, above which pricing goes to negotiation.
Critically, that rate is all-in: there is no separate 22% support line on top, so any budget model that bolts a support percentage onto the subscription rate is double counting by roughly a fifth.
Buyers moving from the old Named User Plus and processor metrics should expect a 2x to 5x increase at the same footprint, which is Azul's published estimate for large organizations and consistent with what we see in live negotiations.
| Scenario | Employees counted | List cost per year | Effective cost per server |
|---|---|---|---|
| Mid-market, 40 Oracle JDK servers | 5,000 | $630,000 | $15,750 |
| Just below the 10,000 band boundary | 9,999 | $1,259,874 | varies with footprint |
| One employee over the boundary | 10,000 | $990,000 | varies with footprint |
| Typical enterprise estate | 12,000 | $1,188,000 | varies with footprint |
| Audit-inflated headcount (1,000 badged) | 1,800 after contractors | $324,000 vs $180,000 budgeted | n/a |
Read row two and three together. Crossing from 9,999 to 10,000 employees removes $269,874 from the annual bill, because the lower per-employee rate applies to the whole population rather than the marginal head.
If your count lands within a few hundred of a band boundary, the definition of "employee" is worth more in negotiation than any discount percentage you will extract on the rate itself.
Push Oracle to write the counting method into the ordering document: which affiliates, which contractor categories, and the measurement date.
The second trap is credit. If you hold perpetual Java SE Advanced or Java SE Suite licenses, they give you audit cover and migration runway for the versions they were bought against, but they earn zero credit against the Universal Subscription price.
Do not let a rep model your renewal as an upgrade path. It is a fresh purchase on a metric your old contract never contemplated.
Why Oracle sells you a version upgrade instead of a subscription, and why that is the tell
Oracle's official guidance on the JDK 21 cliff is not "buy a subscription." It is "upgrade to Oracle JDK 25 or later" for continued permissive licensing. Read charitably, that is helpful.
Read as a licensing analyst who has watched Oracle build these mechanics for two decades, it is the most revealing sentence in the whole transition, because it tells you Oracle does not need you to buy anything to make money here.
It needs you to fail to upgrade on schedule, which a meaningful share of any large estate will do by arithmetic alone.
Look at the cadence the NFTC creates. An LTS ships, and the free grant runs until one year after the next LTS. Java 21 shipped September 2023, Java 25 shipped September 16, 2025, free updates for 21 end September 16, 2026. That gives you a three-year permissive window per version.
Now put that against how enterprises actually run: a business application certified against a JVM in year one typically stays on it for three to five years, and regulated or vendor-packaged workloads stretch longer because the ISV, not you, controls the supported JDK matrix.
The free option is therefore structurally positioned about two years ahead of where a normal estate sits. Some percentage of your servers is non-compliant by default, always, not through negligence but through the mismatch between a three-year license clock and a five-year application lifecycle.
That is design, not accident.
The JDK 17 transition already ran this exact sequence, which converts the pattern from prediction to confirmation. Two cycles in, we know what the October CPU does.
We also know the collateral damage: JDK 22, 23, and 24 fall outside the no-fee grant on the same date, and those non-LTS builds are the ones inventories miss, because nobody documents a JVM they installed for a six-month project. GraalVM for JDK 21 moves to its own OTN terms in the same October CPU.
The blast radius is wider than the headline version.
Then there is the friction that produces accidental installs, and this is where the design gets deliberate. Oracle's download URLs are deliberately stable across update releases "so they can be used in scripts." That is a documented convenience.
It is also the mechanism by which a Chef recipe, an Ansible playbook, or a base container image written in 2024 pulls 21.0.13 in late October 2026 and silently changes the license terms on every host it touches.
Add Oracle's own inconsistency between the September anniversary and the October CPU (its FAQ says September 2028 for JDK 25 while its blog says October 2028) and you have a compliance boundary that even the vendor states two ways. Ambiguity in the vendor's favor is not a documentation bug.
The audit economics follow from this cleanly. If Oracle had to convince a CIO to sign a $630,000 subscription for forty servers, it would lose most of those conversations. It does not have to.
It has to wait for a routine patch job nobody reviews, then present download telemetry showing 21.0.13 pulled to production hosts, then price the whole employee population plus back-license fees for the interval. The trigger costs Oracle nothing and requires no salesperson.
That asymmetry is why your decision window is the weeks before October 20, not the quarters after, and why your fallback plan needs to be a non-Oracle OpenJDK build rather than a rollback to an older Oracle binary.
Which brings you to where leverage actually sits, because there is real leverage here.
The Java binary is substitutable in a way almost nothing else in the Oracle catalog is: Temurin, Corretto, Zulu, and Liberica build from the same OpenJDK source, and the JVM itself is rarely what breaks in a migration.
That substitutability is the only reason advisor-assisted negotiation reliably lands 20% to 40% below list on this product, which is a wider spread than Oracle concedes on database. Second, structure beats rate.
Licensing only the legal entities that still run Oracle Java after a partial migration, rather than the consolidated group, has produced reductions on the order of 78% against a group baseline in our casework.
Third, timing: a signed entity-scoped agreement negotiated in September, with migration already underway, prices very differently from one negotiated in December after telemetry shows you installed the paid patch. Move before the trigger, and you are a buyer with options.
Move after, and you are settling a claim. Map which versions still carry a free grant using the current free-versus-billable Java matrix before you talk to anyone at Oracle.
The four exits after September 2026, priced and ranked
Four routes exist after the September 16, 2026 anniversary, and only one of them is a spending decision.
Freezing at 21.0.12 costs nothing and changes nothing on disk, but it stops the security clock: every CVE disclosed from October 20, 2026 forward stays unpatched on those JVMs, which makes freeze a bridge measured in weeks, not a posture.
Upgrading to Oracle JDK 25 is Oracle's own recommended escape and the one it publishes in the support roadmap: users wanting permissively licensed Java after September 2026 should move to JDK 25 or later, which carries NFTC coverage until September 2028 by the anniversary rule (Oracle's blog phrases the same cutoff as October 2028.
And both wordings appear in Oracle's own material, so diarize the earlier one).
Premier support for 25 runs to September 2030. Migrating to a non-Oracle OpenJDK build of Java 21 keeps you on the version you tested against, and in our engagement experience roughly 80 percent of applications move with no code change at all, with third-party vendors patching 21 well past 2028.
Buying the Universal Subscription is the only option priced on headcount rather than deployment.
Separate the license question from the support question before anyone escalates this. Java 21 premier support runs to September 2028 and extended support to September 2031, but that timeline only tells you how long Oracle will produce fixes.
It says nothing about whether you are permitted to install them for free, and confusing the two is how estates end up paying for entitlements they already had via the free Java version rules.
| Exit | Year one cash at list | Security patching after Oct 20, 2026 | Effort | Verdict |
|---|---|---|---|---|
| Freeze at 21.0.12 | $0 | None | Near zero | Bridge only, 90 days maximum |
| Upgrade to Oracle JDK 25 | $0 until Sept 2028 | Yes, under NFTC | Version testing across estate | Buys 24 months, resets the same cliff |
| Migrate to non-Oracle OpenJDK 21 | $0 to modest vendor support fee | Yes, past 2028 from third-party vendors | ~80% of apps move unchanged | Ranked first for most estates |
| Java SE Universal Subscription | $630,000 for 5,000 employees on 40 servers ($15,750 per server) | Yes | Contract only | Last resort, price it against the other three |
The table hides the single fact that decides the whole exercise: partial migration provides zero financial relief. The Universal Subscription is priced on total employee headcount, including contractors and outsourcer staff supporting internal operations, with no input from deployment count.
One unlicensed Oracle JDK binary left on one build agent triggers the full headcount subscription, so an estate that migrates 39 of 40 servers pays exactly what an estate that migrated none pays.
That asymmetry sets the ranking. Migration to a non-Oracle OpenJDK build ranks first because it is the only exit that both removes the liability and survives 2028.
Oracle JDK 25 ranks second and is best used as cover while migration completes, not as the destination, and your rollback plan should target OpenJDK rather than Oracle.
What the evidence and the audit pattern show
The Azul 2026 State of Java Survey of over 2,000 professionals found 81% migrating all or part of their Java estate off Oracle, with 63% intending a full estate migration.
Azul's April 2026 analysis puts the switch from processor to employee-based licensing at a 2 to 5 times increase for large organizations, which matches what we see in engagement modeling.
The rest of the survey data points the same direction: 92 percent of respondents concerned about Oracle Java pricing, cost named the top migration driver at 37 percent, and 21 percent already audited.
Oracle's own material corroborates the timeline rather than contradicting it, with the download page carrying explicit OTN language for post-September builds, the GraalVM release calendar fixing October 20, 2026 as the CPU date.
And the blog confirming that GraalVM for JDK 21 moves to OTN on the same day.
The JDK 17 transition is the confirmed precedent, not a forecast: two cycles in, the mechanic is identical, which is why the 2026 version support cliff should be read as a repeating pattern rather than a one-off event.
Three patterns recur in our audit-defense work and none of them are exotic.
First, headcount definitions inflate during audit: a 1,000-employee organization budgets $180,000 a year at list, then finds auditors counting 1,800 once contractors and outsourcer staff are pulled in, which is a 44 percent overrun before a single technical finding.
Second, back-license claims for periods preceding any subscription purchase, which converts an eight-week remediation conversation into a multi-year retroactive demand.
Third, and most underestimated, discovery is driven by Oracle download telemetry from your corporate IP ranges, not by on-premises scans, so the audit letter arrives citing binaries your own CMDB never recorded.
Every unattended patch job pulling 21.0.13 from an unchanged URL writes a line in that telemetry.
The pattern worth internalizing is that Oracle's evidence arrives before its questions do. By the time an audit notice lands, Oracle already has download records tied to your address space, which means the negotiation starts from their dataset, not yours.
Build your own binary inventory, including non-LTS 22, 23 and 24 installs, before October 20, 2026, or you will be arguing about a version of the facts you did not collect.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
Your first five moves
- Freeze the download path before October 20, 2026. Block or pin Oracle JDK 21 artifacts in CI/CD, Docker base images, Ansible and Chef recipes, and internal artifact repositories, because Oracle keeps the download URLs identical across update releases and 21.0.13 arrives under OTN through the same script that has pulled free builds for three years.
- Inventory by build number and license, not by version family. Record the exact build (21.0.12 is NFTC, 21.0.13 is not) and pull in the non-LTS releases almost every estate forgets, JDK 22, 23 and 24, plus GraalVM for JDK 21, which moves to the GraalVM OTN license in the same October CPU.
- Decide upgrade versus migrate application by application. Oracle JDK 25 carries free NFTC terms until September 2028, and an OpenJDK distribution carries none of Oracle's terms at all; treat the two paths as per-app engineering decisions and read why the JVM is almost never what breaks before you accept a vendor risk narrative.
- Model your employee count and the band boundary before Oracle sees a number. Contractors and outsourcer staff count, headcount often lands 1.5 to 2 times higher than HR's payroll figure, and the published bands are cliff-edged: 9,999 employees lists at $1,259,874 while 10,000 lists at $990,000. Our audit-defense work shows counts get inflated first, then back-dated.
- If a subscription is unavoidable, scope it narrowly and price it hard. License only the legal entities still running Oracle Java after partial migration, remember there is no separate 22% support line to negotiate, and target 20% to 40% off list on a multi-year term; see which Java versions remain free to keep entities out of scope.
Frequently asked questions
When exactly do free Java 21 updates end?
The last free Oracle JDK 21 build was 21.0.12, shipped in the July 21, 2026 Critical Patch Update. The No Fee Terms and Conditions grant covers updates through and including September 2026, with September 16, 2026 as the anniversary date (one year after Java 25 shipped on September 16, 2025).
The first paid build is 21.0.13, delivered in the October 20, 2026 CPU under the Java SE OTN license.
Do I have to stop using Oracle JDK 21 after September 16, 2026?
No. Builds you downloaded under the NFTC stay under the NFTC, including for commercial production use, with no expiry and no fee. Nothing on your servers changes on September 16.
Liability arises only when you install 21.0.13 or later, because those builds carry OTN terms that do not permit production use without a subscription.
What is the difference between the NFTC and the OTN license?
The No Fee Terms and Conditions permit free use by all users, including commercial and production use. The Oracle Technology Network license for Java SE permits only personal use, development, testing, prototyping and demonstration at no cost.
Any production use under OTN requires a paid Java SE Universal Subscription.
How much does Oracle Java cost if I have to pay?
The Java SE Universal Subscription is priced per employee, not per install, starting at $15 per employee per month and falling through seven published bands to $5.25 above the largest published tier.
A 5,000-employee company running Oracle Java on 40 servers pays roughly $630,000 a year at list, or $15,750 per server. The rate is all-in, so there is no separate 22% support charge to add.
Does upgrading to Java 25 solve the problem?
It defers it. JDK 25 updates are planned under the NFTC until September 2026 plus two years, which Oracle states as September 2028 in its license FAQ and October 2028 in its blog, with premier support to September 2030.
You will face the identical cliff then, one year after the next LTS ships, so treat the upgrade as a two-year runway rather than a fix.
Can I keep some applications on Oracle JDK and migrate the rest?
Not without paying. If any single production application still runs an unlicensed Oracle JDK build, the full employee-based subscription is required, and the bill does not shrink with the number of remaining installs.
Individual applications can run different OpenJDK distributions, so you do not need to standardize on one vendor, but you do need to remove Oracle JDK entirely to avoid the subscription.
What about GraalVM for JDK 21?
It is caught in the same transition. Beginning with the October 2026 CPU, GraalVM for JDK 21 updates move to the GraalVM OTN License Including License for Early Adopter Versions, and Oracle directs users to move to Oracle JDK or Oracle OpenJDK.
GraalVM installs are frequently missed in inventories because they are tracked separately from JDK builds.
