Preparing Java Applications for the Quantum Era NISHIKAWA, Akihiro (Aki) Cloud Solution Architect, Microsoft @logico_jp @logico-jp.dev linkedin.com/in/anishi1222/ 

Hallo! こんにちは! Hello! { "name": "NISHIKAWA, Akihiro", "nationality": "Japan", "work": "Microsoft", "favourites": [ "JVM", "GraalVM", "Azure" ], "expertise": [ "Application integration", "Container", "Serverless" ] } 

Agenda  Problem & Urgency  PQC support in Java  Migration Strategy  Takeaways & Call to Action 

TL;DR Quantum threat is Real. Java is getting ready for PQC. The sooner, the better. 

Problem & Urgency 

No cryptography stays safe forever. 

10-year retention period 2036 End of retention period 2026 Data protected with RSA/ECC 

Harvest-Now, Decrypt-Later (HNDL) Attack Malicious attackers have captured encrypted data to decrypt it when quantum computers emerge. 2030+ Quantum computer emerges 2036 End of retention period HNDL attack 2026 Data protected with RSA/ECC 

If “Q-Day/Y2Q” happened in the retention period... Q-Day.org - Q-Day, Y2Q, PQC, Quantum Readiness, Quantum Security 2030+ Quantum computer emerges 2036 End of retention period Q-Day HNDL attack 2026 Data protected with RSA/ECC 

Post-Quantum Cryptography (PQC)  New cryptographic algorithms designed to be secure against quantum attacks.  Based on mathematical problems that quantum computers (as far as we know) cannot solve efficiently, such as  lattice problems (e.g.; ML-KEM, ML-DSA)  hash-based structures (e.g.; SLH-DSA)  error-correcting codes (e.g., HQC), etc.  No quantum hardware is needed.  These algorithms run on classical computers. 

Why sooner actions needed? 

The Quantum Computer Breakthrough How many noisy qubits are needed to break RSA-2048? Research by Craig Gidney and Martin Ekerå How to factor 2048-bit RSA integers in 8 hours using 20 million noisy qubits – Quantum In 2019 20M In 2025 <1M Research by Google’s Quantum AI team (Craig Gidney) [2505.15917] How to factor 2048-bit RSA integers with less than a million noisy qubits 

Awareness is high, but deployment is lagging 65% of orgs are concerned about HNDL attacks. (Capgemini, Jul 2025) 69% of orgs believe quantum computing will break encryption within 5 years. (DigiCert, May 2025) expect to have at least one PQC algorithm operational by the end of 2026. (Trusted Computing Group, Nov 2025) 20% 5% 55% of orgs have begun PQC migration (Utimaco, 2025) have fully deployed quantum-safe encryption. (DigiCert, May 2025) 

Government Deadlines ~2035 Full transition of national security systems ~2035 Achieve full implementation ~2035 Full transition target ~2035 Full transition target (estimated) ~2030 Ensure quantum resistance for confidential data 

For example, it took many organizations over five years to migrate from the vulnerable primitive SHA-1 to its secure successor SHA-256, even after the necessary specifications and implementations were available. (e.g., SHA-1 deprecated 2017; many systems still used it in 2020+) – The PQC Migration Handbook Cryptographic migration takes time 

Industry Movement Cloud services Major cloud providers are already rolling out support for PQC. Browsers Default to hybrid post-quantum TLS. Libraries OpenSSL 3.5.0 and later supports PQC algorithms. CDN Over 60% of Cloudflare’s traffic by human uses PQC encryption. 

HTTP requests by PQC support time series for Europe Data Explorer | Cloudflare Radar Human Automated 

Can we use PQC today? 

FIPS for PQC Approved and Effective Approved in August 2024 ML-KEM FIPS 203 ML-DSA FIPS 204 SLH-DSA FIPS 205 • CRYSTALS-Kyber based • Module Lattice based Key Encapsulation Mechanism • Key establishment • CRYSTALS-Dilithium based • Module Lattice based Digital Signature Algorithm • Digital signatures • SPHINCS+ based • StateLess Hash- based Digital Signature Algorithm • stateless hash- based signatures Post-Quantum Cryptography FIPS Approved | CSRC 

More standards coming Post-Quantum Cryptography | CSRC HQC (FIPS number TBD) FN-DSA FIPS-206 • A backup algorithm for ML- KEM • Hamming Quasi-Cyclic • Code-based key exchange mechanism • FALCON based • FFT (fast-Fourier transform) over NTRU-Lattice-Based Digital Signature Algorithm NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption | NIST AMS :: Feature Column from the AMS CSRC Presentations: FIPS 206: FN-DSA (Falcon) | CSRC Falcon 

Why Are Java Applications at Risk? Live for a long time. Use crypto everywhere. Not just an infra problem, integration needed. Security risk Business risk Late adoption woes Cost & effort 

PQC support in Java 

Java PQC Timeline A timeline of Java (JDK) releases and their post-quantum crypto features: JEP 452: KEM API (Key Encapsulation Mechanism) # No PQC algorithms included (APIs only) Java 21 Sep 2023 JEP 496: ML-KEM JEP 497: ML-DSA Java 24 Mar 2025 JEP 510: Key Derivation Function API Java 25 Sep 2025 RFC 9180 compliant Hybrid Key Encryption algorithm (Cipher “HPKE”) (JDK-8325448) Signed JAR Support for ML-DSA (JDK-8349732) Java 26 Mar 2026 

Bouncy Castle (BC) https://www.bouncycastle.org/  Comprehensive PQC support ahead of the JDK.  BC 1.79 (the latest is 1.83) or later implement ML-KEM, ML-DSA, as well as SLH-DSA (SPHINCS+), HQC, and Falcon.  Can use all NIST finalists (and some alternates) on Java 8, 11, 17, etc., via Bouncy Castle.  Integration via JCA Provider  To use BC’s PQC, register the provider and request algorithms by name and provider: import java.security.Security; import org.bouncycastle.jce.provider.BouncyCastleProvider; Security.addProvider(new BouncyCastleProvider()); ... // The JCA will pick Bouncy Castle in the list KeyPairGenerator kpg = KeyPairGenerator.getInstance("ML-DSA", "BC"); 

ML-KEM Key Exchange Key exchange using ML-KEM // Example: use ML-KEM-768 as the default KeyPairGenerator g = KeyPairGenerator.getInstance("ML-KEM"); KeyPair kp = g.generateKeyPair(); // Encapsulate a secret with the public key (sender side) KEM kem = KEM.getInstance("ML-KEM"); KEM.Encapsulator encap = kem.newEncapsulator(kp.getPublic()); KEM.Encapsulated capsule = encap.encapsulate(); // Agreed secret key and send these bytes to other party SecretKey sharedSecret = capsule.key(); byte[] encapsulatedBytes = capsule.encapsulation(); // Decapsulate on the other side using private key (receiver side) KEM.Decapsulator decap = kem.newDecapsulator(kp.getPrivate()); SecretKey sharedSecret2 = decap.decapsulate(encapsulatedBytes); 

ML-DSA Digital Signature Digital signing and verification using ML-DSA // Generate ML-DSA (Dilithium) key pair KeyPairGenerator kpg = KeyPairGenerator.getInstance("ML-DSA"); // ML-DSA-65 key pair as the default KeyPair sigPair = kpg.generateKeyPair(); byte[] data = "Important message".getBytes(StandardCharsets.UTF_8); Signature sig = Signature.getInstance("ML-DSA"); sig.initSign(sigPair.getPrivate()); sig.update(data); byte[] signature = sig.sign(); // ...transmit 'data' and 'signature'... // Verification sig.initVerify(sigPair.getPublic()); sig.update(data); boolean valid = sig.verify(signature); 

What about TLS? 

JEP 510: Key Derivation Function API JEP 496: ML-KEM JEP 497: ML-DSA Java PQC Timeline A timeline of Java (JDK) releases and their post-quantum crypto features: JEP 452: KEM API (Key Encapsulation Mechanism) # No PQC algorithms included (APIs only) RFC 9180 compliant Hybrid Key Encryption algorithm (Cipher “HPKE”) (JDK-8325448) Signed JAR Support for ML-DSA (JDK-8349732) Java 21 Sep 2023 Java 24 Mar 2025 Java 25 Sep 2025 Java 26 Mar 2026 Java 26 has not incorporated PQC into the JSSE standard TLS. 

Java PQC Timeline A timeline of Java (JDK) releases and their post-quantum crypto features: Java 24 Mar 2025 Java 25 Sep 2025 Java 26 Mar 2026 JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3 (Completed) # Default JSSE will cover these algorithms in TLS. Java 27 Sep 2026 Java 26 has not incorporated PQC into the JSSE standard TLS. 

Migration Strategy 

Migration Strategy 1. Inventory 2. Prioritization 3. Hybrid 4. Crypto-agility 5. Where to start migration (phased approach) 6. Performance verification 7. Testing thoroughly 8. Check the timeline 

1. Inventory  Identify TLS endpoints, cipher suites, mTLS, cert stores.  Catalogue code/JAR signing, JWT/OIDC/SAML algorithms.  Locate custom Cipher usages and data-at-rest encryption.  Use static analysis/scanners for API/algorithm detection.  Dependency libraries  Configuration  Certificate OIDs (Object Identifiers) 

Where Does Crypto Hide? A typical Spring Boot microservice — how many crypto usage points can you spot? src/main ├── java/com/example/pqcdemo │ ├── config │ │ └── SecurityConfig.java │ ├── controller │ │ └── ApiController.java │ ├── PqcDemoApplication.java │ └── service │ ├── EncryptionService.java │ ├── HmacService.java │ ├── JwtService.java │ └── LicenseService.java └── resources ├── application.properties └── keystore.p12 

src/main ├── java/com/example/pqcdemo │ ├── config │ │ └── SecurityConfig.java │ ├── controller │ │ └── ApiController.java │ ├── PqcDemoApplication.java │ └── service │ ├── EncryptionService.java │ ├── HmacService.java │ ├── JwtService.java │ └── LicenseService.java └── resources ├── application.properties └── keystore.p12 _________________________JWT keys from keystore _________________________REST Endpoints _________________________RS256 via NimbusJwtEncoder _________________________AES-256-GCM via Tink _________________________HMAC-SHA256 via BC HMac _________________________CMS/PKCS#7 via BC ____________________________TLS + DB SSL config ____________________________RSA-2048 cert 

4-Layer Inventory ❶ Dependencies - Nimbus JWT - Bouncy Castle - Google Tink - PostgreSQL JDBC ❷ Source code - Cipher - Signature - KeyPairGen ❸ Configuration - server.ssl.* - Database SSL parameters ❹ Runtime 363 algorithms - Vulnerable: 94 - PQC: 24 (JDK 25.0.2) OMB M-23-02: Migrating to Post-Quantum Cryptography CISA/NIST/NSA: Quantum-Readiness — Migration to Post-Quantum Cryptography NIST CSWP-39: Considerations for Achieving Crypto Agility White House Report on Post-Quantum Cryptography (NSM-10 progress) 6 USC §1526: Inventory of cryptographic systems; migration to post-quantum cryptography Maven/Gradle dependency tree JCE/JCA API and Framework API Properties/YAML and KeyStore JCE providers, registered algorithms, and JVM settings 

What The Audit Finds - Dependencies Crypto hidden in dependencies, source code, configuration, and framework APIs Nimbus JOSE+JWT JWS — RSA signing inside framework Bouncy Castle 1.83 General-purpose crypto provider Google Tink 1.9.0 Algorithm hidden in key template Spring Security 6.5 BCrypt, crypto utilities PostgreSQL JDBC TLS inside the driver — invisible Commons Codec Hashing/encoding utilities JDK built-in JCA/JCE Quantum-vulnerable Attention Low-risk 

What The Audit Finds - Source and Config Crypto hidden in dependencies, source code, configuration, and framework APIs JCE / JCA API Calls KeyStore.getInstance (2 files) Configuration server.ssl.enabled=true datasource sslmode=verify-full Framework / Library Patterns NimbusJwtEncoder (RS256 signing) NimbusJwtDecoder (RS256 verification) JcaContentSignerBuilder (SHA256withRSA) Tink AEAD (AES-256-GCM) Tink KeysetHandle BC CMS / SignerInfoGenerator BC HMac + SHA256Digest 

What The Audit Finds - KeyStore Crypto hidden in dependencies, source code, configuration, and framework APIs keystore.p12  Alias: server  Type: PrivateKeyEntry  Sig: SHA256withRSA  Quantum-vulnerable Used for:  TLS server certificate  JWT signing key (RS256)  License cert verification Every HTTPS connection is an HNDL target classical key exchange (ECDHE) is vulnerable. 

Audit results: 20 Crypto Usage Points 4 Quantum-vulnerable • Nimbus JWT Encoder • Nimbus JWT Decoder • JcaContentSignerBuilder (SHA256withRSA) • Keystore cert (RSA-2048) 12 Attention • PG JDBC TLS • BC • Tink AEAD • Spring Security • KeyStore • server.ssl.* • DB SSL • CMS 4 Low-risk • HMAC-SHA256 • BC HMac • BC SHA256Digest • Commons Codec 

2. Prioritization Target Why Solution Data-in-Transit TLS VPN mTLS HNDL target TODAY Hybrid TLS (JEP 527) Data-at-Rest Database file encryption Long-lived data at risk (especially if the data is stored more than 5 years) ML-KEM key wrapping Code Signing JAR Cert license Trust, not secrecy ML-DSA (at next rotation) 

Prioritize KEM over Signatures KEM: Key Encapsulation Mechanism KEM Communication data stolen risks being decrypted by quantum computers in the future. Exactly ‘Harvest now, decrypt later’. Signature Authentication (signature) need only remain unbroken until quantum computers become practical. 

3. Hybrid Combine traditional cryptography with PQC for a security net. Hybrid (Composite) Direct Replacement (Pure) Security Posture Classical + Quantum Resistant Quantum Resistant Only Risk of Algorithm Break Low (Classical backup exists) High (No backup) Performance Slightly lower (dual overhead, but negligible after handshake) Medium (PQC overhead only) Primary Use Case Commercial/Civilian Transition Military/Intel (High Security) 

PKI Certificate Migration  Challenge: old vs. new clients & toolchains  Solution: hybrid/dual-signed certificates  leaf → intermediate → root  Plan for  increased sizes  update key stores/trust stores & validation logic Root CA [RSA + ML-DSA signatures] Intermediate CA [RSA + ML-DSA signatures] Leaf Certificate [RSA + ML-DSA signatures] Service (Java) draft-ietf-lamps-pq-composite-sigs - Composite ML- DSA for use in X.509 Public Key Infrastructure 

PKI Certificate Migration  EJBCA  EJBCA 9.1 supports ML-KEM/ML-DSA certificate issuance. (Enterprise JavaBeans Certificate Authority)  AWS Private Certificate  AWS Private CA now supports post-quantum digital certificates - AWS  CA providers like DigiCert  Start to provide post-quantum and hybrid certificates for evaluation and testing, including experimental algorithms such as Falcon.  Public commercial availability depends on standards and ecosystem readiness. 

Hybrid TLS 1.3 handshake (X25519MLKEM768) draft-ietf-tls-hybrid-design - Hybrid key exchange in TLS 1.3 Generate X25519 key pair (sk_x, pk_x = 32 bytes) Generate ML-KEM-768 key pair (dk, ek = 1184 bytes) ClientHello TLS Version: 1.3 (0x0304) Random: 32 bytes Cipher Suites: [TLS_AES_256_GCM_SHA384, ...] Extensions: supported_versions: [TLS 1.3] supported_groups: [X25519MLKEM768 (0x11EC), X25519 (0x001D), ...] key_share: [{ group: X25519MLKEM768 (0x11EC), key_exchange: pk_x (32B) ‖ ek (1184B) = 1216 bytes total }] signature_algorithms: [...] server_name: example.com Client (Key Generator + Decapsulator) Server (Encapsulator) Plaintext (unencrypted) 

Hybrid TLS 1.3 handshake (X25519MLKEM768) draft-ietf-tls-hybrid-design - Hybrid key exchange in TLS 1.3 Generate X25519 key pair (sk_s, pk_s = 32 bytes) ML-KEM-768.Encaps(ek) → (ct = 1088 bytes, ss_pq = 32 bytes) X25519 DH(sk_s, pk_x) → ss_ecdh = 32 bytes ServerHello TLS Version: 1.3 (0x0304) Random: 32 bytes Cipher Suite: TLS_AES_256_GCM_SHA384 Extensions: supported_versions: TLS 1.3 key_share: { group: X25519MLKEM768 (0x11EC), key_exchange: pk_s (32B) ‖ ct (1088B) = 1120 bytes total } X25519 DH(sk_x, pk_s) → ss_ecdh = 32 bytes ML-KEM-768.Decaps(dk, ct) → ss_pq = 32 bytes 

Hybrid TLS 1.3 handshake (X25519MLKEM768) draft-ietf-tls-hybrid-design - Hybrid key exchange in TLS 1.3 Shared Secret = ss_ecdh (32B) ‖ ss_pq (32B) = 64 bytes → HKDF-Extract → Handshake Secret {EncryptedExtensions} {Certificate} {CertificateVerify} {Finished} {Finished} Encrypted Application Data Client (Key Generator + Decapsulator) Server (Encapsulator) Encrypted with Handshake Keys Verify server certificate Derive Application Traffic Keys Application Data (HTTP/2, HTTP/3, etc.) Application Data 

Size Comparison Item X25519 [Classical] (RFC 7748) X25519MLKEM768 [Hybrid] (draft-ietf-tls-ecdhe-mlkem) Delta ClientHello key_share 32 bytes 1,216 bytes (32 + 1,184) +1,184 bytes ServerHello key_share 32 bytes 1,120 bytes (32 + 1,088) +1,088 bytes Shared Secret 32 bytes 64 bytes (32 + 32) +32 bytes 

Only nonces feed into key derivation — risks like the Triple Handshake Attack remain PQC keys are 30–50× larger — firewalls and NATs drop or truncate oversized handshakes TLS 1.2 enhancements are officially frozen — PQC work targets TLS 1.3+ only PQC KEMs need the peer's public key first — different from DH, requiring new safety analysis Static RSA mode is incompatible with PQC — passive decryption won't work either way TLS 1.2 bundles all crypto into monolithic cipher suites — hybrid combos multiply fast Why Hybrid TLS is Hard on TLS 1.2? Not impossible, but significantly harder than TLS 1.3 Weak Transcript Binding Message Size & Middleboxes IETF Feature Freeze KEM Directionality Forward Secrecy Gap Cipher Suite Explosion Upgrade to TLS 1.3 first — then add hybrid TLS 

4. Crypto-Agility  Involves abstracting cryptographic calls so that the underlying algorithm can be hot-swapped via configuration without rewriting application code.  Not an algorithm swap but a procedural prerequisite. 

Why?  Resilience:  If a specific PQC standard is broken next year, you can switch to an alternative PQC candidate immediately.  Testing:  Allows you to roll out PQC to 1% of users for testing and revert instantly if issues arise.  Please note that...  Engineering Effort: Requires refactoring legacy codebases where crypto is hardcoded (e.g., hardcoded RSA-2048 keys). 

Bad code... // hardcoded! Signature sig = Signature.getInstance("SHA256withRSA"); // hardcoded! KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA", "SunRsaSign"); 

Design Principles Don’t hard-code algorithm names or parameters Externalize choices in configuration Abstract crypto behind interfaces (strategy pattern) Leverage JCA providers to enable provider swapping Prepare fallback toggles and feature flags Config file CryptoService RSASigner Specify algorithm (ML-DSA, RSA, etc.) sign() verify() encrypt() decrypt() MlDsaSigner implements implements Signature.getInstance ("SHA256withRSA") Signature.getInstance ("ML-DSA") Interface 

crypto: mode: hybrid # classic | pqc | hybrid # Application-Level Cryptography (KEM + Signatures) # These map directly to JCA: KEM.getInstance() / Signature.getInstance() kem: algorithm: ML-KEM-768 # JCA standard name (FIPS 203, Security Level 3) signature: algorithm: ML-DSA-65 # JCA standard name (FIPS 204, Security Level 3) tls: # Named group preference order for key exchange # JDK 27+: maps to jdk.tls.namedGroups system property # Pre-JDK 27: requires Bouncy Castle JSSE (BCJSSE) provider named-groups: - X25519MLKEM768 # PQC hybrid (recommended default) - x25519 # Classical fallback - secp256r1 # Classical NIST curve fallback protocol: TLSv1.3 # JSSE provider selection # - "SunJSSE" → JDK 27+ with JEP 527 (native PQC hybrid) # - "BCJSSE" → Bouncy Castle (JDK 24–26 workaround) provider: SunJSSE keystore: type: PKCS12 # Required for PQC keys (JKS has OID limitations) path: classpath:server-pqc.p12 password: ${KEYSTORE_PASSWORD} # PQC key aliases kem-alias: mlkem # ML-KEM-768 key pair (signed by EC signer) signature-alias: mldsa # ML-DSA-65 key pair (self-signed) Configuration application.yml 

// crypto.kem.algorithm → KEM.getInstance() @Value("${crypto.kem.algorithm}") private String kemAlgorithm; // "ML-KEM-768" KEM kem = KEM.getInstance(kemAlgorithm); KeyPairGenerator kpg = KeyPairGenerator.getInstance(kemAlgorithm); // No NamedParameterSpec needed — parameter set is encoded in the name // crypto.signature.algorithm → Signature.getInstance() @Value("${crypto.signature.algorithm}") private String sigAlgorithm; // "ML-DSA-65" Signature sig = Signature.getInstance(sigAlgorithm); KeyPairGenerator kpg = KeyPairGenerator.getInstance(sigAlgorithm); KEM.getInstance() and Signature.getInstance() 

// crypto.tls.provider → SSLContext.getInstance() @Value("${crypto.tls.provider}") private String tlsProvider; // "SunJSSE" or "BCJSSE" @Value("${crypto.tls.protocol}") private String tlsProtocol; // "TLSv1.3" SSLContext ctx = SSLContext.getInstance(tlsProtocol, tlsProvider); // ctx.init(keyManagers, trustManagers, null); ← keystore config omitted for brevity // crypto.tls.named-groups → SSLParameters.setNamedGroups() or system property // Option A: Programmatic (JDK 20 or later version with appropriate provider) @Value("${crypto.tls.named-groups}") private List namedGroups; // ["X25519MLKEM768", "x25519", "secp256r1"] SSLParameters params = sslSocket.getSSLParameters(); params.setNamedGroups(namedGroups.toArray(String[]::new)); sslSocket.setSSLParameters(params); // Option B: JVM system property (JDK 27+ — zero code change) // -Djdk.tls.namedGroups=X25519MLKEM768,x25519,secp256r1 SSL/TLS 

5. Where to start migration (phased approach) Backends Java app CDN/Proxy Client Inside-Out (Core-First): The Standard Trust Chain Migration Backends Java app CDN/Proxy Client Outside-in (Gateway shield): TLS Termination Strategy 

Summary of Topology Choices Inside-Out (Core first)  Full System Compliance  1st step: Upgrade PKI/Root CA  Complexity: High (Touches everything)  Best for Banking, Identity Systems Outside-In (Gateway Shield)  Rapid Internet Protection  1st step: Upgrade Edge Gateway  Complexity: Medium (Touches Gateway + Client)  Best for Web Apps, Mobile Apps 

Hybrid TLS Hybrid TLS Hybrid TLS Outside-in (Gateway shield) Extend hybrid TLS gradually and hybrid certs internally with keeping backward compatibility, forward security, and modest overhead.  Phase 1: enable hybrid TLS at CDN/load balancer  Phase 2: upgrade app stack to Java which will support JEP 527  Phase 3: end-to-end PQC; retire classical ciphers where feasible Backends Java app CDN/Proxy Client Classic TLS Classic TLS Classic TLS 

6. Performance & Operational Impact TLS  Updating the current protocol is challenging.  Both the ClientHello and ServerHello packets get much bigger.  ClientHello packet could be fragmented at lower layers.  Unexpected behavior at intermediate switches.  The performance loss from segmentation and reassembly. 

7. Testing Strategy Unit Official vectors for ML-KEM/ML-DSA Interop Cross-implementation (Java  OpenSSL/liboqs) Hybrid TLS handshakes (OpenSSL 3.5 includes X25519MLKEM768 in the default KeyShare.) Performance Handshake latency CPU/memory Throughput Compatibility Fallbacks from PQC to classical Legacy clients Rollback Graceful failure modes Side channel Timing analysis on critical operations 

8. Migration Timeline Example: The real customer case in Japan 2025 2026 2027 2028 2029 2030 Crypto asset inventory PoC with Bouncy Castle Risk assessment Edge PQC deployment Hybrid certificates Evaluate hybrid TLS supported JDK (if released) Upgrade to hybrid TLS supported JDK/JRE Implement crypto-agility Integrate PQC Retire legacy crypto PQC-by-default operations Compliance readiness JDK 27 (Sep 2026) (including JEP 527) 

Common Migration Challenges 

Network & Protocol Challenges Protocol ossification and legacy compatibility Challenges Solution Protocol Ossification Middleboxes drop oversized PQC handshakes. Canary rollout + GREASE (RFC 8701) Chrome shipped this to billions — it works. Legacy Client Compatibility Old clients only understand RSA/ECDSA. Hybrid TLS: PQC for modern, classical for legacy to support full backward compatibility. Certificate Size Bloat ML-DSA-87 public key: ~2.5 KB. ML-DSA-65: ~1.9 KB. Prefer ML-DSA-65 (Security Level 3). Enable TLS certificate compression (RFC 8879). RFC 8701: Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility 

Crypto Infrastructure & Operations Library selection, key management, and monitoring Library Selection • JDK 24+: built-in PQC APIs (prefer standards) • Bouncy Castle 1.83: legacy JDKs, full PQC today • OpenSSL 3.5: X25519MLKEM768 as default KeyShare • liboqs/wolfSSL: research & prototyping Key & Cert Management • Plan for larger key/cert sizes (buffers, DB fields) • Prefer PKCS#12 stores over JKS • Track HSM/KMS PQC roadmaps • Manage dual trust anchors during transition Monitoring & Observability • Log cipher suites, key groups, cert validation • Alert on unexpected fallbacks to classical-only • Dashboard: PQC vs classical %, latency trends → 80% PQC adoption = quantum-ready proof for your CISO 

Takeaways 

Key Takeaways 1. Inventory You can't migrate what you can't find. 2. Hybrid The safety net during transition. 3. Start now Migration spans years, not months. 

Call to Action Q3 2026 Deploy hybrid TLS at the edge. When Java 27 ships Upgrade your application stack. Developers Architects Security leads Managers Run "keytool –list". Review codes. (4-Layer Inventory) Set up a PQC PoC environment with Bouncy Castle. Brief your CISO on the HNDL timeline. Build a roadmap and get budget approval by month three. 

No cryptography stays safe forever. But with PQC, we can stay ahead. 20 crypto usage points hide in a single microservice. The tools are ready. Java 27 brings native PQC TLS. Will you start this week? 

Vielen Dank! ありがとう! Thank you!