Post-Quantum Cryptography in Long-Term Support JDK Releases

Executive Summary
Oracle is executing on a strategy to make post-quantum cryptography (PQC) broadly available across the Java ecosystem with a roadmap that brings standardized PQC algorithms and PQC-enabled TLS to current Long-Term Support (LTS) releases, helping reduce adoption friction for developers and enterprises.

• Oracle is bringing PQC readiness not only to new JDKs, but across supported Oracle JDK LTS releases, including JDK 25, 21, 17, 11 and 8.
• The objective is to minimize application disruption. Applications that simply rely on Java’s TLS stack can take advantage of PQC-enabled benefits simply through updating and configuration changes.
• Other cryptographic changes, beyond PQC-enabled TLS support, are also part of the roadmap update.
• Security readiness requires a continuous process; it is not a one-time goal. If you are not already following Java Crypto Roadmap updates, now would be the best time to start.

Details
The history of cryptography is largely a story of gradual evolution punctuated by occasional disruption. For long periods, cryptographic systems improve incrementally. Occasionally a technological breakthrough changes the rules entirely. Mechanized encryption transformed a world of hand ciphers. Electronic computers transformed a world of electromechanical cryptography. Today, quantum computing is poised to transform the cryptographic landscape once again.

The transition to post-quantum cryptography is unusual: the industry is preparing for a threat before it becomes practical. Large-scale quantum computers capable of breaking today’s widely deployed public-key cryptography are not believed to exist yet. However, the cryptographic community has sufficient confidence in the underlying mathematics to begin standardizing and deploying quantum-resistant alternatives.

For a platform such as Java, the challenge is not only deciding when to adopt new cryptographic technologies but making them broadly available once standardized. Many organizations run business-critical applications on long-term support (LTS) releases for years, long after newer JDK releases become available. The Java team’s objective is therefore not only to deliver stronger cryptography in the newest JDK releases, but also to allow existing applications running on earlier but still supported releases to transition to post-quantum cryptography with as little disruption and effort as possible.

Some building blocks had to be introduced before the standards themselves were finalized. The first step was the introduction of the Key Encapsulation Mechanism (KEM) API through JEP 452 in JDK 21, which was released in September 2023. This provided a foundation for modern key establishment algorithms without committing to a specific post-quantum design.

The next step was to choose the right algorithms. Cryptography is used for two distinct but related purposes: encrypting information and establishing trust. Encryption prevents unauthorized parties from reading protected information. Digital signatures allow systems to verify who created or sent information and to detect whether it has been modified.

In August 2024, NIST published FIPS 203, standardizing ML-KEM, and FIPS 204, standardizing ML-DSA. ML-KEM is a quantum-resistant key establishment mechanism used to protect information. ML-DSA is a quantum-resistant digital signature algorithm used to establish trust. Together, they address the two primary roles that public-key cryptography plays in modern systems.

Soon after, in March 2025, JDK 24 introduced support for both algorithms through JEP 496 and JEP 497.

JDK 24 provides the algorithms required to build post-quantum secure applications. In practice, however, many applications rely on the JDK’s TLS implementation to establish secure network connections and negotiate cryptographic algorithms automatically. To enable post-quantum cryptography with minimal application changes, JDK 27 introduces JEP 527, adding hybrid post-quantum key exchange for TLS 1.3.

With these additions, JDK 27 delivers all the core capabilities needed for the initial transition to post-quantum cryptography, with its GA in September 2026. For many organizations, however, the more important question is how to adopt PQC on applications running on earlier long-term support (LTS) releases.

Delivering PQC on earlier JDK releases requires backporting algorithms, which in many cases also require updating earlier Java SE specifications. The work has already started. The KEM API introduced in JDK 21 was later incorporated into Java SE 17 through Maintenance Release 1.

As described in the July 2026 update of Oracle’s JDK Cryptographic Roadmap, the process of bringing these capabilities to earlier releases is underway. JDK 25 is expected to reach functional parity with JDK 27’s post-quantum cryptography capabilities with the October 2026 Critical Patch Update (CPU). JDK 21 and JDK 17 are expected to reach comparable functionality by the first half of 2027, followed by JDK 11 and JDK 8 during the second half of 2027.

This progression must be deliberate to promote correctness, standardization, and interoperability. The addition of PQC to the JDK follows a familiar pattern in the evolution of Java security. New cryptographic capabilities are introduced in new platform releases first. As capabilities are validated and integrated into the platform, they are then propagated across supported long-term support releases.

“PQC-ready” is not achieved just by delivering a particular feature. Readiness depends on the platform, protocols, certificates, infrastructure, and operational practices evolving together.

These capabilities establish a foundation for adopting post-quantum cryptography, primarily for the protection of data in transit. Most applications should not require major code changes to use the new capabilities, but adoption still requires appropriate configuration and operational planning. The platform can enable post-quantum cryptography, but it does not force its use. Consult the documentation to configure, validate, and test that PQC is negotiated and used.

The value of the Java platform lies in its ability to evolve carefully as new security challenges appear. Post-quantum cryptography should not be viewed simply as a finish line, where adding a set of new features makes the platform “PQC-ready” and the work is complete. Platform security is a continuous process. New threats emerge, new technologies appear, and new cryptographic techniques are developed in response. Post-quantum cryptography is the latest example of this recurring pattern in computing history. Java’s goal is to provide a sustainable path for adopting this generation of security technologies—and the next ones as they emerge.