From Theory to Practice: Real-World Lessons in Post-Quantum Cryptography Migration NISHIKAWA, Akihiro (Aki) Cloud Solution Architect, Microsoft @logico_jp @logico-jp.dev linkedin.com/in/anishi1222/ 

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

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

Problem & Urgency 

No cryptography stays safe forever. 

Your data may be already compromised...  Example: 10-year retention period (varies by industry) 2036 End of retention period 2026 Data encrypted with RSA/ECDSA 

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

If “Q-Day” happened in the retention period... Q-Day (or Y2Q)  The moment quantum computers can break today’s public-key cryptography.  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 encrypted with RSA/ECDSA 

Post-Quantum Cryptography (PQC) New cryptographic algorithms designed to be secure against quantum attacks.  Based on math problems that quantum computers (as far as we know) cannot solve efficiently  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. 

FIPS for PQC Approved and Effective Approved on 13 August 2024 and has been effective since 14 August 2024. FIPS 203 ML-KEM FIPS 204 ML-DSA FIPS 205 SLH-DSA • 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 will be selected and added Post-Quantum Cryptography | CSRC HQC FIPS-206 FN-DSA • 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 sooner actions needed? 

The Quantum Computer Breakthrough Required Qubits 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 Estimated in 2019 20M Re-estimated 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 

There’s a Big Gap Between Awareness and Action. 65% 69% 5% of organisations are concerned about HNDL attacks 2025_07_10_Capgemini_Post-Quantum-Cryptography- Report_News-Alert.pdf of organisations believe quantum computing will break encryption within 5 years Quantum Readiness Gap: A DigiCert Study On Quantum-Safe Encryption of organizations have deployed PQC solutions. Just 5% of Enterprises Have Deployed Quantum-Safe Encryption - Infosecurity Magazine 

Government Deadlines Are Real Roadmap of each country (1/2) ~2027 – New procurement must incorporate PQC ~2030 – Deadline for phasing out non-PQC-compliant equipment ~2035 – Full transition of national security systems NSA's CNSA 2.0 Guidance [NSA's CNSA 2.0 Guidelines (NSM 10)] ~2026 – Each country shall formulate plans ~2030 – Commence transition to priority systems ~2035 – Achieve full implementation Recommendation on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography 

Government Deadlines Are Real Roadmap of each country (2/2) ~2034 – Full transition target (estimated) Timelines for migration to post-quantum cryptography (March 2025) ~2035 – Full transition target (estimated) A roadmap will be formulated during the 2026 fiscal year. Transition to Post-Quantum Cryptography (PQC) in Government Agencies and Other Organizations (2025) report_202511.pdf ~2030 – Ensure quantum resistance for confidential data Planning for post-quantum cryptography (September 2025) 

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. – The PQC Migration Handbook Cryptographic migration takes a long time... 

Industry Movement PQC support has been formally rolled out across major cloud services.  Amazon Web Services  ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager  Amazon CloudFront launches TLS security policy with post-quantum support  AWS Private CA now supports post-quantum digital certificates  Google Cloud  Announcing quantum-safe digital signatures in Cloud KMS  Post-quantum cryptography (PQC)  Microsoft Azure  Quantum-safe security: Progress towards next-generation cryptography  Post-quantum resilience: building secure foundations 

Real-world uptake of PQC is faster than expected Browsers OpenSSL • Default to hybrid post-quantum TLS. • By late 2025, all leading browsers and TLS libraries have X25519+Kyber- 768 enabled by default. • OpenSSL 3.5.0 supports PQC algorithms. • Per TLS enhancement, hybrid PQC KEM groups are added and X25519MLKEM768 is used for Default TLS key share. OpenSSL 3.5 Series Release Notes | OpenSSL Library X25519+ML-KEM-768 hybrid key exchange in production (opt-in) Over 50% of Cloudflare’s traffic uses PQC encryption. Cloudflare Radar State of the post-quantum Internet in 2025 • About 55% of human traffic • ~35% of all traffic was using hybrid KEM Cloudflare Akamai Post-Quantum Cryptography Implementation Considerations in TLS 

Why Are Java Applications at Risk? Applications last for a long time. Rely on cryptography heavily. Need integration Not just an infrastructure problem. 

Any Other Risks of Not Acting? 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 (Kyber-based) JEP 497: ML-DSA (Dilithium-based) Java 24 Mar 2025 JEP 510: Extended KDF API (Key Derivation Functions) for hybrid protocols 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 

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 to 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); 

Bouncy Castle (BC) https://www.bouncycastle.org/  Comprehensive PQC support ahead of the JDK.  BC 1.79 (the latest is 1.81) 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" ); 

What about TLS? 

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) JEP 496: ML-KEM (Kyber-based) JEP 497: ML-DSA (Dilithium-based) JEP 510: Extended KDF API (Key Derivation Functions) for hybrid protocols 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 (target, integrated) # Default JSSE will cover these algorithms in TLS. Java 27 Sep 2026 

Current Limitations & Gaps • JEP 527 is integrated in Java 27!! • Post-Quantum Hybrid Key Exchange for TLS 1.3 • Current default JSSE doesn’t cover PQC in TLS. (JSSE provider can be added.) Java Secure Socket Extension (JSSE) Reference Guide • ML-KEM and ML-DSA are available in JDK 24/25 APIs. 

Migration Strategy 

Migration Strategy 1. Inventory 2. Prioritize KEM over signatures 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) 

2. Prioritize KEM over signatures Key Encryption Mechanism / Key Exchange 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 to make security better. draft-ietf-tls-ecdhe-mlkem - Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 draft-ietf-tls-hybrid-design - Hybrid key exchange in TLS 1.3 JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3 Classic PQC Pros Long security verification history. No efficient solution using quantum computers. Cons Vulnerability to quantum computers is a concern. Short security verification history. (a risk to be broken) 

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  DigiCert  Started offerings and pilot operations for issuing “PQC certificates. 

Key Exchange flow in TLS 1.3 (as of now) Generate (EC)DHE key pair Send ClientHello ClientHello - key_share (includes PK_c) - signature algorithms - psk_key_exchange_modes - pre_shared_key 1. Decide key algorithm 2. Generate (EC)DHE keypair Derive shared_secret with (EC)DHE Derive handshake_secret from shared_secret by HKDF shared_secret =ECDH(PK_c, SK_s) handshake_secret =HKDF(shared_secret ...) Send ServerHello Derive shared_secret with (EC)DHE Derive handshake_secret from shared_secret by HKDF shared_secret =ECDH(PK_s, SK_c) handshake_secret =HKDF(shared_secret ...) Decrypt encrypted parts of ServerHello with a key derived by HKDF from handshake_secret Public key (PK_c) Private key (SK_c) Public key (PK_s) Private key (SK_s) ServerHello - key_share (includes PK_s) - pre_shared_key - EncryptedExtensions - CertificateRequest - Certificate - CertificateVerify - Finished - Application Data Encrypted with a key derived by HKDF from handshake_secret . 

Hybrid Key Exchange flow in TLS 1.3 with ECDHE and ML-KEM draft-ietf-tls-hybrid-design - Hybrid key exchange in TLS 1.3 Generate (EC)DHE key pair Send ClientHello 1. Decide key algorithm 2. Generate (EC)DHE keypair Derive shared_secret_x with (EC)DHE Derive handshake_secret from shared_secret by HKDF shared_secret_x =ECDH(PK_c, SK_s) handshake_secret =HKDF(shared_secret ...) Public key (PK_c) Private key (SK_c) Public key (PK_s) Private key (SK_s) Generate (PQ)KEM key pair Encapsulation key (EK) Decapsulation key (DK) 1. Generate shared_secret_y 2. Encapsulate the secret with EK Enc=Encap(EK, shared_secret_y) Concatenate shared_secret=shared_secret_x || shared_secret_y ClientHello - key_share (includes PK_c, EK) - signature algorithms - psk_key_exchange_modes - pre_shared_key [Note] In the key_share extension of ClientHello , a new public key and the encapsulation key (EK) are sent at the same time. The server performs 1. ECDH key exchange to derive shared_secret_x 2. Encapsulates the randomly generated key shared_secret_y 3. Combines shared_secret_x and shared_secret_y to derive shared_secret 4. Generates handshake_secret using the HMAC Key Derivation Function (HKDF). 

Send ServerHello Derive shared_secret_x with (EC)DHE Derive handshake_secret from shared_secret by HKDF shared_secret_x =ECDH(PK_s, SK_c) handshake_secret =HKDF(shared_secret ...) Decrypt encrypted parts of ServerHello with a key derived by HKDF from handshake_secret Decapsulate enc with EK and obtain shared_secret_y shared_secret_y =Decap(DK, Enc) Concatenate shared_secret=shared_secret_x || shared_secret_y ServerHello - key_share (includes PK_s, Enc) - pre_shared_key - EncryptedExtensions - CertificateRequest - Certificate - CertificateVerify - Finished - Application Data [Note] In the key_share extension of ServerHello , a new public key and the shared_secret_y are sent at the same time. The steps in the client are similar to what the Server performs. That is, 1. Performs an ECDH key exchange to derive shared_secret_x 2. Decapsulates to derive shared_secret_y 3. Combines shared_secret_x and shared_secret_y to derive shared_secret, 4. Generates handshake_secret using the HKDF. Encrypted with a key derived by HKDF from handshake_secret . 

How about direct replacement (Pure PQC)? Pros Cons • Efficiency: Eliminates overhead of the hybrid method (though PQC keys are still larger than ECC). • Simplicity: Relying on a single cryptographic primitive reduces code complexity. • Full Compliance (Future): Aligns with mandates like NSA CNSA 2.0. • Single Point of Failure: If the PQC algorithm is broken, you're unprotected. • Incompatibility: Legacy systems lacking PQC won't connect. • Significant variation between vendors: Many current HSMs and smart cards lack hardware acceleration for PQC, slowing performance on older devices 

Hybrid is the practical solution for a while Ultimately, pure will be the goal. Feature 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 Lowest (Dual overhead) Medium (PQC overhead only) Primary Use Case Commercial/Civilian Transition Military/Intel (High Security) CYBER; Migration strategies and recommendations to Quantum Safe schemes Migration to Post-Quantum Cryptography | NCCoE Announcing the Commercial National Security Algorithm Suite 2.0 Avis de l'ANSSI sur la migration vers la cryptographie post-quantique (suivi 2023) 

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). 

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 (YAML) signature : algorithmType : ML- DSA # switchable: RSA, ML - DSA, etc. kem: algorithm : ML- KEM parameterSet : ML_KEM_768 # switchable: ML_KEM_512, ML_KEM_768, ML_KEM_1024 tls : # TLS 1.3 "named groups" ( supported_groups / key_share ) groups : # Hybrid PQC groups (IETF / OpenJDK JEP 527) - X25519MLKEM768 - SecP256r1MLKEM768 - SecP384r1MLKEM1024 # Classic fallback groups (compatibility) - X25519 - secp256r1 - secp384r1 

// Java (Strategy + DI) public interface SignService { byte [] sign( byte [] data, PrivateKey key) throws Exception ; boolean verify( byte [] data, byte [] sig, PublicKey key) throws Exception ; } @ Service public class RSASignService implements SignService { /* ... */ } @ Service public class MLDSASignService implements SignService { /* ... */ } @ Configuration public class CryptoConfig { @ Value ( "${signature.algorithmType}" ) private String algType ; @ Bean public SignService signService ( Optional rsa , Optional mlDsa ) { ...; } } 

5. Topological Migration Procedures 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 (Trust Chain) Outside-In (Gateway Shield) Primary Goal Full System Compliance Rapid Internet Protection First Step Upgrade PKI/Root CA Upgrade Edge Gateway Complexity High (Touches everything) Medium (Touches Gateway+Client) Best For Banking, Identity Systems Web Apps, Mobile Apps 

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 

Phase-1 Start by using Hybrid TLS at the Edge. Client Hybrid TLS Classic TLS CDN/Proxy Java app Backends Classic TLS 

Phase-2 Communication between CDN and Java app uses Hybrid TLS. Client Hybrid TLS Classic TLS CDN/Proxy Java app Backends Hybrid TLS 

Phase-3 All communications are using Hybrid TLS and PQC is used by default. Client Hybrid TLS Hybrid TLS CDN/Proxy Java app Backends Hybrid 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. ML-KEM-768 Public key shared key for encapsulation X25519 public key Key size (byte) 1184 1088 32 

Other viewpoints Larger key / signature sizes KBs vs bytes Resize buffers; optimize certificate chains TLS handshake latency Small % increase (e.g.; Chrome: <10%) TLS 1.3; session resumption; avoid extra RTT CPU usage Moderate increase Modern JVM/CPUs; profile; selective PQC use Network bandwidth Larger ClientHello / Cert messages Certificate compression; conditional key-share HSM support Varies by vendors Track roadmaps; software keys until supported 

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 Timing analysis on critical operations Side channel Graceful failure modes 

8. Migration Timeline  It depends upon customer requirements...  The authorities may set a deadline for the transition by law.  In this case, transition by the deadline is mandatory. 

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 (including JEP 527) 

Common Migration Challenges 

Common Migration Challenges Issue Impact Solution Protocol ossification Handshake failures Canary rollout + fallback Hybrid mode + GREASE (Generate Random Extensions And Sustain Extensibility) Legacy client compatibility Breakages Hybrid mode + staged enablement Certificate size bloat Latency/storage Trim chains + compression + limits monitoring Library updates Security gaps Frequent upgrades; track advisories Stateful signatures State loss risks HSM/state management; procedures Side-channel leakages Leakage risks Constant-time libs; cross-HW testing 

Library Selection & Management Library/Tool Use Case Notes JDK 25+ Built-in PQC APIs Prefer standards JEP 527 is targeted to JDK 27 Bouncy Castle Legacy JDKs; full PQC today JCA provider Hybrid cert options OpenSSL/BoringSSL Cross-language interop/testing Validate handshakes & hybrids OpenSSL 3.5 offers X25519MLKEM768 as the default KeyShare for TLS. liboqs/wolfSSL Research/prototyping JNI bridges Algorithm exploration SPHINCS+/LMS/XMSS Firmware/long-term signatures Specialist libs HSM for state 

Key & Certificate Management  Plan for larger key/cert sizes (buffers, DB fields, keystores)  Prefer PKCS#12 stores; validate parsing/limits  Track HSM/KMS PQC roadmaps; use software storage until supported  Rotate keys/certs; document hierarchies and signatures  Manage dual trust anchors during transition 

Monitoring & Observability  Log negotiated cipher suites, key groups, cert validation results  Alerts for fallbacks, handshake errors, algorithm use beyond policy  Dashboards: PQC vs classical %, latency trends, error rates by algorithm  Tag requests for analysis (e.g., PQC-enabled) 

Common Pitfalls to Avoid Mistake Better Approach Hard-coding algorithm names Configuration + DI for flexibility Ignoring backward compat. Hybrid mode and staged rollout No rollback plan Design graceful fallbacks Only “happy path” testing Include error cases, versions, unsupported groups Waiting for perfection Start PoCs now; iterate Ignoring performance Measure early; optimize handshake/key usage Side-channels overlooked Use constant-time libs; run side-channel tests Vendor lock-in Open standards; multiple providers 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 

Best Practices 1. Inventory all cryptographic uses (TLS, signing, storage, tokens) 2. Prioritize Key Encapsulation Mechanisms (KEM) over signatures 3. Prefer hybrid modes during transition 4. Design for crypto-agility (config + abstractions) 5. Test thoroughly (vectors, interop, performance, fallback) 6. Monitor and alert on crypto behaviors 7. Manage side-channel risks 8. Stay informed (NIST/IETF/JEPs; library releases) 

Takeaways 

Key Takeaways Quantum threats are real NIST PQC standards are ready Already supported PQC Hybrid + crypto-agility Start now HNDL is active! • ML-KEM • ML-DSA • SLH-DSA Other standards are now being discussed. Hybrid key exchange support in TLS 1.3 (JEP 527) expected in upcoming JDK. For safe migration Migration spans years; monitor and iterate. 

Call to Action  Weeks 1–2  inventory all crypto; identify long-lived data  Month 1  PoC with BC/JDK; measure performance  Months 2–3  roadmap; budget; stakeholder briefings  2026 Q4 – 2028  edge hybrid TLS; hybrid certificates; Java 27 (JEP 527)  2028+  migrate core apps; phase out classical; align to policy timelines 

The future’s security depends on what we do today. 

Tack! ありがとう! Thank you!