Java 27 Turns On Hybrid Post-Quantum TLS by Default Through JEP 527, and Oracle Expects JDK 8 and JDK 11 to Receive It Only in the Second Half of 2027
Java 8 reached general availability in March 2014. Oracle's support roadmap still lists it under extended support until December 2030 and JDK 11 until January 2032, which makes them the two oldest runtimes it still supports, sixteen and thirteen years after their release. Payment switches, hospital integration engines, insurance back-ends and government portals built in that period often still run on one of the two. On 15 September 2026 Oracle released Java 27 with a hybrid post-quantum key exchange switched on by default, and the question that matters for those estates is answered in a separate roadmap post from 6 August 2026: Oracle expects them to receive the same capability in the second half of 2027.
This post reads the chronology as Oracle and OpenJDK wrote it, from the first building block in 2023 to the last backport date, and then asks what a runtime default does that a regulatory deadline does not.
Practical takeaway. If your applications use the JDK's own SunJSSE TLS stack over TLS 1.3 with the default named-group list, upgrading the runtime is the key-exchange migration step: Java 27 now, and on Oracle's expected dates for Oracle JDK, JDK 25 from the October 2026 Critical Patch Update, JDK 17 and 21 in the first half of 2027, JDK 8 and 11 in the second half of 2027; other distributions set their own schedules. Oracle says the platform enables the hybrid exchange and does not force it, so the second step is confirming, per connection class, that the server selected X25519MLKEM768. Authentication is separate: certificates and signatures stay classical until keys, certificates, issuance and validation all support ML-DSA.
September 2023 to March 2025: the building blocks arrive before the standard
JEP 452 brought a Key Encapsulation Mechanism API into JDK 21 in September 2023, eleven months before NIST published FIPS 203 and FIPS 204 in August 2024. Oracle's roadmap post describes the sequencing as deliberate: the API committed the platform to modern key establishment without committing it to any particular post-quantum design. Once the standards were final, JDK 24 added ML-KEM through JEP 496 and ML-DSA through JEP 497 in March 2025. From that point a Java developer could build a post-quantum application by hand. Oracle's roadmap post observes that, in practice, many applications instead rely on the JDK's TLS implementation to negotiate their algorithms, and until this week the JDK's default negotiation was classical.
June 2025 to 15 September 2026: JEP 527 and what it leaves out
JEP 527, owned by Jamil Nimeh and created on 3 June
2025, was delivered in JDK 27 on 15 September 2026. It implements three hybrid named groups from the IETF TLS
working group's hybrid design: X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024. Only the first is
enabled by default, and it is placed at the front of the JDK's preference list, ahead of x25519, secp256r1,
secp384r1, secp521r1, x448 and the three finite-field groups. The JEP's own reasoning is that X25519MLKEM768 is
the fastest hybrid and is what most TLS clients now enable, so a Java client offers X25519MLKEM768 and x25519 key
shares and lets the server choose; the hybrid is used only when the server selects it. All of this applies to
the JDK's own SunJSSE provider; an application that bundles another TLS library is outside the JEP. An
application that has already called SSLParameters::setNamedGroups or set
jdk.tls.namedGroups keeps its own list, and is protected only if that list includes a hybrid group.
The non-goals are as informative as the goals. JEP 527 covers TLS 1.3 only, through javax.net.ssl only, and implements no pure ML-KEM group; the authors say hybrids are in higher demand and give a minimum guarantee against both quantum and classical attack that neither algorithm gives alone. Nothing in the JEP touches authentication. A Java 27 client that negotiates X25519MLKEM768 still verifies the server's certificate with RSA or ECDSA, so the connection is protected against harvest-now-decrypt-later collection and remains forgeable, in principle, by a future quantum adversary who can sign as the server at the time of the connection. That is the same split the DNS world is working through, where Cloudflare's resolver began validating ML-DSA-44 signatures on 10 September while the chain above it stays classical.
6 August 2026: the calendar Oracle wrote for the runtimes people actually run
The press release of 15 September, issued from Austin, quotes Georges Saab, Oracle's senior vice president for the Java platform and chair of the OpenJDK governing board, on "a roadmap to bring comparable capabilities to JDK releases with long-term support offered by Oracle." The roadmap itself was published five weeks earlier, on 6 August 2026, by Aurelio Garcia-Ribeyro, and its table is the most consequential document of the week for anyone who runs Java in production. JDK 25, the current LTS, is expected to reach functional parity with JDK 27's post-quantum capability with the October 2026 Critical Patch Update. JDK 21 and JDK 17 are expected to reach comparable functionality in the first half of 2027. JDK 11 and JDK 8 are expected to follow in the second half of 2027. These are Oracle's stated expectations for Oracle JDK; other Java distributions publish their own schedules. The table has two rows: the ML-KEM and ML-DSA algorithms of JEP 496 and 497 reach JDK 17 and 21 with the October 2026 update and JDK 8 and 11 in the second half of 2027; the hybrid TLS exchange of JEP 527 follows in H1 2027 for the former pair and lands together with the algorithms for the latter.
Two features of that table deserve attention. The first is that Java 27, the release that ships the default, is a non-LTS release whose premier support ends in March 2027; the feature was born in a six-month runtime and will spend most of its useful life in the backports. The second is the ordering. Oracle's support roadmap runs JDK 17 to September 2029, JDK 21 to September 2031, JDK 25 to September 2033, JDK 8 to December 2030 and JDK 11 to January 2032. The two oldest lines are scheduled for the hybrid exchange in H2 2027, after every newer line, which produces an exposure inversion for the data that travels through them: where an estate on JDK 8 or 11 carries sensitive, long-lived data and stays on that line, the harvest-now-decrypt-later risk to that data runs to Oracle's latest scheduled backport, unless the operator upgrades the runtime or changes the TLS stack sooner. The post also states plainly that "the platform can enable post-quantum cryptography, but it does not force its use," and that being PQC-ready "is not achieved just by delivering a particular feature." Both caveats are Oracle's own, and both are correct.
How the backport dates sit against the regulators' dates
Three public milestones sit near these dates, and they are different kinds of instrument. NIST's draft IR 8547 of November 2024 proposed deprecating quantum-vulnerable public-key algorithms after 2030 and disallowing them after 2035, a proposed algorithm-transition timetable. FINMA's Guidance 05/2026 of 9 July 2026 recommends that Swiss institutions have a post-quantum roadmap by mid-2027, a planning recommendation. National Security Memorandum 10 of May 2022 sets the United States the goal of mitigating as much of the quantum risk to federal systems as feasible by 2035, a national objective. An Oracle JDK LTS line that negotiates X25519MLKEM768 by default from the first half of 2027 sits inside all three windows, and for a regulated firm the more useful reading is the reverse one: a supervisor who asks in mid-2027 what share of an institution's TLS connections use a hybrid exchange will get an answer that depends heavily on which JDK line the institution's Java estate runs and whether the October 2026 and H1 2027 updates were installed and verified. Korea's difficulty, as Quentir described in its finance-sector rehearsal, was that certification throughput, not algorithm availability, set the pace. For Java the constraint moves one layer down, to patch throughput across an installed base that is measured in the millions of JVMs and is, by design, slow to change.
The FIPS side is separate and also moving. The Cryptographic Module Validation Program accepts FIPS 140-2 validated modules for new systems through 21 September 2026, six days after the Java release; after that date their certificates move to the historical list, which still permits use in existing systems and stops their use for new ones. Oracle's press release positions Jipher 20, now part of its Java Verified Portfolio, as the provider for deployments in FIPS 140-regulated environments. A hybrid exchange in the open-source JDK and a validated module for a regulated customer are two different deliverables, and an institution that needs the second cannot assume it from the first.
How Quentir Reads It
The first implication is about where the migration schedule is being written. No regulator moved a date this week; the 15 September release made the calendar Oracle published on 6 August operationally relevant, and the dates it expects (October 2026, H1 2027, H2 2027) reach the installed base through the ordinary patch cycle, a channel no supervisory guidance of 2026 has. How much of the quantum-resistant share of enterprise TLS that produces is an empirical question for 2027. The JEP notes that most TLS clients already enable X25519MLKEM768 by default; the browsers and the large CDNs moved first. JEP 527 and its backports bring the same default to a language widely used for regulated back-office traffic, where the client is a batch job or a service mesh and nobody updates it by accident.
The second is about inventory. Oracle's table is only useful to an operator who knows which JDK line each application runs, whether its TLS stack is the JDK's or a bundled library, and whether anyone pinned a named-group list years ago for an interoperability reason nobody remembers. That is the same question the cryptographic bill of materials answers, which Quentir's Defense Monitor treated as the map of a migration, and the Java calendar gives that map Oracle-specific dates. Quentir's Signature Report, the PQC Migration Roadmap, adds what this post does not: a fixed-scope sequence for locating those runtimes and libraries, an executive summary, refresh triggers as each backport lands, and an internal-use license, where a public post can only point at the table.
The third is about the half that did not ship. JEP 527 protects confidentiality and leaves authentication classical, by design. TLS 1.3 does negotiate signature schemes, through the signature_algorithms and signature_algorithms_cert extensions of RFC 8446, but a signature migration needs more than a preference list: the server needs an ML-DSA key and a certificate for it, a certification authority willing to issue one, and every client and intermediary on the path able to validate it. Oracle's table does carry the ML-DSA algorithm of JEP 497, and earlier than the hybrid exchange: JDK 25 has it already, JDK 17 and 21 are expected to receive it in October 2026, and only JDK 8 and 11 get algorithm and hybrid exchange together in H2 2027. What none of these documents schedules is the end-to-end chain. The question a Java estate owner should ask next is when a certificate authority, the JDK's trust store and the estate's own clients can all handle an ML-DSA chain, and that is a date these Oracle documents do not provide.
Sources: Oracle, "Oracle Releases Java 27 and Strengthens Post-Quantum Cryptography Support", press release, Austin, 15 September 2026 (JEP list, Georges Saab quotation, Jipher 20 and Java Verified Portfolio). Jamil Nimeh, JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3, OpenJDK, created 3 June 2025, updated 17 August 2026, status Closed/Delivered, release 27 (named groups, default order, non-goals, configuration). Aurelio Garcia-Ribeyro, "Post-Quantum Cryptography in Long-Term Support JDK Releases", Oracle Java blog, 6 August 2026 (backport table: JDK 25 October 2026 CPU, JDK 17 and 21 H1 2027, JDK 8 and 11 H2 2027; quotations on enabling versus forcing use). OpenJDK, JEP 452 (JDK 21, September 2023), JEP 496 and JEP 497 (JDK 24, March 2025). Oracle, Oracle Java SE Support Roadmap, consulted 16 September 2026 (GA and support dates for JDK 8, 11, 17, 21, 25 and 27). NIST, IR 8547 (initial public draft), Transition to Post-Quantum Cryptography Standards, November 2024. FINMA, Guidance 05/2026, 9 July 2026. The White House, National Security Memorandum 10, 4 May 2022 (2035 objective). IETF, RFC 8446 section 4.2.3, August 2018 (signature_algorithms extensions). NIST CMVP, Cryptographic Module Validation Program (FIPS 140-2 modules accepted for new systems through 21 September 2026, historical list thereafter). InfoQ, "Java 27 Delivers Post-Quantum Cryptography, Future Language Innovation, Helidon 27, JavaFX 27", 16 September 2026. Earlier Quentir coverage is linked inline.
Published intelligence, built to inform your own decisions. Published: September 16, 2026.