Resources Post-quantum · July 2026

Post-quantum readiness for TLS is mostly inventory work

Post-quantum cryptography is no longer only research, but TLS migration is not a single certificate replacement project. For most infrastructure teams, the useful work today is knowing where quantum-vulnerable public-key cryptography is used, who owns it, and which systems can change without breaking clients.

What is actually standardized

NIST finalized the first three post-quantum cryptography standards in August 2024. The names matter because they describe different jobs. ML-KEM is for key establishment. ML-DSA and SLH-DSA are for digital signatures. They are not interchangeable.

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.

For European buyers, this is increasingly a governance and planning topic too. The EU coordinated roadmap frames PQC as a transition that should be planned across Member States and stakeholders, not as an isolated product switch.

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.

TLS has two separate migration surfaces

TLS teams should separate key establishment from certificate authentication. Mixing them together is the fastest way to produce a readiness plan that sounds good but cannot be executed.

Key establishment

This is the part of the TLS handshake that creates session secrets. The hybrid ECDHE-MLKEM path is further along in the IETF than standalone ML-KEM named groups, but both still 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.

The real risk is not the same for every system

The strongest near-term argument for PQC planning 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 do not have the same secrecy lifetime. Treating all TLS endpoints as equally urgent is not a risk model; it is a queue nobody can prioritize.

Certificate-signature migration is 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 professional 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

  • Panic-buying a product because it says 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 and does not make an endpoint post-quantum by itself. Its Business and Custom Compliance workspaces have a narrower and more useful role: keep certificate and TLS posture visible across public and internal observations, including certificate algorithms, TLS policy findings, and timestamped evidence.

That makes post-quantum readiness trackable as part of normal TLS operations instead of a separate spreadsheet. The output should be a list of systems, owners, vendors, algorithms, and migration constraints, not a generic "quantum-safe" badge.

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.