The post-quantum key exchange already happened. You didn't notice. Good.

NIST published FIPS 203 — the Module-Lattice-Based Key-Encapsulation Mechanism standard, formerly known as CRYSTALS-Kyber — in August 2024. Two years later, the post-quantum cryptography transition is partially complete and partially a looming mess, and the part that’s done went so smoothly most people missed it entirely.

The part that worked

SSH key exchange negotiates a shared secret over an untrusted channel. The threat model for “harvest now, decrypt later” attacks targets exactly this layer: an adversary records your encrypted SSH sessions today, stores the ciphertexts, and waits until a sufficiently capable quantum computer exists to break the classical key exchange. At that point every session they’ve archived becomes retroactively readable.

The correct defense is a hybrid: combine a classical algorithm (X25519) with a post-quantum algorithm (ML-KEM) such that breaking either one alone is insufficient. The adversary needs to break both simultaneously to get the session key. When the quantum computer arrives, the ML-KEM layer holds. If ML-KEM turns out to have a flaw nobody found in the fifteen-year standardization process, the X25519 layer still holds. Belt and suspenders.

OpenSSH has been shipping hybrid KEX since 9.0, using sntrup761x25519-sha512 — NTRU Prime blended with X25519. OpenSSH 9.9 added mlkem768x25519-sha256, the NIST-standardized Kyber variant, to the default KEX negotiation list. If both ends of a connection run 9.9 or later, they’re using it without anyone touching a config file. Verify it:

ssh -vv yourhost 2>&1 | grep 'kex:'

kex: mlkem768x25519-sha256 — you’re there. kex: curve25519-sha256 — one end is behind and should be updated. The OpenSSH legacy algorithm cuts happened alongside this addition; the project was simultaneously dropping old cruft and adding new capability, which is the correct way to do a cryptographic migration.

The whole key exchange transition was operationally invisible on systems that stayed current. No certificates to reissue. No configuration to migrate. The negotiation just negotiated better on the next connection. This is how you do it.

The part that’s going to hurt

TLS certificates are not key exchange. Your HTTPS certificate is a signature over your public key, made by a CA, verified by every browser and TLS client that hits your server. Changing the signature algorithm means reissuing every certificate in existence, retraining every validation path in every trust store, shipping updated root CAs to every device, and dealing with the fact that post-quantum signatures are large in a way that matters at scale.

Concretely: an ECDSA P-256 signature is roughly 64 bytes. An ML-DSA-65 signature — NIST FIPS 204, medium security level, the one that maps closest to P-256 for bit-strength equivalence — is 3,309 bytes. The ML-DSA-65 public key is 1,952 bytes versus 64 bytes for P-256. A three-cert TLS chain carrying ML-DSA at every level adds roughly 15 KB to every handshake compared to the classical version.

Over a gigabit LAN connection this is noise you’ll never notice. Over a mobile connection in a part of the world with real latency and packet loss, it’s not noise. TLS 1.3 reduced round trips significantly but you can’t round-trip your way out of certificate payload size. QUIC helps. It doesn’t help enough.

The CA/Browser Forum has been working through hybrid certificate profiles — a certificate that carries both a classical ECDSA signature and an ML-DSA signature, valid to both classical and quantum-resistant validators. Hybrid is the right approach for the transition period: the same belt-and-suspenders logic as hybrid KEX. A hybrid chain is also approximately 25–30 KB, which is not nothing.

Certificate lifetimes are already collapsing toward 90-day cycles, which means whatever automation infrastructure is handling your cert reissuance now has to handle PQC-sized payloads at higher frequency. The operational complexity stacks.

Where the implementations are

LibreSSL — which ships in OpenBSD base — has taken its characteristic approach: correct first, pressure from the vendor ecosystem second. Post-quantum KEX support is present. The certificate and signing story is being worked through at the pace that produces correct implementations rather than the pace that produces press releases. If you’ve been watching OpenSSL ship half-baked features under marketing pressure for the last decade, you recognize the difference.

OpenSSL 3.5 added ML-KEM and ML-DSA. The implementation is there; the question is whether the certificate tooling, the CA issuance pipelines, and the validation paths in software that isn’t actively maintained catch up at the same rate. The answer historically is: no, not at the same rate, not even close.

Go’s crypto/tls and the Rust rustls crate are both tracking the NIST standards. Browser vendors are running trials. The openssl s_client workflow for verifying PQC TLS works the same way as everything else once the server is actually issuing PQC certs — which most aren’t yet.

The harvest-now concern is real; the timeline is not

Intelligence services collecting encrypted traffic under the assumption that a useful quantum computer eventually exists — that’s not paranoid speculation, it’s documented. The question is the timeline. Academic consensus on cryptographically relevant quantum computers (capable of breaking RSA-2048 or ECDSA P-256 at useful speed) currently runs somewhere between 10 and 25 years, with significant uncertainty in both directions and some serious researchers saying the engineering obstacles are underestimated.

For key exchange: solve it now. The session data generated today has a 25-year adversarial window, the hybrid approach costs essentially nothing operationally, and OpenSSH has already done the work. If you’re not on 9.9+, update and verify.

For certificates: the urgency is meaningfully lower. A certificate signed today with ECDSA expires in 90 days. When a quantum computer that threatens P-256 actually exists, you reissue the cert that week. The operational migration is real and will be painful, but it is not an emergency that justifies shipping underspecified hybrid certificate profiles before the tooling is solid.

The vendors currently selling post-quantum-everything as a critical 2026 priority are not wrong about the direction. They are, at minimum, simplifying the timeline. Their urgency is not entirely disconnected from the fact that they have products to sell. The OpenBSD and OpenSSH teams, who have no products to sell, shipped the key exchange fix quietly and correctly and moved on.

Update your OpenSSH. Run the grep. If you see mlkem768x25519-sha256, you’re done with the part that needed doing now. The certificate fight will find you when it’s ready. It’s not ready yet.