The term on this page
- TLSTransport Layer Security
- the protocol behind the padlock in your browser
Also mentioned
ML-KEMML-KEMModule-Lattice-based Key Encapsulation MechanismModule-Lattice-Based Key-Encapsulation Mechanism, the NIST-standardized post-quantum KEM derived from CRYSTALS-Kyber and specified in FIPS 203.Read the full entry (new tab), ML-DSAML-DSAModule-Lattice-based Digital Signature AlgorithmModule-Lattice-Based Digital Signature Algorithm, the NIST-standardized post-quantum signature scheme derived from CRYSTALS-Dilithium and specified in FIPS 204.Read the full entry (new tab), PQCPQCpost-quantum cryptographyCryptographic algorithms designed to run on today's classical computers while remaining secure against attacks by both classical and future quantum computers.Read the full entry (new tab) are defined in the glossary.
Read this first
Java 27, released on 15 September 2026, adds hybrid post-quantum key exchange to the standard TLS 1.3 implementation. X25519MLKEM768 is first in the default named-group preference, so applications using the normal javax.net.ssl APIs can negotiate it without application code changes when the peer supports it. The release also changes how new ML-KEM and ML-DSA private keys are encoded, which creates a compatibility check for mixed-version Java fleets.
The important change is not that Java can perform ML-KEM. That arrived earlier. Java 27 moves hybrid post-quantum key exchange into the ordinary TLS path. Oracle's Java 27 announcement and release notes describe three hybrid TLS 1.3 groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. X25519MLKEM768 sits at the front of the default named-group list. For teams already using JSSE, the migration can therefore begin as a runtime upgrade rather than an application rewrite.
The default changed, but the peer still decides what happens
A preferred group is not a guarantee that every connection becomes post-quantum protected. TLS negotiates what both endpoints support. A Java 27 client can offer X25519MLKEM768, but an older server, load balancer, inspection device, or manually restricted named-group configuration may still lead to a classical exchange. The right question is not whether the JDK contains ML-KEM. It is whether the actual connection negotiated the hybrid group across the full production path.
| Change | Java 27 behavior | Operational consequence |
|---|---|---|
| Preferred TLS hybrid group | X25519MLKEM768 is first in the default named-group list | Compatible JSSE connections can select hybrid PQC without application code changes |
| Additional hybrid groups | SecP256r1MLKEM768 and SecP384r1MLKEM1024 are supported | Deployments have alternatives when policy or interoperability requires a different classical component |
| Private-key encoding | New ML-KEM and ML-DSA keys default to seed encoding | Older JDKs may reject newly generated keys unless they are translated to an older-compatible encoding |
This is exactly why a hybrid TLS migration needs connection-level evidence. Upgrade one endpoint, capture what group was negotiated, then test the same route through the real proxy, WAF, load balancer, service mesh, and egress controls. Our TLS hybrid key exchange reference now records Java 27 as a native deployment path, and the post-quantum TLS checker explains how to verify support rather than infer it from a version number.
The private-key encoding change can break mixed JDK fleets
Java 27 also changes the default PKCS #8 encoding for newly generated ML-KEM and ML-DSA private keys from the expanded-key form used when the algorithms first appeared in JDK 24 to a seed representation. The release notes are explicit about the consequence: older JDK releases do not accept Java 27's new default encoding, although Java 27 can still read keys produced by older releases.
Oracle exposes the choice through the jdk.mlkem.pkcs8.encoding and jdk.mldsa.pkcs8.encoding security properties. The allowed values are seed, expandedKey, and both. If a private key must move between Java 27 and an older runtime, the release notes recommend using expandedKey for that compatibility path and translating the key with KeyFactory.translateKey. This is not a cryptographic weakness. It is a serialization compatibility issue, and it is the kind that turns a technically correct migration into an outage when key material crosses runtime boundaries.
Inventory the key format, not just the algorithm
A service can be correctly using ML-KEM or ML-DSA and still fail after a runtime change if another component cannot decode the private-key representation. Record the JDK version that generates, stores, imports, exports, and consumes each key. Test rollback before changing the encoding default in production.
The performance argument got weaker too
Oracle reports substantial gains on x86_64 systems with AVX-512 after optimizing SHA-3 intrinsics. In its JDK 27 microbenchmarks, ML-KEM key generation improved 48%, decapsulation 47%, and encapsulation 46%. ML-DSA key generation improved 60%, signing 38%, and verification 74%. Those figures are implementation benchmarks on the stated hardware path, not a promise that an application's end-to-end TLS latency improves by the same percentage.
The distinction matters. Hybrid TLS adds bytes to the handshake, and network behavior can dominate cryptographic compute. The ML-KEM standard defines the algorithm, while the transport path decides whether a larger ClientHello crosses middleboxes cleanly. Java making the computation faster does not remove the need to measure packetization, retries, HelloRetryRequest behavior, CPU load, and connection latency on the systems that actually terminate TLS.
What Java teams should test now
- Confirm the negotiated TLS group on representative production paths. Do not treat JDK 27 installation as proof that X25519MLKEM768 was used.
- Search for explicit jdk.tls.namedGroups settings and framework or proxy configuration that can override the new default preference.
- Generate ML-KEM and ML-DSA test keys on Java 27 and verify every older runtime, HSM integration, keystore path, backup process, and rollback target that must read them.
- Benchmark handshake behavior with the actual load balancers and middleboxes in front of the service, including fragmented or multi-packet ClientHello traffic.
- Keep algorithm support and key-format compatibility as separate fields in the cryptographic inventory. One can be green while the other is broken.
The practical shift is that Java's mainstream TLS stack now gives many applications a direct path to hybrid PQC. That removes one engineering excuse, but it does not remove migration work. A safe rollout still requires knowing where TLS terminates, what each endpoint negotiates, and where keys cross version boundaries. The same discipline applies to signatures under ML-DSA: availability is useful, interoperability evidence is what makes it deployable.
References
- Oracle: The Arrival of Java 27, 15 September 2026. General availability announcement and summary of JEP 527.
- Oracle: JDK 27 Release Notes, 15 September 2026. TLS hybrid groups, private-key encoding compatibility, certificate compression, and PQC performance figures.
- OpenJDK JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3. Design and implementation scope for hybrid TLS key exchange in the JDK.
- Oracle: Post-Quantum Cryptography in Long-Term Support JDK Releases. Backport plan for supported LTS JDK releases and distinction between algorithm availability and deployment readiness.