The good news about the post-quantum migration is that the algorithms are standardised, the libraries are available, and the browser vendors have already done the hard part. The bad news is that the hard part was never the algorithms.
It is the inventory. Specifically, it is every endpoint that terminates a cryptographic handshake and was designed by someone who assumed the algorithm would never change. That set includes your load balancers, your service mesh, your VPN concentrators, your industrial gateways, and the firmware in a device installed in 2016 that nobody has the credentials to update.
Two migrations moving at different speeds
The visible migration is at the edge, and it is going fast. Browsers have shipped hybrid key exchange, major CDNs have enabled it, and the fraction of TLS handshakes using a post-quantum key agreement is already in the double digits and climbing steeply.
The invisible migration is inside the perimeter, and it is barely moving. Internal services, device fleets and code-signing chains move at the speed of procurement, not at the speed of a library release.
That divergence is the risk. A system is only as post-quantum as its weakest link, and the weakest link is usually a device that speaks TLS 1.2 to a broker nobody owns anymore. The gap in the chart is not a scheduling inconvenience; it is the window in which a harvest-now-decrypt-later attack is worth running.
The cost is in bytes, not cycles
The performance conversation about post-quantum algorithms is mostly a distraction. On modern hardware the CPU cost of ML-KEM and ML-DSA is close enough to elliptic-curve operations that it disappears into the noise of a request.
The size cost does not disappear. Public keys, signatures and ciphertexts are all substantially larger than their elliptic-curve equivalents, and the multiplier shows up in three places: the handshake, the certificate chain, and the packet count.
Signature size is the one that hurts. A certificate chain with three post-quantum signatures can add several kilobytes to a handshake, which on a lossy mobile link is not a rounding error. It is extra round trips, extra retransmissions, and a measurable increase in time-to-first-byte for exactly the users with the worst connections.
This is why the practical rollout order is key exchange first, signatures second. Key exchange adds a fixed, bounded amount of data to a handshake you were already doing. Signatures inflate a certificate chain that has to be validated by every client, including the old ones.
The part that will actually bite
Code signing and firmware update chains are where I expect the real incidents.
A firmware update chain typically has a root key with a ten-to-twenty-year life, a signing key rotated yearly, and a verifier burned into a device that cannot be changed. Migrating that chain requires either a device that supports algorithm agility or a dual-signing period long enough to outlive the fleet. Most fleets have neither.
The consequence is that a large installed base will be cryptographically frozen: it can only accept signatures from an algorithm that will eventually be considered broken. That is not a theoretical concern. It is the same problem as the SHA-1 deprecation, except the devices are in factories rather than browsers, and the replacement cycle is measured in decades.
The market arithmetic
The migration itself is a services market before it is a product market. My estimate is that the professional-services spend on cryptographic inventory and remediation runs several times larger than the software licence spend, and that the ratio holds for at least five years.
On the product side, the winners are the ones selling crypto agility rather than crypto algorithms: hardware security modules that can load a new algorithm without a firmware update, certificate authorities that can issue hybrid chains, and observability tools that can answer the question "which of my endpoints is still using RSA" without a six-month project.
The losers are the ones selling a one-time migration. A migration is a project; agility is a capability, and only one of them has recurring revenue.
What to do before the auditors arrive
Start with an inventory, and start it by measurement rather than by asking teams. Passive inspection of handshake metadata across your egress points will find more endpoints in a week than a survey will find in a quarter, because teams genuinely do not know what their predecessors deployed.
Then classify by whether the endpoint can be updated at all. Anything that cannot is a candidate for network isolation and a compensating control, not for a migration plan. Writing "migrate by 2029" next to a device with no update path is how these projects fail their first audit.
Finally, measure the byte cost on your real user population before you enable signatures. The CPU will be fine. The users on a two-bar connection will tell you the truth.
Hybrid or pure, and why it matters more than it sounds
The deployment question that generates the most argument is whether to run hybrid constructions, which combine a classical algorithm with a post-quantum one, or to go straight to pure post-quantum.
Hybrid is the conservative choice, and it is the right default for the next few years. It preserves your security if the new algorithm turns out to have a weakness nobody has found yet, and it preserves interoperability with peers that have not migrated. The cost is that you carry both the classical and the post-quantum bytes, so the size penalty is roughly additive.
Pure is faster and smaller, and it is where the ecosystem will end up. The transition point is not a date; it is the moment when the last peer you must interoperate with supports the new algorithm. For a consumer-facing service that moment has already passed. For an industrial protocol stack it may be 2032.
The mistake I see most often is treating this as a binary choice made once. It is a per-link decision, and the right answer differs between your public edge, your service mesh and your device fleet. A single organisation can legitimately be running pure post-quantum on one link and hybrid on another in the same week, and that is not inconsistency. It is an accurate map of what each peer supports.
What you should not do is defer the decision until the deprecation date is announced, because by then the inventory work is on the critical path and the queue for remediation is longer than the calendar allows.
What is actually transferable
The transferable lesson is that algorithm migrations are fleet problems, not code problems. The code change is a sprint. The fleet change is a decade, and it is bounded by the least-updatable device you have ever shipped.
That asymmetry is worth remembering the next time a standard changes. The question is never "can we implement this". It is "can we un-implement the old thing", and for most organisations the answer is no.
If this saved you time, a tip is appreciated.
HCqPmPJM3NVtS6YrmVaTZYnuP8XZ2PFgQZKT94VK1LkS
Top comments (0)