Signatures and Key Exchange Are Two Different Migrations. Don't Run Them as One.

It is natural to talk about "the post-quantum migration" as a single program of work with one timeline and one budget. But cryptography does two quite different jobs — it keeps secrets, and it proves authenticity — and the quantum threat lands on those two jobs on two different schedules. Treating them as one undifferentiated migration almost guarantees that your first and most expensive effort goes to whichever piece is easiest to reach, rather than to whichever piece is actually most urgent.

The distinction is not academic hair-splitting. Key exchange is exposed to an attack that is effectively running today. Signatures are exposed to an attack that cannot happen until a quantum computer exists, and even then only against things signed from that day forward. Those are different problems with different deadlines, and the single most useful thing you can do early in a migration is refuse to blur them together.

Two mechanisms, two clocks

Start by being precise about the two mechanisms. A key encapsulation mechanism, or KEM, establishes a shared secret between two parties so they can encrypt a conversation; its job is confidentiality. A signature proves that a message came from the holder of a particular key and was not altered in transit; its job is authenticity and integrity. ML-KEM is the standardized post-quantum KEM. ML-DSA and SLH-DSA are the standardized post-quantum signature schemes. The reason to keep the two firmly separate in planning is that their clocks run at very different speeds, and sequencing the work by clock is most of the battle.

KEMs and the harvest-now clock

The KEM clock is already ticking, because of harvest-now-decrypt-later. An adversary records your encrypted traffic today and simply stores it, then decrypts it on the day a capable quantum computer arrives. The vulnerable part of that traffic is the key exchange: recover the session key and the stored recording becomes readable plaintext. This is why confidentiality with any meaningful shelf life is at risk now, before a single quantum computer exists, because the ciphertext that will be broken later is being collected in the present. It is why the KEM migration is the urgent one, and why hybrids exist at all — to get quantum-resistant key exchange deployed before the standards and the surrounding ecosystem have fully matured.

Signatures and the forger's clock

The signature clock is different, and it mostly points into the future. A quantum computer could forge signatures by recovering a private key from its public counterpart — but only once that computer exists, and a forgery produced then does not reach back in time to falsify something you signed today. There is no harvest-now analogue for authenticity: recording a signature does an attacker no good, because there is nothing in it to decrypt later. So for most signatures, the ephemeral ones that authenticate a live handshake and are irrelevant seconds after, the threat genuinely waits for the hardware. The consequential exception is a signature that must remain verifiable for many years, which begins to overlap the horizon and starts to behave like the urgent case.

A recorded ciphertext is a problem the day it is captured; a forged signature is a problem only the day it is made — which is exactly why one migration is urgent and the other is merely important.

Size and performance differ sharply

The two migrations also differ in what they cost to deploy, and the costs do not land in the same place or on the same component.

• KEM key shares are larger, but bounded — a lattice KEM's public key and ciphertext are kilobytes where classical values were tens of bytes, inflating each handshake but as a one-time, per-connection cost.
• Signatures can be larger still — post-quantum signatures and their public keys are often substantially bigger than classical ones, and the schemes trade against each other on signature size, key size, and raw speed.
• Verification lands in the wrong place — a signature is checked by everyone who relies on it, frequently on the smallest and slowest device in the system, so signature-size and verification-time penalties bite hardest at the edges.
• Big objects break old assumptions — formats, buffers, and packets sized for small classical values mishandle large post-quantum ones, which is where a size increase stops being a bandwidth line item and becomes an outage.

Firmware signing versus TLS certificates

Within signatures, not everything is equally urgent, and the sorting principle is lifetime rather than importance. A TLS handshake signature lives for the length of a single connection; if it only becomes forgeable a decade from now, the connection it authenticated ended long ago and the forgery buys nothing. A firmware signing key or a root certificate is a different animal: it is trusted for the service life of the hardware or the lifetime of a public-key infrastructure, often a decade or more. A signature that must remain unforgeable twenty years out is effectively racing the quantum horizon in the same way confidentiality is. That puts long-lived signing — firmware roots, PKI roots — far ahead of ephemeral handshake signatures in the queue, even though both are filed under the single word "signatures."

Stateful hash-based signatures and their footguns

One family of post-quantum signatures deserves a specific warning, because it is tempting for exactly the long-lived signing just described. Stateful hash-based schemes rest on conservative, well-understood assumptions, which is attractive when a signature has to stay trustworthy for decades. The catch is in the name: they are stateful. Each private key may sign only a bounded number of times, and the signer has to reliably track which one-time keys it has already consumed. Reuse of a one-time key — from a restored backup, a cloned virtual machine, a crash that loses the counter — can be catastrophic for the scheme's security rather than merely inconvenient. That quietly converts a cryptographic decision into a systems-engineering obligation to never, ever lose or duplicate signing state, which is harder than it sounds and is the footgun to design around before adopting the scheme.

Sequencing the work

Put the clocks side by side and the sequence writes itself. First comes the KEM migration for anything whose confidentiality has a long shelf life, because the recording that defeats it is happening now. Next come long-lived signatures — firmware keys and PKI roots — because their forgeability window genuinely overlaps the horizon. Last come ephemeral signatures, which can reasonably wait for the hardware they are racing against. Run these as one flat project and effort will gravitate toward whatever is easiest to touch, which is almost never the time-critical item.

When 6QURE reviews a post-quantum migration plan, the first thing worth checking is whether it is genuinely one plan or two plans pretending to be one. Separating the KEM migration from the signature migration, and then ordering the signature work by how long each signature has to stay trustworthy, is what keeps the first and most expensive year of effort pointed at the data and the keys that are actually exposed. The two migrations share a vocabulary and almost nothing else; running them on a single clock is the most common way to stay very busy and still fall behind.