Product1 publisher3 min readPublished
Oracle's post-quantum backport reaches JDK 8 and 11 last, in the second half of 2027
Java 27 shipped ML-KEM hybrid key exchange for TLS 1.3 on September 15. Oracle's published plan gives it to JDK 25 in October and to JDK 8 and 11 in the second half of 2027, and The Futurum Group's Mitch Ashley says that order inverts the risk.
The Product Desk · Product desk
What happened
- Java 27 shipped on September 15 with post-quantum hybrid key exchange for TLS 1.3 under JEP 527, and Oracle says standard Java TLS clients and servers need no code changes to use it.
- Oracle's published backport order runs newest first: JDK 25 in its October critical patch update, JDK 21 and 17 in the first half of 2027, and JDK 8 and 11 in the second half.
- Oracle is adding monthly critical security updates between its quarterly releases, limited to security and stability fixes with no new features, and says it will phase them in gradually.
- Oracle describes Java 27 as a drop-in replacement for existing applications unless those applications depend on preview features.
Compiled by The Product DeskSomething wrong?How this is made
Why it matters
- exposure Traffic a JDK 8 endpoint carries between now and the last backport window is captured before any platform fix exists for it, so the exposure sits in someone else's storage by the time the patch ships.
- decision Somebody has to name the TLS endpoints whose plaintext stays sensitive past 2027 and fund a non-JVM answer for them, and that naming happens in this budget cycle.
- cost The people who gate a JDK rollout absorb the extra review cycles, and the monthly drops ship no features they can point to when asked what the change window bought.
- precedent Staggering a cryptographic primitive across LTS lines sets the expectation that long-term support now means the fix eventually, in an order the vendor chooses by build difficulty.
The operator who has to do something about this is the one whose production JVM is JDK 8. Five JDK releases appear in Oracle's backport plan, and four of them wait until 2027 [19]. At least nine months sit between the first backport and the last [20].
Mitch Ashley, vice president and practice lead for CIO & Technology Buyers and Software Lifecycle Engineering at The Futurum Group, said the ordering is what teams should read. "The backport schedule matters more than the release," he said [9]. "Post-quantum protection arrives first on the version with the least production code behind it, and last on JDK 8 and 11, where a large share of enterprise Java still runs," he said [10]. Teams carrying the oldest estates, he said, "hold the traffic most exposed to harvest-now-decrypt-later capture, and they wait the longest for a platform fix" [11].
Oracle says the older long-term-support releases run on older hardware and predate virtual threads and the module system, and that both complicate a clean backport [5]. The reason is plausible on its face, and it does not change what an on-call team owns in the meantime.
Georges Saab, senior vice president of Oracle Java Platform and chair of the OpenJDK governing board, said Oracle "delivers a major post-quantum cryptography milestone and is executing on a roadmap to bring comparable capabilities to JDK releases with long-term support offered by Oracle" [13]. The roadmap he points to is the published table of backport dates [4].
Harvest now, decrypt later is a storage bet by the attacker: traffic captured today can be opened once quantum computing matures [15]. The useful question about each TLS endpoint is therefore how long the plaintext behind it stays worth reading.
Two things set the priority. One is the date your JDK gets hybrid key exchange, October for JDK 25 or a 2027 window for everything older [4]. The other is whether the confidentiality of what crosses that endpoint outlives the wait. Session tokens that expire in an hour are not worth two years of someone's disk; slowly rotated credentials and records with a legal retention period are. The endpoints that need work now are the ones where both answers go the wrong way. Ashley said those teams "should inventory which TLS endpoints they can protect another way before 2027" [12]. In practice that means terminating TLS somewhere that already does hybrid key exchange, or writing down that the capture window is open and who signed for it.
The patch cadence lands on different desks. Java went from roughly annual security updates a decade or so ago to quarterly, and Oracle is now moving toward monthly critical security updates between the quarterly releases [7][1]. Twelve patch events a year against four is three times the review traffic for whoever gates a JDK rollout, and twelve times what the same shop planned for a decade ago [18].
What to watch
- Whether Oracle puts a start date and scope on the monthly critical security updates it says it will phase in gradually.
- Whether the October critical patch update actually delivers ML-KEM to JDK 25, the first test of the published backport plan.
- Whether JDK 21 and 17 hold their first-half-2027 dates, since a slip pushes JDK 8 and 11 further out.