Post-quantum: the half you can fix today

Post-quantum cryptography discussions tend to collapse into a single question — "when do we have to migrate?" — and then stall, because the honest answer for certificates is "not yet, and not on your schedule".

That answer is right for signatures. It is wrong for key exchange, and the difference is the most actionable thing in this whole subject.

Two different threats on two different clocks

Key exchange is a harvest-now-decrypt-later problem. Traffic captured today, encrypted with a classical key agreement, can be stored indefinitely and decrypted the day a cryptographically relevant quantum computer exists. The damage is done at capture time. Nothing you do in 2032 protects a session recorded in 2026.

Signatures are a planning problem. A certificate signed classically is only forgeable once the machine exists — and by then you will have rotated it several times over, because maximum TLS validity is collapsing toward 47 days anyway. The exposure is real but it is in the future, and it is bounded by certificate lifetime.

One of those is urgent and fixable. The other is neither.

The fixable half has already shipped

Hybrid post-quantum key exchange is not a research topic. It is in your TLS stack now. Go 1.26's crypto/tls carries X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024. Chrome and Firefox negotiate hybrid groups by default. Cloudflare has served them for years.

Hybrid matters: these combine a classical exchange with ML-KEM so that the result is at least as strong as the classical one. If ML-KEM turns out to have a weakness, you have lost nothing. That property is why this could be deployed early — it is not a bet.

Meanwhile signatures genuinely are not ready. crypto/mldsa does not exist in the Go standard library, crypto/x509 cannot build or parse an ML-DSA certificate, and issuing one means hand-rolling ASN.1 plus a third-party implementation for a certificate that almost nothing will verify. Waiting is the correct engineering decision there.

What to do this quarter

Measure first. You can already answer "which of our endpoints negotiate a post-quantum group?" — it is one field in a TLS handshake you are probably already performing during discovery scans. "Three of six scanned endpoints do not negotiate a post-quantum group" is a finding about your estate that needs no new standard, no new certificate, and nothing from a CA.

openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/null 2>&1 \
  | grep -i "negotiated group"

Then turn it on where you control both ends. Internal mTLS, service mesh traffic, anything between your own services — there is no compatibility argument to have with yourself, and that traffic is often the longest-lived and most sensitive you have.

Then keep certificate agility. The thing that will make the eventual signature migration survivable is not picking an algorithm early. It is being able to reissue your entire estate quickly and without drama — which, if validity is heading to 47 days, you need regardless.

The uncomfortable part

A cryptographic bill of materials that covers certificates and observed TLS is worth having, and it is also not complete. Keys at rest, the algorithms inside applications, and anything you have never observed are outside it — and that is most of an organisation's cryptography. A CBOM should be read as "what we can see", not "what exists". Reporting it as the latter is how you end up confident and wrong.