The Post-Quantum Security Timeline for Java: JEP 496, JEP 527, and What Teams Should Do Now
If you manage Java services that handle sensitive data, 2026 is a year that deserves your attention. Not because quantum computers are breaking encryption today, but because the tools to protect against them are already shipping — and the compliance clock is officially ticking.
In this article we’ll break down exactly what delivered in JDK 24, what is bringing to JDK 27, why the NIST deadlines make this urgent, and what your team should realistically be doing right now.
The chart below gives you a clean picture of where each piece lands across JDK releases. Now, let’s walk through the full story — because understanding the why behind these JEPs matters just as much as knowing the what.
1. Why Post-Quantum Cryptography Can’t Wait
Before diving into JEPs, it’s worth understanding the threat model. The concern isn’t that quantum computers are breaking RSA today — they’re not. The concern is a specific attack called “Harvest Now, Decrypt Later” (HNDL). An adversary could harvest encrypted data today, store it, and decrypt it once sufficiently powerful quantum computers become available. OpenJDK
That means traffic your APIs are exchanging right now could be sitting in an attacker’s archive, waiting. For financial records, healthcare data, or government communications — where data needs to stay confidential for a decade or more — this is a very real problem.
Furthermore, some analysts predict state actors may have quantum decryption capabilities as early as 2028. Keyfactor Whether or not that timeline proves accurate, NIST has already drawn a firm line: RSA, ECDSA, EdDSA, DH, and ECDH will be deprecated by 2030 and completely disallowed by 2035. AppViewX
Importantly, migration at enterprise scale takes far longer than most teams expect. If large enterprises require 12–15 years for complete PQC migration, and fault-tolerant quantum computers arrive in 2028–2030, enterprises beginning migration in 2025 face a 3–5-year window where significant portions of their infrastructure remain vulnerable. MDPI
That gap is exactly why Java has been moving quickly.
2. The Foundation: How We Got Here
Java’s PQC story didn’t begin with JEP 496. It started with JEP 452 in JDK 21 (September 2023), which introduced the KEM (Key Encapsulation Mechanism) API. Think of JEP 452 as laying the wiring for a new socket — before you could plug anything in, you needed the socket itself. That step is often overlooked, but it’s what made everything that followed possible.
From there, the JDK team had a stable, extensible foundation to build actual quantum-resistant algorithms on top of.
3. JEP 496: ML-KEM Arrives in JDK 24
JEP 496 enhances the security of Java applications by providing an implementation of the quantum-resistant Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), standardized by NIST in FIPS 203. OpenJDK
In plain terms: ML-KEM is the algorithm that replaces the way two parties agree on a shared secret over an untrusted connection. Today, that job is done by RSA or Diffie-Hellman key exchange. Tomorrow, it needs to be done by something a quantum computer can’t crack. ML-KEM is that something.
JEP 496 adds ML-KEM implementations of the KeyPairGenerator, KEM, and KeyFactory APIs, with support for parameter sets ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as standardized in FIPS 203. OpenJDK These three parameter sets offer increasing security strength at the cost of slightly lower performance — ML-KEM-768 is the current general-purpose recommendation for most enterprise workloads.
Alongside JEP 496, <a href=”https://openjdk.org/jeps/497″ target=”_blank”>JEP 497</a> added ML-DSA — the quantum-resistant digital signature algorithm. ML-DSA is a standard for verifying the authenticity and integrity of data. When code or documents are signed with ML-DSA, they remain trustworthy even against future quantum attackers. Baeldung
A Quick Note on What’s Not Yet In JDK 24
Here’s something important teams often miss: critically, TLS 1.3 integration is not yet complete in the standard JDK TLS provider (JSSE). The SunJSSE provider does not yet support ML-KEM as a named group for TLS key exchange by default. Java Code Geeks In other words, JDK 24 gives you the cryptographic primitives, but full TLS integration — the thing that protects your actual network traffic — is coming in JDK 27. That gap is precisely what JEP 527 fills.
4. The Algorithm Landscape at a Glance
The table below summarises the key post-quantum algorithms, their purpose, and their current status in the JDK:
| Algorithm | Standard | Purpose | JDK Status | Best For |
|---|---|---|---|---|
| ML-KEM-768 | FIPS 203 | Key encapsulation | JDK 24 (JEP 496) | TLS key exchange, API secrets |
| ML-KEM-1024 | FIPS 203 | Key encapsulation (high-security) | JDK 24 (JEP 496) | Long-lived sensitive data |
| ML-DSA-65 | FIPS 204 | Digital signatures | JDK 24 (JEP 497) | JWT signing, code signing |
| SLH-DSA | FIPS 205 | Hash-based signatures | BouncyCastle 1.80+ | Firmware, artifact signing |
| X25519MLKEM768 | IETF Draft | Hybrid TLS key exchange | JDK 27 (JEP 527) | TLS 1.3 connections |
JEP 527: Hybrid TLS 1.3 in JDK 27
This is the JEP that will matter most to the majority of Java enterprise teams. JEP 527 enhances the security of Java applications by implementing hybrid key exchange algorithms for TLS 1.3, combining a quantum-resistant algorithm with a traditional algorithm to defend against future quantum computing attacks. Inside.java
JEP 527 was formally targeted to JDK 27 in February 2026 Inside.java, and JDK 27 is scheduled for GA release in September 2026 Jvm-weekly — meaning production-ready hybrid TLS in Java is only months away.
What “Hybrid” Actually Means
The term “hybrid” is key here. Rather than switching from traditional algorithms to quantum-resistant ones all at once (which introduces compatibility risks), the hybrid approach combines both. A hybrid key exchange scheme combines a quantum-resistant algorithm with a traditional algorithm, and is secure as long as one of the algorithms remains unbroken. OpenJDK
This is a very deliberate design decision: if ML-KEM turns out to have an undiscovered weakness (which is possible, since these algorithms are newer), the traditional ECDHE component still provides protection. Conversely, if ECDHE eventually falls to quantum attacks, ML-KEM covers you. You get the best of both worlds, with neither being a single point of failure.
JEP 527 delivers three hybrid schemes in the SunJSSE provider: X25519MLKEM768 (combining ECDHE with X25519 and ML-KEM-768), SecP256r1MLKEM768 (combining ECDHE using the secp256r1 curve with ML-KEM-768), and SecP384r1MLKEM1024 (combining ECDHE with the secp384r1 curve and ML-KEM-1024). OpenJDK
The Best Part: No Code Changes Required
One of the most compelling aspects of JEP 527 is that, for most applications, it just works. Applications that use the javax.net.ssl APIs will benefit from these improved algorithms by default, without any change to existing code. Inside.java JDK 27’s TLS stack will automatically prefer the hybrid scheme in new connections, as long as the server supports it.
Of course, for teams that want explicit control — for example, to enforce only quantum-resistant schemes in high-security environments — the SSLParameters::setNamedGroups API is available. But the default behaviour means upgrading the JDK is itself a meaningful security improvement.
5. The NIST Deprecation Timeline: What It Means in Practice
Let’s translate the regulatory picture into practical terms. Here’s how the timeline stacks up:
PQC compliance vs. Java JDK releases (2023–2035)
As you can see, Java is actually well ahead of the NIST curve — but the enterprise adoption gap between “JDK ships it” and “all production services are running it” is where the real risk lives.
The shift from SHA-1 to SHA-2 took over 12 years across industries, and that migration was far simpler than moving to post-quantum cryptography. Keyfactor PQC involves larger key sizes, new algorithm families, potential protocol compatibility issues, and library updates across your entire dependency graph. In short, teams that start now will be in good shape by 2030. Teams that wait until 2028 likely won’t.
6. What Teams on JDK 17 or 21 Can Do Today
If you’re running an LTS release — JDK 17 or JDK 21 — you don’t have to wait. For teams on JDK 17 or JDK 21, the practical path to PQC today runs through BouncyCastle 1.80+, which implements FIPS 203, 204, and 205 and integrates cleanly with the standard JCA KeyPairGenerator, Signature, and KeyGenerator APIs. Java Code Geeks
BouncyCastle is a well-established cryptographic library, and its recent releases are essentially a bridge that lets you adopt post-quantum algorithms years before your JDK upgrade cycle would otherwise allow it.
7. A Practical Migration Checklist for Enterprise Teams
Migrating to post-quantum cryptography isn’t a single task — it’s a multi-phase program. Here’s how to think about it:
Phase 1 — Audit (Do This Now)
The first step is simply knowing what you have. Identify every place in your codebase and infrastructure where asymmetric cryptography is used. Look for RSA key exchange in TLS configurations, ECDSA signatures in JWT handling, any hardcoded algorithm names like "RSA" or "EC" in your Java security code. Tools like quantum cryptography NIST’s Migration to PQC Project offer guidance on discovery tooling.
Phase 2 — Build Cryptographic Agility
Rather than hardcoding algorithm choices, refactor your security layer so that the algorithm selection is configurable. The key lesson is to build algorithm agility now, before you are forced to make breaking changes under a compliance deadline. Java Code Geeks A well-designed crypto-agile architecture can swap from RSA to ML-KEM in a configuration change rather than a code rewrite.
Phase 3 — Adopt ML-DSA for Signing Now
Digital signature migration is less urgent than TLS key exchange (signatures don’t suffer from the HNDL threat in the same way), but it’s also simpler to start with. JDK 24’s ML-DSA implementation is production-ready, so there’s no reason to wait on signing pipelines, JWT issuance, or code artifact signing.
Phase 4 — Plan Your JDK 27 Upgrade Path
Since JEP 527 brings hybrid TLS with zero code changes required, the most important planning question becomes: when can we upgrade to JDK 27? Start that conversation with your platform and ops teams now. JDK 27 is scheduled for GA in September 2026 Jvm-weekly, so a Q4 2026 or Q1 2027 upgrade window is realistic for most teams.
Phase 5 — Test Hybrid TLS Today with JDK 27 Early Access
You don’t have to wait for GA. Early access builds of JDK 27 beginning with build 6 already include JEP 527. Inside.java Setting up a test environment on the EA build now means you’ll have months of operational experience before GA ships, and you’ll catch any compatibility issues with your load balancers, API gateways, or third-party TLS libraries well in advance.
8. The Bigger Picture: Algorithm Agility as a First-Class Concern
One subtle but important shift in mindset that PQC migration requires is treating cryptographic agility as a design principle, not an afterthought. The PQC standards are still relatively new. The IETF specifications for hybrid key exchange in TLS 1.3 are still in the draft stage, and if the specifications change materially when they become RFCs, the JDK’s implementation will be adjusted accordingly. OpenJDK
This means even ML-KEM and ML-DSA, mature as they are today, may have parameter recommendations evolve over time. Systems that hardcode "ML-KEM-768" the same way they once hardcoded "RSA/2048" will face the same painful refactoring cycle all over again. The better pattern is to treat algorithm selection as configuration — something that can change without a code deployment.
9. What We’ve Learned
Looking across the full landscape of Java’s post-quantum journey, a clear picture emerges. Java has been laying groundwork since JDK 21 with the KEM API, shipped the first production-ready PQC algorithms (ML-KEM and ML-DSA) in JDK 24, and is on track to deliver native hybrid TLS 1.3 in JDK 27 by September 2026. Meanwhile, NIST has set firm 2030 and 2035 deadlines for deprecating and disallowing classical asymmetric algorithms like RSA and ECDSA.
Enterprise migration timelines for large organisations typically run 12–15 years, which means teams that haven’t already started their cryptographic inventory and agility work are already behind the curve. The most impactful action most Java teams can take today is not to wait for JDK 27 — but to begin the audit, adopt BouncyCastle 1.80+ or JDK 24 for algorithm exploration, build cryptographic agility into their security layer, and plan their JDK 27 upgrade path now. The Java platform has done its job. The next step belongs to the teams running it.
