Operationalizing PQC: An Engineer's Migration Playbook

By Taylor Thomas · 2026-08-30

The hard part of post-quantum cryptography is no longer the cryptography. NIST’s first core standards are final — ML-KEM (FIPS 203) for key establishment, ML-DSA and SLH-DSA (FIPS 204 and 205) for signatures — and the protocol machinery that carries them is standardized or completing standardization. What remains is a migration: finding every place public-key cryptography does work in your network, deciding what moves first, and shipping the change without breaking tunnels that carry production traffic. That is an engineering program, and it succeeds or fails on sequence.

Inventory Before Algorithms

You cannot migrate what you have not enumerated. The first deliverable is a cryptographic inventory answering three questions for every flow and system: what algorithms protect it today, what its platform can be configured to run, and how long the data it carries must stay secret. For key-establishment flows, the last column is the leading priority signal — alongside migration lead time, system criticality, and dependencies. Harvest now, decrypt later is the reason the migration cannot wait for a quantum computer to exist: a session keyed by quantum-vulnerable public-key exchange and recorded today becomes solvable once a sufficiently capable machine exists, so the flows carrying decade-scale secrets — legal, health, design, government traffic — migrate first, while flows whose data goes stale in days carry far less harvest-now-decrypt-later urgency.

The inventory reaches further than tunnels. TLS terminators, IKEv2 peers, management-plane SSH, the PKI issuing certificates, and the pipeline signing firmware and software images all belong on the list, because each migrates on a different mechanism and a different clock.

Hybrid Key Exchange Is the Deployment Pattern

Data in transit migrates by hybrid: run a classical exchange and an ML-KEM exchange in the same handshake and derive session keys from both secrets. Correctly combined — through the protocol’s own key-schedule binding, with independent secrets and sound implementations — a recorded session resists passive capture while at least one component remains unbroken — the established algorithm hedges a future cryptanalytic surprise against the newer one, and ML-KEM removes the quantum exposure of the classical curve. The hedge is cryptanalytic, not universal: a randomness failure or an exploitable handshake bug can compromise a session regardless of how many exchanges it ran.

TLS and IKEv2 each have their route. The TLS 1.3 hybrid groups pairing a classical curve with ML-KEM are deployed at internet scale while their defining documents complete standardization. IKEv2 offers two standardized mechanisms: RFC 8784 mixes a post-quantum preshared key into the key schedule — no new public-key math, effective against passive capture wherever a high-entropy key can be provisioned — and RFC 9370 negotiates multiple key exchanges — the generic mechanism that lets a post-quantum KEM run alongside the classical Diffie-Hellman, with the ML-KEM-specific algorithm identifiers completing standardization behind it. Quantum-safe VPNs walks the tunnel-level detail.

Plan for Bigger Handshakes

ML-KEM changes the packet math. An X25519 public value is 32 bytes; an ML-KEM-768 encapsulation key or ciphertext runs 1,184 and 1,088 bytes respectively. Over TCP, TLS lets the transport segment the larger handshake, at some cost in setup bytes and time; QUIC and DTLS, living on datagrams, feel the growth more directly. IKEv2’s initial exchange rides UDP, and its message fragmentation (RFC 7383) applies only to encrypted exchanges — IKE_SA_INIT cannot use it. That is why RFC 9370 carries the additional key exchanges in IKE_INTERMEDIATE exchanges (RFC 9242), which are encrypted and so can use IKE fragmentation where peers support it. The operational consequence: pilot on lab gear first, measure handshake size and setup time across your real paths — especially constrained WAN links and middleboxes with opinions about UDP — and treat interoperability testing between vendors as part of the rollout, not an afterthought.

Signatures Move on a Different Clock

Signatures sequence by verification lifetime. A handshake signature is consumed at session time: a future ability to forge its algorithm cannot reach back and change a verification that already completed — it enables impersonation in future sessions, which is why session authentication must migrate before the threat arrives but can follow key exchange rather than lead it. A signature on a firmware or software image shipped today is the opposite case — it may need to stay trustworthy for the device’s supported life, verified at every boot and upgrade — so code and image signing migrate early. NIST’s stateful hash-based signatures (LMS/XMSS, approved in SP 800-208) suit that role — their defining hazard is state, since a reused signing state destroys security, which confines them to carefully managed signing infrastructure — and NSA’s CNSA 2.0 guidance for National Security Systems assigns them to software and firmware signing, sequenced first. General PKI migration to ML-DSA follows as certificate authorities, protocols, and validation software align — and certificate chains grow, which the same handshake-size testing should cover.

Run the migration so the next one is cheap: prefer platforms where the algorithm is configuration rather than hardware, and build the substitution muscle deliberately — that discipline is crypto-agility, and it outlasts this transition. None of this is futurism on the certification track either: post-quantum cryptography appears by name in the SCOR 350-701 cryptography objective, next to the PKI and IPsec machinery it amends. The engineers who have run the inventory will find the blueprint’s cryptography objectives familiar ground.

Frequently Asked Questions

Where should a PQC migration actually start?

With an inventory, not an algorithm. Enumerate every place public-key cryptography protects data in motion or authenticates something — VPN tunnels, TLS endpoints, management access, PKI, code signing — and record what each runs today, what its platform can be configured to run, and how long the data it protects must stay secret. That last column leads the ordering: flows carrying long-lived secrets migrate first, because traffic protected only by quantum-vulnerable public-key establishment may already be recorded against future decryption.

Why hybrid key exchange instead of pure ML-KEM?

Because hybrid hedges both directions at once. Deriving session keys from independent classical and ML-KEM secrets means a passive recording stays protected while at least one exchange remains unbroken — the classical algorithm covers the possibility of an undiscovered cryptanalytic flaw in the newer standard, and ML-KEM covers the quantum exposure of the classical one. Negotiation eases the operational transition — peers that both support a hybrid group use it, while older peers fall back to classical groups — but a fallback session carries no post-quantum protection, so whether to allow fallback is a policy decision, and tracking where it still happens is part of the migration.

Do I need new hardware to deploy post-quantum cryptography?

Often no, but it is a platform-by-platform question. ML-KEM and ML-DSA run efficiently on general-purpose CPUs, so software and firmware updates carry the migration on many platforms. The practical constraints are elsewhere: end-of-support devices that will never receive the update, hardware acceleration or HSMs tied to specific algorithms, and constrained links where kilobyte-scale handshake payloads need testing. The inventory is what tells you which of your platforms fall in which bucket.