Guide
Post-Quantum Cryptography: What Network Engineers Need to Know
The algorithms taking over the work RSA and elliptic curves do today are already standardized — what changes for a network engineer is the handshake, the byte counts, and the migration order.
Post-quantum cryptography is no longer a research topic a network engineer can defer. The replacement algorithms are published as final NIST standards, the protocol machinery that carries them exists, and the earliest deployment step — hybrid key exchange — is already running at internet scale. What an engineer needs is not the lattice mathematics but the operational shape: what breaks, what replaces it, and in what order the replacement happens.
What Breaks and What Survives
A cryptographically relevant quantum computer running Shor’s algorithm solves the mathematical problems under the public-key cryptography that establishes keys and authenticates peers in deployed TLS and IPsec: the integer factoring behind RSA and the discrete logarithms behind finite-field and elliptic-curve Diffie-Hellman. That covers the exchanges keying most deployed TLS and IKEv2 sessions and the signatures in their certificates, in one stroke. Symmetric cryptography survives. Grover’s algorithm roughly halves the effective strength of a symmetric key, and AES-256 absorbs that with margin to spare. SHA-2 and SHA-3 at modern output lengths likewise remain fit for use. The migration therefore targets a specific layer: the public-key handshake that produces symmetric keys and proves who you negotiated them with. The bulk encryption on either side of that handshake stays.
Why it cannot wait for the hardware is a capture problem. A session keyed only by a quantum-vulnerable exchange and recorded today opens the day that exchange can be solved, so data with a secrecy lifetime measured in years is already exposed — harvest now, decrypt later walks through that timing in full.
The First Standards Are Final
NIST has published its first final post-quantum FIPS standards: ML-KEM (FIPS 203) for key establishment, and ML-DSA (FIPS 204) plus SLH-DSA (FIPS 205) for digital signatures. The portfolio is still growing at the edges — NIST has selected HQC as a backup KEM built on different mathematics — but near-term migration planning centers on the three published FIPS. A separate, earlier NIST recommendation approves stateful hash-based signatures — LMS and XMSS, in SP 800-208 — for constrained uses where signing state can be managed safely, with firmware and code signing the canonical case: a signature made today must still verify on a device a decade from now. For an engineer, the core selections are settled enough to plan against: the named algorithms are what protocols, certificates, and hardware roadmaps are converging on.
What Actually Changes in the Handshake
ML-KEM is not a drop-in Diffie-Hellman. It is a key encapsulation mechanism: one peer generates a keypair, the other encapsulates a fresh secret against that public key and sends back a ciphertext, and both derive the same shared secret. The result is familiar — a shared secret no passive observer can compute, with authentication still supplied by the surrounding protocol — but the primitive’s roles, encodings, and byte counts differ, which is why each protocol needed defined integration rules — TLS 1.3 carries KEM material in its existing handshake flights — rather than a silent cipher swap.
The sizes change more than the flow. ML-KEM public keys and ciphertexts run near a kilobyte each, where the elliptic-curve exchanges they augment use tens of bytes; ML-DSA signatures are kilobytes where ECDSA signatures are not. Handshake packets grow, fragmentation becomes a real design consideration for UDP-carried exchanges like IKE, and certificate chains get heavier when post-quantum signatures eventually land in them. None of this has stopped deployment at internet scale, but MTU limits, fragmentation support, and middlebox behavior are exactly the kind of thing a network engineer, rather than a cryptographer, ends up debugging.
Hybrid Is the Transitional Pattern
The transition does not begin by ripping out the classical exchange. The common transitional pattern — prevailing in TLS deployment today — is hybrid: run a classical curve and a post-quantum KEM in the same handshake and combine both secrets into the key schedule, so that a correctly combined session keeps its confidentiality as long as either exchange holds. RFC 9370 standardizes the multiple-key-exchange framework in IKEv2 within which such combinations run; TLS 1.3 hybrid groups pairing a classical curve with ML-KEM are deployed at internet scale while their defining documents complete standardization. Hybrid buys the post-quantum confidentiality protection without betting recorded traffic on algorithms young enough that cryptanalytic confidence is still accumulating — the handshake’s authentication stays classical until signatures migrate on their own track. Quantum-safe VPNs covers how this lands in tunnel configuration.
The Order of the Migration
Sequence follows exposure. For data in transit, key exchange takes priority, because confidentiality is retroactively at risk from recorded traffic while a completed handshake’s authentication cannot be retroactively forged — a future forgery cannot rewrite a verification that already happened. Signatures migrate on the clock of their own verification lifetime: firmware and code signing are the usual leaders, because those signatures will be verified far in the future by long-lived devices, and transport authentication must still be done before a capable machine exists, since live sessions could then be impersonated. Before any of it comes inventory — finding every place public-key cryptography protects data in motion and ranking those flows by how long their contents must stay secret.
This is blueprint material now: the SCOR 350-701 exam topics name post-quantum cryptography alongside PKI, TLS, and IPsec in the cryptography objective. The engineers who understand today’s handshake are the ones who will migrate it without drama — start with the free lesson.
Frequently Asked Questions
Is post-quantum cryptography something I need to act on before quantum computers exist?
Yes, for one class of data: anything encrypted today that must stay secret for years. Recorded ciphertext can be decrypted when a capable machine arrives, so the exposure begins at capture time, not at decryption time. Key exchange protecting long-lived secrets is the part of the stack with a deadline that does not wait for the hardware.
Do I have to replace AES?
Not wholesale. Grover's algorithm reduces the effective strength of a symmetric key by roughly half in the idealized model, and AES-256 retains a comfortable margin against that — which is why policy frameworks that set a quantum bar, such as CNSA 2.0, specify AES-256. An AES-128 deployment is worth evaluating against the security level and policy that apply to it. The post-quantum migration otherwise targets the public-key layer — key exchange and signatures — not the bulk cipher itself.
What is the difference between ML-KEM and ML-DSA?
They solve different problems. ML-KEM (FIPS 203) establishes a shared secret between two parties — the job Diffie-Hellman does in today's handshakes. ML-DSA (FIPS 204) signs and verifies — the job RSA and ECDSA signatures do in certificates and handshake authentication. A migrated session needs the first for confidentiality; where its authentication rests on certificates or other public-key signatures, that layer eventually needs a post-quantum answer too — ML-DSA is the primary standardized option, with SLH-DSA the conservative alternative, and preshared-key authentication sits outside the problem entirely.