From Theory to Practice: Real-World Lessons in Post-Quantum Cryptography Migration NISHIKAWA, Akihiro Cloud Solution Architect, Microsoft 

Agenda Act 1: Why migration starts now Act 2: Java platform reality Act 3: Inventory and evidence Act 4: Five migration tracks Act 5: Rollout plan 

Answer first 

Opening: one pilot, five tracks A migration talk, not a mathematics talk. PQC (Post Quantum Cryptography) • Algorithms that run on today's computers, built to resist future quantum attacks 5 tracks • Track T: TLS and HTTPS key exchange • Track S: signed/encrypted objects — JWT, CMS, key wrap • Track C: certificates and PKI • Track K: KeyStores, HSMs, KMS platforms • Track P: partner protocols AS2, AS4 Transport ≠ application-object protection. Track S needs its own evidence. 

Your Monday action One pilot you can start. Five tracks you will not forget. Pick: one real Java service Find: its cryptographic touchpoints Sort: each one into a track Name: owner, control point, behaviour, evidence Choose: one reversible Track T pilot 

Act 1 – Why migration starts now 

Start with public-key decisions Not every algorithm changes. Find every public-key decision point At risk: RSA, Diffie-Hellman, ECDH, ECDSA (public key crypto) • They agree keys, sign messages, prove identity Not the first target: AES, SHA-2, SHA-3, HMAC (Symmetric & hashing) • Review key sizes and policies 

Lead time, not one deadline No single date fits every Java system. • NIST, NSA, UK NCSC: work spans this decade and the 2030s — different scopes, no single date • Your date = system + data lifetime + jurisdiction + regulator • Plan backwards from the date the system must be ready • Month one is discovery, ownership, vendor checks, partner dialogue NIST IR 8547 remains an Initial Public Draft dated 12 November 2024. CNSA 2.0 primarily applies to US National Security Systems. NCSC milestones are UK guidance. 

A customer case: complexity creates lead time cryptographic touchpoints Java versions 3,000+ 4 (7, 8, 11, 17) • Libraries, keys, certificates and integrations sat outside the obvious security module; ownership was fragmented. • No JDK release can find an owner, update a partner agreement, rotate a key, or prove a production path changed. 

Two clocks: confidentiality and authenticity Do not choose. Sequence them. Confidentiality Authenticity • Harvest Now, Decrypt Later • Forged certs, JWTs, receipts • Hybrid TLS 1.3 = clear first pilot • Certificates and signatures migrate this • Rank by secrecy lifetime, not convenience • Own deadlines, own plan How long must data stay secret? How long must identity stay trusted? 

Act 2 – Java platform reality 

Two layers of Java support Not “Does Java support PQC?” — but which surface, which use case, which build? Building blocks • ML-KEM · ML-DSA · KDF: ingredients, not a migration Protocol integration • JEP 527: hybrid TLS 1.3 key exchange in SunJSSE 

JEP 527: one hybrid handshake X25519MLKEM768 • Client offers the hybrid group; server may select it • X25519 material combined with ML-KEM material • Break both, or break nothing: HNDL risk drops for new sessions • HKDF input: ML-KEM first, then X25519 (NIST curves: ECDHE first) • Record protection unchanged: normal TLS 1.3 AEAD 

Hybrid TLS 1.3: X25519MLKEM768 Only what you need to know 🖥 Client 🌐 Server 1. ClientHello offers a hybrid group (e.g. X25519MLKEM768) 2. ServerHello selects the group and returns a hybrid key share 3. Each side derives both shared secrets, then concatenates them: ML-KEM || X25519 4. HKDF takes that one combined input and derives the handshake secret For X25519MLKEM768: K_combined = K_MLKEM ||" K_X25519 Note: The exact order is group-specific. For the NIST-curve hybrid groups, ECDHE comes first. 

Standards and release status RFC 10024 • Three ECDHE-MLKEM groups, Standards Track. No longer a draft. JDK 27 • JEP 527 delivered. GA planned 15 September 2026. Oracle LTS roadmap • JDK 8–25 PQC updates: a plan, not deployed evidence. Release candidate = lab evidence. Re-test on the exact GA or vendor build. 

Hybrid first, fallback visible A default says what the runtime may do. Evidence says what a real route selected. • Hybrid keeps a classical component while adding a post-quantum one • Start from a stable TLS 1.3 baseline; TLS 1.2 is a separate problem • JDK 27 SunJSSE lists X25519MLKEM768 first by default • Keep x25519 as fallback: visible, owned, time-bounded 

Act 3 – Inventory and evidence 

Cryptography is hidden in application systems • Framework defaults, HTTP clients, database drivers • KeyStores, TrustStores, JWT signing • Security sets policy. Platform ships approved providers • Application teams know which change breaks production • Migration is shared work 

Four-layer inventory Make each layer a search you can run before lunch. Build: crypto libraries and TLS implementations Source: crypto calls and algorithm strings Config: KeyStores, TrustStores, TLS settings, endpoints Runtime: evidence from the real route or object Record five fields • track, owner, control point, behaviour, evidence 

Demo beat 1: four-layer inventory 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 

Layer 4 Needs Three Views Capability SSLContext.getDefault().getSupportedSSLParameters().getCipherSuites() or, per sockets: sslSocket.getSupportedSSLParameters().getNamedGroups() Configuration SSLParameters.setNamedGroups(...) -Djdk.tls.namedGroups=... Runtime JFR: jdk.TLSHandshake / jdk.X509Certificate / jdk.SecurityProviderService (since JDK20) Clear named-group proof: JSSE debug (-Djavax.net.debug=ssl:handshake:verbose) or packet capture: Outside the JVM: Edge TLS / Managed crypto / External identity 

No content

Demo result — one small Spring Boot service • One small service: 22 crypto touchpoints. • Most were not obvious from business code. Quantum vulnerable 5 Need review Low risk Total 14 3 22 (in this demo) 

Demo beat 2: deterministic hybrid TLS proof Close the gap: prove the negotiated group. CLIENT SUCCESS PROVES SERVER Hybrid only X25519MLKEM768 Hybrid only TLS 1.3 was selected TLS 1.3 ClientHello offer + ServerHello selection = negotiated proof 

ClientHello ServerHello 

Java 27 Java 28 

Evidence ladder for PQC readiness 1. Capability: the runtime can do it 2. Configuration: the service asks for it 3. Technical proof: the real route or object shows it 4. Business proof: the real client or partner accepts it 5. Operational proof: monitoring, rollback, owner, expiry Level 1 or 2 is preparation, not migration complete 

Crypto-agility makes migration possible policy, not hard-coding • New and old data follow different rules during migration • Encrypt-new, decrypt-old. Sign-new, verify-old • Every exception needs an owner, a reason, and an expiry algorithm names hard-coded in business logic Signature.getInstance("SHA256withRSA"); business code asks for a use case; policy supplies the rest • Algorithm, provider, key alias, validity, rollback • JWT policy: RS256 today, move only when everyone is ready 

Configuration – e.g. application.yml tls: key-exchange-mode: hybrid named-groups: [X25519MLKEM768, x25519] certificates: mode: classical application-signatures: mode: classical Keep four things in configuration: 1. Separate modes by migration track 2. Use standard names and complete transformations 3. Keep TLS named-group order outside code 4. Keep message-protection provider and message-protection: policy outside code cms-smime-mode: classical-baseline provider: BC content-cipher: AES/GCM/NoPadding key-wrap: RSAES-OAEP oaep-digest: SHA-256 oaep-mgf: MGF1 oaep-mgf-digest: SHA-256 oaep-label: empty pqc-pilot-target: ML-KEM-based CMS recipient flow when provider and peers are ready legacy-verify-allowed: true 

Act 4 – Five migration tracks 

Where TLS ends, evidence begins. Track T pilot checklist ❶ Baseline: Start from stable TLS 1.3 ❷ Boundary: Find the real TLS termination point ❸ Evidence: Prove the selected group at that boundary ❹ Signals: Hybrid / Classical fallback / Timeouts ❺ Recovery: Pilot one route / Rehearse rollback Edge termination: edge evidence / JVM termination: JSSE evidence JDK 27: A routine upgrade may introduce a larger hybrid-first ClientHello. Treat the upgrade as a route-level rollout. 

Track S – Signed and encrypted application objects • Not the pipe: the objects the app creates, stores, sends • Signed: sign-new, verify-old-and-new during coexistence • Encrypted: encrypt-new, decrypt-old-and-new • Record creator, consumer, key, and how long old objects live • Done only when the real format works end to end — and rejects bad input 

Track C – Certificates / PKI • In TLS 1.3 the session key comes from the ephemeral exchange • An RSA or ECDSA certificate can still use the hybrid group • Certificates solve a different problem: future impersonation • Plan CA hierarchy, TrustStore, renewal, revocation, pinning, validation 

Track K – Key and secret management Track K is often the blocker. • You cannot convert an RSA key into ML-DSA or ML-KEM • Create new key material alongside the old • Check the real path: key types, provider, rotation, backup, recovery, audit • Certificates, signatures, and partners all depend on keys • An untracked fallback is a downgrade, not a safe mode 

Track P – Partner protocols • Another organisation is involved • Transport may follow Track T — the message layer is separate • Name partner, gateway, security profile, test artefact, fallback, cutover • AS2 and AS4 use different message-security stacks • An HTTPS upgrade alone proves nothing about the message path 

One operating model, five mechanisms The operating model is reusable, not the handshake. • Choose a boundary. Name the owner. Find the control point • Run a small pilot. Collect proof. Keep fallback visible • Define rollback. Monitor exceptions • T is the reference case; S coexists objects; C plans PKI • K coexists keys; P tests bilaterally 

Act 5 – Rollout plan 

Discover in parallel, change in sequence Discover all tracks in parallel. Change one controlled boundary at a time • Track T first: cuts HNDL risk on a route you own • Track K discovery now: keys underpin everything • Track P early: bilateral agreement is slow Dependencies decide the order — not a template. 

Four gates before expansion No gate, no expansion. Scope — route, TLS boundary, owner, cohort Security — hybrid proven, fallback measured Compatibility — real clients finish real work Operability — baseline, limits, rollback A metric without a threshold is not a gate. 

Turn pilot evidence into continuous control Passing the pilot is not the end. • The same evidence controls the next cohort • Keep watching negotiation, fallback, timeouts, key lifecycle • Start-up and CI checks stop the drift back • Every exception: owner, reason, review date, expiry Yesterday's proof is today's control. 

One guardrail for every claim Track. Boundary. Evidence. "Java supports PQC”: which track? "The provider supports it”: which route or object? "The partner is ready”: which profile, which test? A claim without executed proof is preparation, not completion. 

Key takeaways – the Monday test One service. One boundary. This week. • Inventory every public-key decision: track, owner, control point, evidence • Pick one reversible Track T route where capture risk matters • Fix baseline, thresholds and rollback before the pilot starts • In parallel: key-platform discovery, partner conversations Plan five tracks. Change one boundary. Expand only on evidence. 

Sample codes github.com/anishi1222/find-crypto-usages 

Appendix 

Appendix map Question Go to What is final, draft, or release-candidate today? A — Status snapshot Which feature release or Oracle LTS update changes which surface? B — Java release map How large are the hybrid key shares? C — Wire sizes What should we inventory, and what does the demo prove? D — Inventory and demo How can JDK 27 prove the selected group? E — Selected-group proof What claim can we make at each evidence level? F — Evidence ladder What must one migration decision record? G — Decision record What gates a Track T pilot? H — Pilot gates What about resumption and 0-RTT? I — Resumption What does ‘done’ mean for S, C, K, and P? J — Other tracks Where should evidence come from? K — Controlling boundary What should we ask vendors and partners? L — Questions Which claims should we avoid? M — Guardrails Where are the primary sources? N — Sources 

[A] Status snapshot — standards • Everything in this section is dated. Source Status at the review cutoff Use it for Scope guardrail NIST FIPS 203 / 204 / 205 Final standards ML-KEM, ML-DSA, and SLH-DSA Algorithms, not an application migration plan NIST IR 8547 Initial Public Draft, 12 Nov 2024 Proposed transition and deprecation planning Draft guidance; not a universal obligation RFC 9954 Informational, July 2026 Generic hybrid key-exchange construction for TLS 1.3 Does not assign concrete groups RFC 10024 Standards Track, August 2026 Three concrete ECDHE-MLKEM groups for TLS 1.3 A published RFC does not prove product or route support RFC 9881 / 9882 Standards Track, October 2025 ML-DSA identifiers for X.509 and CMS Identifier availability is not interoperability RFC 9935 / 9936 Standards Track, March 2026 ML-KEM identifiers for X.509 and CMS Same product-readiness guardrail RFC 9964 Standards Track, May 2026 ML-DSA in JOSE and COSE Every producer and verifier still needs testing draft-ietf-tls-mldsa-05 Internet-Draft at this cutoff ML-DSA signature schemes in TLS 1.3 Separate from RFC 10024 and X.509 identifiers 

[A] Status snapshot — vendor, policy and IANA groups • For public Web PKI, claim neither universal readiness nor universal impossibility. Verify CA product, profile, chain, TrustStores, clients, TLS stack and route. Source Status at the review cutoff Use it for Scope guardrail Oracle LTS PQC announcement Current Oracle direction PQC across Oracle JDK LTS lines: 25, 21, 17, 11, 8 Directional commitment, not delivery or migration evidence Oracle JRE/JDK Cryptographic Roadmap Updated 3 July 2026; future update-release targets Oracle JDK release-line planning and early testing Plans can move; Oracle-shipped providers only CNSA 2.0 / CNSS Policy 15 Current guidance for systems in scope US National Security System requirements Not a global enterprise deadline UK NCSC 2028 / 2031 / 2035 Current UK guidance Discovery, priority migration, completion planning Apply the relevant jurisdiction and sector rules RFC 10024 → 4587 / 0x11EB SecP256r1MLKEM768 IANA Recommended flag: N Registry property, not a deployment mandate RFC 10024 → 4588 / 0x11EC X25519MLKEM768 IANA Recommended flag: Y Apply policy and validated-module requirements RFC 10024 → 4589 / 0x11ED SecP384r1MLKEM1024 IANA Recommended flag: N Verify the route, not the registry 

[B] Java release map • Production guardrail: use the JDK 27 release candidate for lab evidence only. Repeat every test on the exact supported GA or vendor build. Java release / surface Status at the review cutoff Helps with Does not prove Java 21: KEM API, JEP 452 Final standard API Standard API shape for key encapsulation Built-in ML-KEM or protocol migration Java 24: ML-KEM and MLDSA, JEP 496 / 497 Final Post-quantum KEM and signature primitives JWT, CMS, JAR, HSM, or partner interoperability Java 24: KDF API, JEP 478 Preview in Java 24 Standard key-derivation API shape A stable production API contract in Java 24 Java 25: KDF API, JEP 510 Final; finalises the Java 24 preview Standard key derivation, including HKDF Protocol choice or rollout boundary JDK 27: JEP 527 Delivered; build 34 is an RC/EA build; GA planned 15 Sep 2026 Hybrid TLS 1.3 key exchange Certificates, objects, keys, in OpenJDK SunJSSE partners, or a supported runtime before GA JDK 28: JFR namedGroup EA; from build b03 via JDK8301626; no JDK 27 backport Named-group field in completed jdk.TLSHandshake events JDK 27 evidence, failed attempts, or resumption lineage 

[B] Oracle JDK LTS update roadmap • PBMAC1 is KeyStore modernisation, not a PQC algorithm. Default capability is still not proof of selection on a real TLS leg. Target date Oracle JDK line Planned addition 20 October 2026 25 Post-Quantum Hybrid Key Exchange for TLS 1.3; PKCS12 PBMAC1 support 20 October 2026 21, 17 ML-KEM and ML-DSA First half of 2027 21, 17 Post-Quantum Hybrid Key Exchange for TLS 1.3; PKCS12 PBMAC1 support Second half of 2027 11, 8 ML-KEM, ML-DSA, Post-Quantum Hybrid Key Exchange for TLS 1.3, PKCS12 PBMAC1 Second half of 2027 8 X25519 and X448 key agreement 

[C] Wire sizes • A complete ClientHello is commonly around 1.5 kB and may span multiple TCP segments. Measure the real route. Item Size Meaning ML-KEM-768 encapsulation key 1,184 bytes Client-side ML-KEM public material X25519 ephemeral share 32 bytes Classical component X25519MLKEM768 client key_exchange 1,216 bytes 1,184 + 32 Separate classical x25519 client share 32 bytes Also sent by the default JDK 27 client Two default JDK 27 client payloads 1,248 bytes Payloads only, not the full ClientHello X25519MLKEM768 server key_exchange 1,120 bytes ML-KEM ciphertext 1,088 + X25519 32 SecP256r1MLKEM768 Client 1,249; server 1,153 Implemented, not in the JDK 27 default list SecP384r1MLKEM1024 Client and server 1,665 Implemented, not in the JDK 27 default list 

[D] Four-layer inventory: checks and records • A match is a candidate, not proof of production use. No match is not proof of absence. Layer Representative checks Record Build Security frameworks, JSSE/JCE providers, database and broker drivers, KMS SDKs, JOSE/CMS/XML libraries, native TLS bindings Dependency, version, owner, expected use Source KEM, KeyAgreement, Signature, Cipher, KeyStore, SSLContext, SSLEngine, SSLParameters, and framework APIs Call path, format, algorithm, key source, track Configuration KeyStores, certificates, named groups, protocol pins, algorithm constraints, partner endpoints, database TLS Control point, requested behaviour, owner, expiry Runtime Effective parameters, real handshakes, serialised objects, certificates, and audit events Boundary, peer or consumer, observed behaviour, proof source 

[D] crypto-audit-demo: evidence boundaries • This is a discovery demo, not a production reference architecture. Track / touchpoint What the demo proves What it does not prove T: local inbound HTTPS The Spring Boot service starts over HTTPS and completes a request The selected group on a real route T: PostgreSQL TLS Configuration discovery finds database TLS settings; the profile excludes the DataSource A live connection, effective sslmode, identity checks, or selected group S: JWT/JWS Nimbus issues and verifies RS256 tokens A post-quantum format or every-verifier interoperability S: CMS SignedData Payload and signature integrity using the embedded certificate That the signer is an authorised licence issuer S/K: Tink AEAD and HMAC Local AES-256-GCM and HMAC round trips Durable key storage, rotation, recovery, or multiinstance operation C/K: PKCS12 An RSA key, RSA-signed chain, and shared key entry are discoverable Production PKI, purpose-separated keys, HSM/KMS, renewal, or revocation P: partner protocol No path exists; the absence is recorded AS2, AS4, S/MIME, or a bilateral test 

[E] Selected-group proof — server and client • Terminal A — server permits only the hybrid group cd 01-PQC/demo/PQC-enabled-SpringBoot-App mvn clean package # Set the keystore variables from the README first. export APP_TLS_NAMED_GROUPS="X25519MLKEM768" java -jar target/pqchybridtls-0.0.1-SNAPSHOT.jar --spring.profiles.active=tls • Terminal B — client with a restricted debug sink • NOTE: --trust-all is for this local self-signed laptop demo only. Any real pilot uses an approved TrustStore with hostname and certificate validation. install -d -m 700 logs && umask 077 java -Djavax.net.debug=ssl:handshake -cp target/classes \ dev.logicojp.example.pqchybridtls.client.HybridTlsClient \ --url 'https://localhost:8443/api/hello?name=JCConf' \ --named-group X25519MLKEM768 --trust-all 2>logs/jsse-client.log 

[E] Show the offer, selection and artefact • Terminal C — filter the restricted debug log cd 01-PQC/demo/PQC-enabled-SpringBoot-App rg -i 'supported_groups|key_share|x25519mlkem768' logs/jsse-client.log • Evidence hygiene • NOTE: At another boundary, use that product's selected-group log or an approved handshake-only capture. Never use evidence from one TLS leg to describe another. Keep the ClientHello offer and the ServerHello selection together. An offer alone is not proof of final selection. Treat the debug file as sensitive operational evidence: approval, restricted access, minimal capture window, retention, verified deletion. Debug field names change between builds - retain the raw artefact and the full java -version. 

[F] Five-level evidence ladder • For TLS, a JDK default or jdk.tls.namedGroups is Level 2. The selected group on the real leg is Level 3. Level Question Minimum proof Claim allowed 1: Capability Can this exact build support the algorithm or group? Release notes, provider documentation, local capability check Capability only 2: Configuration Is it requested and permitted at this boundary? Effective group list, protocol, provider, and algorithm constraints Configuration intent 3: Technical proof What did the real route, object, ServerHello selection, serialised or key operation do? identifiers, sign/verify result, or executed key operation Confirmed technical behaviour 4: Business proof Did the real workflow and consumer accept it? Critical-path end-to-end test Business-path compatibility 5: Operational proof Can the team observe, pause, reverse, and retire it? Coverage, thresholds, owner, rollback exercise, exception expiry One bounded production decision 

[G] Minimum migration decision record • Blank is not N/A. Minimum row: record_id, track, boundary, technical_owner, risk_owner, control_point, current_behaviour, target_behaviour, evidence. Section Required fields Identity and scope Record ID, track, boundary or object, environment, route or consumer Ownership Technical owner, risk owner, control point, approval authority Risk and target Purpose, data sensitivity, confidentiality/authenticity lifetime, current state, target state, deadline Implementation Exact product, JDK, provider, build, key type, format, peer versions, and effective policy Evidence Positive and negative artefacts, source boundary, population or sample, timestamp, result, reviewer Gates Comparable baseline, approved threshold per metric, workflow pass definition Recovery Pause and rollback triggers, authority, procedure, measured time, recovery validation Closure Legacy retirement evidence, or a time-bounded exception with owner, reason, review date, expiry 

[H] Track T pilot gates — entry criteria • Identify the implementation that terminates each TLS leg • Limit the pilot to a named route and reversible cohort • Record the exact JDK/provider or product build and effective group, protocol and constraint settings • Choose the selected-group evidence source at the controlling boundary • Define the handshake-attempt population — JDK 27 jdk.TLSHandshake records only completed handshakes • Capture a comparable classical baseline: same boundary, window and failure definition • Approve thresholds, pause authority, rollback authority and maximum pause duration • Rehearse rollback and measure it, including restart and connection drain 

[H] Track T pilot gates — gate table • An empty denominator is never 0% and never a pass. Insufficient evidence pauses expansion. Gate Example signal Pass condition Security outcome Hybrid selection coverage; classical-fallback share; any prohibited group or protocol Meets approved target; no prohibited outcome Evidence quality Selected-group evidence coverage; missing or conflicting records Meets approved minimum Compatibility Real client and critical workflow result Passes positive and required negative tests Reliability Handshake-failure rate, including timeouts with no TLS alert Within approved change from comparable baseline Performance p95/p99 handshake latency, CPU, memory Within approved deltas Operability Alert routing, owner, rollback, recovery check Exercised and within service allowance 

[I] Resumption and 0-RTT Do not infer that every session is hybrid from one new full handshake. • A new full handshake is protected by its selected group • Resumed 1-RTT data: a fresh hybrid exchange in psk_dhe_ke, or hybrid lineage from the issuing session • psk_ke has no fresh key exchange and depends on PSK lineage • 0-RTT early data is protected by the offered PSK — a later hybrid exchange does not fix those bytes • JDK 27 SunJSSE offers psk_dhe_ke, not psk_ke, and does not implement 0-RTT • JDK 27 exposes neither PSK identity nor lineage through a public API 

[J] Track S, C, K and P checklists • A published identifier, vendor roadmap or signed agreement is preparation. Executed evidence is proof. Track Transition rule Done means Minimum evidence S: signed objects Sign-new; verify-old-andnew during approved coexistence Every producer and verifier accepts the target; prohibited signers, keys and formats fail; legacy production stops Producer/consumer matrix, positive and negative object tests, retirement record S: encrypted Encrypt-new; decrypt-oldobjects and-new during approved coexistence New objects work; retained old objects readable only within policy; wrong recipient/key and prohibited formats fail Round trips, retained-object test, negative tests, retention decision C: Introduce and distribute the Expected identities and purposes validate; certificates / target trust path alongside expired, revoked, wrong-identity and PKI the old where supported wrong-purpose credentials fail Chain, identity, lifecycle, pinning and rollback tests K: keys / secrets Create new key material; don't convert an old RSA key Generation, activation, rotation, recovery, failover, coexistence, access, audit, destruction and rollback pass Exact provider/HSM/KMS lifecycle and negative-path tests P: partner protocols Agree transport and message profiles before production change Both organisations pass the target profile; legacy works only during the approved window Bilateral artefacts, versioned profile, sign-off, runbook 

[K] Evidence follows the controlling boundary • Identify which implementation terminates the leg before choosing the control or evidence source. Boundary Continuous signal Focused proof CDN, gateway, reverse proxy, load balancer Product selected-group, attempt, fallback and failure metrics where available Product log or approved sampled capture JVM on JDK 27 SunJSSE Protocol/cipher baseline and service metrics; JFR has no named group or failed-attempt count Time-boxed JSSE debug or approved capture JVM on JDK 28 EA JFR namedGroup for completed handshakes in lab evidence Debug or capture where offer path, failure or lineage matters In-process native or thirdparty TLS stack That stack's own configuration, logs and metrics That stack's handshake log or capture JVM as TLS client to database, Client-side service metrics; the peer controls broker or partner API selection Client-side debug or capture plus peer evidence Service mesh, database or broker Per-leg platform metrics Per-leg log, real connection, identity check, failover test Partner message layer Profile validation and business-flow metrics Object identifiers, validation result and profile receipt 

[L] Questions — transport and platform • Which exact named groups, TLS versions, provider modes and validated configurations does this version support? • Is support enabled by default, or by which explicit control? • Which implementation terminates each primary and failover leg? • Which fields expose ClientHello offers, HelloRetryRequest, final selected group, resumption mode, outcome and failure? • What is the handshake-attempt counter and its scope? • How are policy rollback, connection drain, ticket invalidation and recovery tested? • Which peer stacks and versions have passed interoperability and negative tests? 

[L] Questions — trust, formats, keys, partners • Which certificate algorithms and profiles can the CA issue, and which clients accept them? • Which HSM/KMS parameter sets, operations, providers, firmware, recovery, failover, access controls and audit paths are supported? • Which RFC identifiers do JOSE, CMS, XML and certificate tools implement, from which version? • Which producers, consumers, retained objects and partner profiles have passed positive and negative tests? • What coexistence window, fallback, rollback, retirement date and authorised sign-off apply? • Never accept "PQC supported" without a dated version, boundary, algorithm or format, evidence source, owner, rollback path and expiry 

[M] Guardrails — platform and configuration Claim to avoid Better claim Evidence question Java supports PQC, so the application Java supplies building blocks, and JEP is ready. 527 gives OpenJDK SunJSSE a Track T path. Which track and bounded decision passed? JEP 527 migrates the application. JEP 527 changes TLS 1.3 key exchange in SunJSSE. What about objects, certificates, keys and partners? We enabled the hybrid group, so the route is quantum-safe. Configuration is intent; new, resumed and early-data paths need the right evidence. What did the real leg select, and what was the coverage? The provider or CA supports the algorithm. Support is preparation. Did the real route, key lifecycle, object or trust path pass? Oracle's roadmap lists our JDK line, so we are ready. A roadmap row is a vendor target; confirm delivery, provider and boundary. Which update shipped, and which evidence level passed? 

[M] Guardrails — certificates, partners, telemetry • Narrow the claim. Name the boundary. Ask for evidence. Claim to avoid Better claim Evidence question Hybrid TLS means the certificate is post-quantum. Key exchange and certificate authentication are separate tracks. What chain and identity evidence exists? The partner path is ready because HTTPS is ready. Transport and message profiles need separate bilateral proof. Which profile, version, artefact and rollback plan passed? JFR shows no failures, so the rollout is healthy. JDK 27 JFR records only completed handshakes and no named group. What counted attempts, failures and selected groups? One hybrid handshake proves production readiness. One handshake proves a path; production needs coverage, workflow, thresholds and rollback. Which Level 4 and Level 5 evidence passed? 

[N] Sources — standards and guidance • NIST FIPS 203: ML-KEM • NIST FIPS 204: ML-DSA • NIST FIPS 205: SLH-DSA • NIST IR 8547: Transition to Post-Quantum Cryptography Standards, Initial Public Draft • NSA Post-Quantum Cybersecurity Resources • UK NCSC: Timelines for migration to post-quantum cryptography • RFC 9954: Hybrid Key Exchange in TLS 1.3 • RFC 10024: Post-Quantum Traditional Hybrid Key Agreement Mechanisms for TLS 1.3 • IANA TLS Supported Groups registry • RFC 9881, RFC 9882, RFC 9935, RFC 9936, and RFC 9964 • draft-ietf-tls-mldsa 

[N] Sources — Oracle and OpenJDK • Post-Quantum Cryptography in Long-Term Support JDK Releases • Oracle JRE and JDK Cryptographic Roadmap • Configure Oracle's JDK and JRE Cryptographic Algorithms • JEP 452: Key Encapsulation Mechanism API • JEP 478: Key Derivation Function API (Preview) • JEP 496: ML-KEM • JEP 497: ML-DSA • JEP 510: Key Derivation Function API • JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3 • JDK 27 project and schedule • JDK 27 early-access builds • JDK-8301626: Capture Named Group information in TLSHandshakeEvent 

Thank you!