Resources

Preparing TLS for post-quantum cryptography: what to inventory

To prepare a TLS migration to post-quantum cryptography, identify where quantum-vulnerable public-key algorithms are used. Record who manages those systems and which changes their clients can support. Replacing certificates is only part of the work.

Published standards

NIST finalized three post-quantum cryptography standards in August 2024: ML-KEM for key establishment, and ML-DSA and SLH-DSA for digital signatures. These algorithms serve different purposes.

The concern is mostly asymmetric cryptography: RSA, DSA, ECDSA, EdDSA, finite-field DH, and ECDH. Symmetric encryption and hash functions are not affected in the same way, so a TLS readiness plan should not describe every cipher or hash as equally broken.

The EU coordinated roadmap calls for Member States and the organizations involved to plan the transition to PQC together. European buyers can use it to inform their migration planning.

Algorithm Standard Role Operational note
ML-KEM FIPS 203 Key establishment The algorithm family most directly relevant to TLS key exchange work.
ML-DSA FIPS 204 Digital signatures Relevant to future certificate and software-signing paths.
SLH-DSA FIPS 205 Digital signatures A hash-based signature standard intended to provide algorithm diversity.

Key establishment and certificate authentication

Plan key establishment and certificate authentication separately: they use different algorithms and have different compatibility requirements.

Establish session keys

ClientServer

Protect the exchanged data

ECDHE · ML-KEM

Authenticate the server

ClientServer

Check its identity using certificates and signatures

X.509 · CertificateVerify
Post-quantum key establishment does not make the certificate chain post-quantum. These are two separate migration tracks.
Protocol details and support

Key establishment

This is the part of the TLS handshake that creates session secrets. Hybrid ECDHE-MLKEM key agreement is published in RFC 10024; standalone ML-KEM named groups remain a draft. Both depend on client, server, library, and policy support.

Certificate authentication

This is the X.509 certificate chain used to authenticate the server. RFCs exist for ML-DSA, SLH-DSA, and ML-KEM identifiers in X.509, but that is not the same thing as production support for publicly trusted TLS server certificates.

Prioritize by how long data must remain confidential

A key near-term reason to plan for PQC is "harvest now, decrypt later": an attacker can record encrypted traffic today and try to decrypt it later if a cryptographically relevant quantum computer becomes available. That risk is most important where the data must remain confidential for years.

A marketing website, an internal admin panel, a payroll portal, and a customer data export endpoint have different confidentiality requirements. Use those requirements to prioritize their migration.

Certificate-signature migration addresses a different risk. It is about future authentication, chains of trust, root-program policy, Certificate Transparency behavior, and client compatibility. It does not decrypt traffic that was already recorded.

What teams can do now

  • Inventory where RSA, ECDSA, EdDSA, finite-field DH, and ECDH appear in certificates, TLS endpoints, appliances, load balancers, VPNs, and managed services.
  • Record which systems terminate TLS, which certificates they present, which teams own them, and which vendors control the cryptographic stack.
  • Classify data by confidentiality lifetime. Long-lived confidential data changes the priority; short-lived public web sessions usually do not.
  • Ask vendors for specific support dates and names: ML-KEM rather than pre-standard Kyber, ML-DSA, SLH-DSA, hybrid TLS, CAVP algorithm validation, FIPS 140-3 module validation where required, and downgrade or fallback behavior.
  • Test hybrid TLS only where the client population is known and rollback is easy. Measure latency, handshake size, middlebox behavior, and observability.
  • Avoid treating certificate re-issuance as the migration plan. Public certificate policy and client compatibility still matter.

What not to do

  • Buying a product solely because it claims to be quantum-safe.
  • Replacing every public certificate before your browsers, CAs, and clients support the relevant algorithms.
  • Assuming a PQC key exchange also gives you PQC certificate signatures.
  • Using PQC and quantum key distribution as if they were the same migration project.
  • Ignoring existing certificate ownership, renewal, and TLS hygiene because PQC sounds more strategic.

Where Nocert fits

Nocert does not issue certificates or migrate endpoints to post-quantum cryptography. Business and Custom Compliance workspaces show certificate algorithms, TLS policy findings, and timestamped evidence from public and internal observations.

Use these observations when planning your migration. For each system, record its owner, vendor, algorithms, and compatibility constraints.

Primary sources

This note is based on NIST PQC standards and migration guidance, IETF TLS and X.509 work, the CA/Browser Forum Baseline Requirements, and the EU coordinated PQC roadmap.