Oracle JDK 21's free-update window closes with the October 2026 CPU, but the last no-fee binary ships in July 2026, leaving a 60-day gap most estates have not planned for

Oracle has said JDK 21 updates through and including September 2026 stay under the No Fee Terms and Conditions, and that the October 2026 CPU moves to the same OTN license already governing Java 8, 11 and 17. The operational reality is tighter: the last free JDK 21 update ships in July 2026, so any host you have not moved by then is running unpatched or running licensed. That gap, not the headline September date, is what decides whether you buy a $15 per employee per month subscription in Q4 2026 or finish a migration first.

Prepared by Redress Compliance · August 26, 2026 · Oracle Java advisory. NFTC transition and Employee-metric renewals, 2023 to 2026.

The No Fee Terms and Conditions license is not a promise about a Java version, it is a rolling grant tied to Oracle's LTS cadence, and the clock that matters started running before most estates noticed.

Oracle's stated rule is one year of overlap: when a new LTS ships, the previous LTS keeps its permissive grant for twelve more months, then moves to the Oracle Technology Network license that already governs Java 8, 11 and 17. JDK 25 shipped in September 2025.

That release, not any announcement, started the countdown on JDK 21.

Oracle has since confirmed the landing point: all JDK 21 updates through and including September 2026 remain under the NFTC, and beginning with the October 2026 CPU, further Oracle JDK 21 updates are planned under the Java SE OTN license.

Read that carefully, because the operative event is a build, not a calendar page. Nothing breaks on September 30, 2026.

What happens is that the next patch Oracle publishes carries different terms, and the moment you install it in production you have accepted a license that permits development, testing and demonstration only.

The identical mechanic already played out with Java 17: public updates through September 2024 were permissive, and updates released as of October 15, 2024 arrived under OTN.

Also note what falls with 21: JDK 22, 23 and 24 sit under the same September 2026 boundary, and GraalVM for JDK 21 has its own parallel move to the GraalVM OTN license at the October 2026 CPU.

If you are trying to decide which of your builds are already billable, our breakdown of which Java versions are free and which trigger a bill maps the same logic to the versions already past their cliff.

Oracle patches Java on a fixed quarterly cadence: January, April, July, October. That cadence, not the license text, is what sets your operational deadline, because a license grant that expires between two patch drops gives you nothing you can actually consume.

The July 2026 CPU is the last Oracle JDK 21 update distributed under the NFTC. The next update Oracle publishes is the October 2026 CPU, and that one arrives under OTN. So the September 2026 boundary in Oracle's own language describes a window in which no free binary exists to collect.

A host that took the July patch and stayed on JDK 21 sits unpatched from late July until it is either upgraded off Oracle's build or brought under subscription, and if the decision drifts into Q4 board cycles or a January 2027 budget refresh, that is roughly six months of exposure, not sixty days.

Quantify what that exposure means rather than treating it as an abstraction.

On the Java 8 line, Oracle had released 213 security patches since the last free update as of October 2024, and the assessment attributed to Gartner is that nearly all of them are exploitable over a network without authentication.

That is the profile of the Java patch stream generally, not a quirk of Java 8. Two quarters of missed JDK 21 CPUs is not a low-severity backlog you can carry through a change freeze; it is a set of remotely reachable defects in a runtime that typically sits on internet-facing middleware.

In our experience across audit-defense engagements, this is the exact argument security teams use to force an emergency Oracle subscription purchase in November or December, at list, with no competitive tension and no time to model the employee-metric bands.

The third date, September 16, 2026, is the Java.com free-use cutoff for Java 21 builds obtained from that channel. Treat it as a distraction for server estates and a genuine trap for desktop and developer workstation fleets, which frequently pull from Java.com without any inventory record.

Build your plan around July 2026. Before that CPU lands, every JDK 21 host should be either migrated to an OpenJDK distribution, priced into a subscription with a signed order, or formally accepted as a decommission candidate with a date.

Our note on why the JVM is almost never what breaks and your fallback must be OpenJDK covers the rollback design that makes a pre-July migration defensible to an application owner who is arguing for delay.

Every migration plan we have reviewed this year keys on the string "21". That is a discovery error with a price attached.

Certero's July 2026 reading of the grant is unambiguous: JDK versions 21, 22, 23 and 24 remain free under the NFTC until September 2026, and hosts still running those versions after that date fall outside the no-fee grant.

The three non-LTS releases sit on the same cliff edge as 21, on the identical day, with none of the surrounding narrative.

Nobody wrote a blog post about the JDK 23 end-of-permissive-license transition, because JDK 23 already ended its six-month support life in March 2025 and everyone assumed the story was over.

The confusion is structurally reasonable, which is why it is so widespread. Oracle's own licensing FAQ states that non-LTS releases such as JDK 24 are available under the NFTC for their entire planned six-month support life.

Engineering teams read that correctly and conclude there is no cliff to diarize: the release stops receiving updates, so the license question resolves itself. What that reading misses is that the NFTC grant covering the binary you already downloaded and deployed is not open-ended.

It expires in September 2026 alongside 21, whether or not that version was ever getting another patch.

An abandoned JDK 23 host is not licensed-in-perpetuity; it is a production install whose permissive grant ends on a date, and it will not appear on any upgrade-path spreadsheet because there is no upgrade path to speak of, only a jump to 25.

These hosts are also, in our experience, the ones nobody owns. Non-LTS releases get pulled in by a developer testing a preview feature, a container base image that never got repinned, or a build agent someone stood up in a sprint and forgot.

They rarely appear in the CMDB with a clean version attribute. In audit engagements, the Oracle JDK installs that surface late and hurt most are almost never the deliberate ones.

Run your discovery pass on a version-string range of 22 through 24 as well as 21, and treat any hit as production until proven otherwise.

Query java -version output and installed-package inventories across servers, build infrastructure, container registries and developer laptops, then reconcile against the version-by-version position in which Java versions are free and which trigger a bill.

A JDK 24 install on a CI runner in October 2026 is the same unlicensed-production finding as a JDK 21 install on an application server, and Oracle's GLAS team will score it that way.

This is not a forecast.

Oracle already ran this exact mechanic on Java 17, and the record is on Oracle's own support roadmap: Java SE 17 public updates through September 2024 were available under the permissive license, and further Oracle JDK 17 updates released as of October 15.

2024 are available under the Java SE OTN license.

Same trailing one-year overlap after the next LTS shipped. Same September-to-October boundary. Same destination license, the one already governing Java 8 and 11.

Two cycles in, Certero's assessment is the right one: the pattern is confirmed, not predicted, and Java upgrades should be treated as a recurring licensing obligation with a date on it, owned by someone and funded like any other compliance activity.

What matters more is what Oracle did and did not do in the weeks after October 15, 2024. It did not issue a global notice to JDK 17 downloaders. It did not disable download endpoints, break builds, or make the license change visible to an operations team that was not reading release notes.

The binaries kept flowing; the terms under them changed.

OTN permits free use for development, testing and demonstration, but not production workloads, so the effect was a silent conversion: hosts that were compliant on October 14 were unlicensed on October 15 without a single configuration change, log entry, or alert.

What Oracle did do, on the timeline we saw across engagements, is start using download telemetry as the basis for outreach.

The auto-update and download records tied to a corporate IP range or an oracle.com account become the evidence set, and the conversation opens six to eighteen months later as a soft compliance inquiry rather than a formal audit letter.

Buyers caught in that window did not pay a technical remediation cost. They paid the Employee-metric subscription, backdated where Oracle could argue continuous use, priced off total headcount rather than the handful of JDK 17 servers actually in scope.

In our negotiation experience across those 2024 and 2025 files, the sticker shock came from the metric, not the version: a five-thousand-employee organization running Oracle Java on forty servers faces roughly $630,000 per year at list, about $15,750 per server.

That is the shape of the October 2026 event for JDK 21, 22, 23 and 24. If contact has already been made, the response discipline in the Oracle GLAS Java notice and what to send back applies before you concede a single install count.

If you run Oracle JDK 8, 11 or 17 binaries in production without a subscription, you are not waiting for a cliff. You went over one already.

Oracle's own support roadmap states that Oracle JDK releases for Java 8, 11 and 17 are available under the OTN License Agreement for Java SE, which is free for personal, development and other users only.

Read the grant literally: OTN permits development, testing and demonstration, and it does not permit production. There is no throttle, no nag screen, no license key that stops you.

The binary installs and runs exactly the same way it did in 2018, which is precisely why so many estates drifted into non-compliance without a single ticket being raised.

Oracle's position, consistently applied since the April 2019 licensing change and hardened after the January 2023 move to the Employee metric, is that commercial use after January 2023 without a subscription, including legacy Java SE 8 running in production, is unlicensed and audit-exposed.

In our experience across audit-defense engagements, the download telemetry Oracle holds against your corporate domains is the opening exhibit, and it usually predates anything your CMDB knows about.

Two beliefs cost buyers real money here. The first is grandfathering. There is none.

A JDK 8u202 binary you downloaded in 2018 does not carry forward a perpetual right into 2026 production; the license that applies is the one in effect for the release you are running, and for anything past the free-update boundary that is OTN.

The second is that legacy perpetual entitlements offset the new bill. Perpetual Java SE Advanced or Java SE Suite holdings do useful work as historical audit cover for the period they covered, and you should keep the ordering documents, but they earn no credit against a Universal Subscription price.

The Employee metric is calculated from headcount, not from what you already own.

Practical test: pull every java -version string and note the vendor field. Anything reporting Oracle Corporation on 8, 11 or 17, in a production or production-supporting tier, belongs on a remediation list with a named owner and a date this quarter, not next year.

Buyers keep sending us a circulating mid-2026 claim that Java 11 Extended Support expires in September 2026, framed as the leading edge of a 2029 to 2032 wave taking out 17, 8, 21 and 11.

That claim sits badly against Oracle's own published roadmap, which waives the Java SE 11 Extended Support uplift fee for October 2023 through January 2032. Both statements can circulate because they describe different things, and the conflation is where negotiation leverage gets given away.

Three separate dates are being merged into one: the end of free public updates, the availability window for Extended Support, and the period during which the uplift fee on Extended Support is waived.

The last of these is a pricing concession, not a support boundary, and a waiver running to January 2032 tells you Oracle intends to keep patching Java 11 for subscribers well past 2026.

Plan against January 2032 for the uplift waiver and treat Java 11 patch availability as a subscriber benefit that outlives your 2026 planning horizon. What you should not do is let an unverified 2026 date be used as urgency in a renewal conversation.

Ask your Oracle rep, in writing and citing the roadmap, to confirm three things: the current Extended Support end date for Java SE 11, that no uplift fee applies through January 2032, and that both are reflected in the ordering document rather than a support policy Oracle can revise unilaterally.

Get it in the contract or an amendment. A roadmap page is not a contractual commitment, and the same team that sends compliance notices is not obliged to honour a webpage. That written confirmation is cheap to obtain now and expensive to reconstruct during an audit.

Read the JDK 21 timeline as an engineering problem and you will lose money. Oracle has tuned the LTS cadence so that the technical decision (move the runtime off Oracle JDK 21) and the commercial decision (sign a Java SE Universal Subscription) land on the same date, October 2026.

That coincidence is not accidental, and it is not neutral. Engineering owns the calendar, procurement owns the money, and the two rarely sit in the same meeting until the deadline has already collapsed the option space.

By the time a CIO learns that 40 production hosts are still on Oracle binaries, the only lever left is the one Oracle sells.

The pricing mechanics reward that collapse precisely because the meter is decoupled from consumption. A 5,000-employee organization that needs Oracle Java on 40 servers pays $630,000 per year at list under the Employee metric, which works out to $15,750 per server.

Nothing in that number reflects cores, sockets, JVM count, or how many of those 5,000 people have ever opened a Java application. The metric counts payroll, including agents, contractors, outsourcers and consultants supporting internal operations.

So the cost of a technical decision made in a change advisory board is set by the HR headcount report, which is the one variable the engineers who created the exposure cannot influence at all.

That decoupling is the whole design.

In our engagements, organizations moving from pre-2023 processor-based Java SE licensing to the Employee metric have seen average increases in the region of 340 percent, and the increase is largest exactly where consumption is smallest: a large workforce running Java on a handful of servers.

The pre-2023 metric priced what you deployed, so shrinking your Java footprint shrank your bill. The Employee metric does not respond to footprint at all until the footprint reaches zero. There is no partial credit for migrating 90 percent of hosts.

You either need the license or you do not, and that binary is what makes the October date a pricing event rather than a technical milestone.

The band structure removes the last illusion that the price tracks anything rational. At 9,999 employees, annual list runs $1,259,874. At 10,000, it runs $990,000. One additional employee removes $269,874 of cost.

A price curve that inverts at a boundary is not a measure of value delivered; it is a bracket schedule, and brackets are negotiated, not computed.

Buyers who understand that stop arguing about how many JVMs they run and start arguing about band placement, employee definition scope, and term length, which is where the actual money sits.

None of that argument works from a weak position, and October 2026 is a weak position by construction.

A buyer sitting down with Oracle in Q4 2026 with production still on Oracle JDK 21 is negotiating with a live compliance clock, an unpatched-security narrative building behind it, and no credible alternative inside the quarter. Oracle knows the migration cannot be completed in eight weeks.

Every concession request in that meeting is answered by the calendar.

Compare that to a buyer who walks in having already cut over to an OpenJDK distribution and is discussing only residual desktop or legacy exposure: the conversation moves from "what discount" to "whether we buy at all," and the answer to the second question sets the price of the first.

The durable counter is therefore structural, not tactical. Separate the two decisions in time. Finish the runtime move before the license question is live, ideally by the July 2026 binary, so the commercial discussion happens on a footprint you chose rather than one you inherited.

That means diarizing the migration as a funded compliance activity with an owner, not a backlog item, and it means treating the rollback plan as OpenJDK rather than Oracle, because a fallback that reinstalls an Oracle binary reintroduces the exposure you spent the year removing.

Buy time first, then decide whether to buy anything else.

If the answer to October 2026 is "upgrade to JDK 25," price what that actually buys. Oracle plans JDK 25 updates to remain under the NFTC until October 2028, one year after the next LTS, Java 29, which is currently planned for September 2027.

Apply the same trailing-clock logic the 21 cliff just demonstrated and the practical last free binary lands mid-2028, not October. So a 25 upgrade purchases roughly 24 months of runway and resets an identical clock, with an identical two-month operational gap at the end of it.

That is a legitimate and often correct move, but it is a deferral, not a resolution.

The right way to frame the 2026 decision is therefore as a capacity question, not a version question: can this organization complete a full OpenJDK migration inside 24 months, on the estate as it exists, with the staffing it actually has? If yes, JDK 25 is a clean bridge and you should take it.

If the honest answer is that the last migration took three years and stalled on two vendor-packaged applications, then JDK 25 just moves the same conversation to 2028 at whatever the Employee rate is by then, with two more years of headcount growth priced in.

Organizations that cannot commit to a firm exit date should assume they are buying a subscription eventually and should negotiate it now, from a position of choice, rather than in 2028 under the same duress.

Write the dates into the change calendar this quarter, not next year. Book the JDK 25 cutover for H2 2027 at the latest, book a mid-2028 checkpoint against the last free 25 binary, and note Java 29's September 2027 planned release as the event that starts the next transition period.

Also record which applications carry third-party vendor certification constraints, because those, not the JVM, are what will decide whether the 2028 window is real.

Our view, tested across several dozen estates, is straightforward: treat every LTS jump as a recurring licensing obligation with a funded owner, or you will meet this cliff a third time.

If you miss July 2026 and keep patching, the price is not per server, per JVM, or per developer. It is per employee, and the definition is deliberately broad.

Oracle's Java SE Universal Subscription counts all full-time, part-time and temporary employees, plus the employees of your agents, contractors, outsourcers and consultants who support your internal business operations.

The licensed quantity is determined by headcount, not by who actually touches a JVM. That is why a 5,000-employee firm running Oracle Java on 40 servers pays $630,000 per year at list, roughly $15,750 per server, which is the arithmetic that makes migration budgets look cheap by comparison.

Note two structural details buyers routinely miss: there is no separate 22 percent support line, so the per-employee rate is all-in and any budget adding a support uplift is double counting.

And legacy perpetual Java SE Advanced holdings earn no credit against the subscription price (they survive only as audit cover for historical use).

One further constraint almost nobody reads: the Employee metric carries an installation ceiling of 50,000 Processors, exclusive of desktops and laptops. Cross it and Oracle requires an additional license.

For most estates this is academic, but for hyperscale container fleets and heavily virtualized VMware or Kubernetes environments it is a live exposure that surfaces during an audit rather than at signature.

Count your processors before you sign, and get the ceiling language reviewed against your actual and projected deployment. Our note on which Java versions are free and which trigger a bill covers the version boundary; this is the volume boundary sitting alongside it.

Two published waivers change the arithmetic of staying put, and almost no buyer prices them.

Oracle's Java SE Support Roadmap waives the Extended Support fee for Java SE 17 from October 2026 through September 2029, and waives the Extended Support uplift fee for Java SE 11 from October 2023 through January 2032.

Read that carefully: the waiver removes the uplift, not the underlying subscription. You still need the Universal Subscription to be licensed for production use of Oracle's binaries.

What the waiver does is remove the penalty for being on an older LTS, which means the case for a panicked jump from 17 to 21 to 25 purely to chase free updates is weaker than Oracle's messaging implies.

If you are already paying for the subscription, sitting on 17 through 2029 costs the same as sitting on 25, and the migration risk is lower. If you are not paying, neither version is free in production and the waiver is irrelevant to you.

The lever that actually moves price is not an argument about price.

In our experience across 2026 renewals, discounts in the 28 to 44 percent range land when the buyer can demonstrate a credible, costed, partially executed alternative: Eclipse Temurin, Amazon Corretto.

Azul or Red Hat builds already running in a defined slice of the estate, with a named owner and a date.

Oracle's rep prices the probability that you walk, not the elegance of your reasoning. A migration plan on a slide moves nothing. Two hundred hosts already cut over, with rollback tested, moves everything.

Our field note on why the JVM is almost never what breaks and your fallback must be OpenJDK not Oracle covers the technical side of building that proof.

Third-party support is the third option, and it is the one that reframes the negotiation entirely. Independent providers will patch older Java lines at a fraction of Oracle's employee-metric cost, which converts a headcount-driven bill into a deployment-driven one. That conversion is the whole game.

Price all three routes (subscribe, migrate to OpenJDK, buy third-party support) as line items with dates before you open the conversation, not after Oracle sends a quote.

Those two figures are the whole negotiation in miniature: fix the quantity first, then the rate, because a 25 percent overcount at a good rate still costs more than list at a correct one. The other patterns recur with enough consistency to plan around.

First, pre-2023 Java agreements: where an organization still holds a Java SE Subscription or Java SE Advanced paper on the old processor or named-user metrics, that paper often survives on renewal, and Oracle's sales motion does not volunteer it.

We see quotes built entirely on the Employee metric issued to customers whose existing contract would price the same estate on 40 servers rather than 5,000 employees, the difference between roughly $630,000 per year at list and a fraction of it. Retrieve the paper before you take the call.

Second, GraalVM for JDK 21 moves to its own GraalVM OTN variant at the same October 2026 CPU, and GraalVM almost never appears in the CMDB as "Java," so it surfaces late, usually inside a container image someone else built.

Third, timing: settlements cluster in March through May, ahead of Oracle's 31 May fiscal year end, which is where the $9.50 to $12.80 outcomes concentrate. A Q4 2026 negotiation, after the October CPU has already landed and you are demonstrably running unpatched, is the weakest seat at the table.

Fourth, and this is market experience rather than published data, the estates that end up buying are rarely the ones that could not migrate; they are the ones that could not find the JDKs, which is why discovery precedes every other decision.

Where an audit letter has already arrived, treat the commercial track and the response track separately and read the Oracle GLAS Java notice and what to send back before answering anything.

The corollary is that a discount percentage is a bad success metric. We have seen 30 percent off list on an inflated count produce a higher annual spend than list on a defended one, and the customer celebrated the discount.

Score the deal on total annual dollars and on the ceiling you are agreeing to (the Employee metric caps installation at 50,000 processors excluding desktops and laptops), not on the concession Oracle chooses to advertise.

Related reading: When Do Free Java 21 Updates End and What Then?, Is Java 25 Really Free, and For How Long?, and Java 17 Already Fell Off the Free Cliff: Your Options Now.

When exactly do free Java 21 updates end?

Oracle has said all Oracle JDK 21 updates through and including September 2026 remain available under the No Fee Terms and Conditions, and that beginning with the October 2026 CPU, JDK 21 updates move to the Java SE OTN license already used for Java 8, 11 and 17.

Operationally the last free binary ships with the July 2026 CPU, and Java 21 builds from Java.com remain free for use until September 16, 2026. Plan against July 2026, not September.

Does the cliff apply to Java 22, 23 and 24 as well?

Yes. JDK 22, 23 and 24 remain free under the NFTC until September 2026 on the same terms as 21, so any host still running those versions after that date falls outside the no-fee grant.

This is widely missed because non-LTS releases are otherwise free under the NFTC for their whole six-month support life. Include version strings 22 through 24 in your discovery scope.

What does the Oracle Java subscription cost after the cliff?

The Java SE Universal Subscription is priced per employee per month, starting at $15.00 for 1 to 999 employees and stepping down through seven published bands to $5.25 at 40,000 to 49,999, with no published rate above 50,000.

The metric counts all full-time, part-time and temporary employees plus those of agents, contractors, outsourcers and consultants supporting internal operations, not the people who use Java. Oracle's own example puts a 28,000-employee company at $2,268,000 per year.

Is there a support percentage added on top of the per-employee rate?

No. The per-employee rate is all-in and there is no separate 22 percent support line, so any budget that adds a support percentage on top is double counting.

Legacy perpetual Java SE Advanced holdings still matter as audit cover for the historical period, but they earn no credit against the subscription price.

Does Java 11 Extended Support really end in September 2026?

That claim circulates widely but sits awkwardly against Oracle's own support roadmap, which waives the Java SE 11 Extended Support uplift fee through January 2032 and waives the Java SE 17 Extended Support fee for October 2026 to September 2029.

End of free updates, availability of Extended Support, and waiver of the uplift fee are three different things. Get the specific date and program confirmed in writing by your Oracle rep before you plan a migration around it.

How long does upgrading to Java 25 buy me?

Oracle plans JDK 25 updates to remain under the NFTC until October 2028, which is one year after the next planned LTS, Java 29, currently scheduled for September 2027. That is roughly two years from the October 2026 cliff.

Treat it as a funded window to complete an OpenJDK migration rather than as a permanent resolution, because the same one-year overlap mechanic will apply again.

What actually moves Oracle's price on a Java subscription?

Two things: a defensible employee count and a credible alternative.

Benchmark data across 80-plus contracts shows negotiated rates of $9.50 to $12.80 per employee per month for 1,000 to 10,000-employee organizations against $15.00 list, and 28 to 44 percent reductions specifically where a documented OpenJDK migration plan exists.

Strip temporary staff and non-supporting contractors from the count first, since initial Oracle quantities typically overcount by 18 to 28 percent, and time the close against Oracle's 31 May fiscal year end.