Post-quantum migration gets discussed as one project. It's two, and they're in very different states of health.
The half that is going well¶
Key exchange. The hybrid construction, classical X25519 combined with ML-KEM so the result holds if either component does, is deployed and deployable today, and standardised as X25519MLKEM768 in RFC 10024. ML-KEM itself is FIPS 203.
Deployment figures vary wildly depending on who you ask and when. DigiCert's guidance cites Cloudflare reporting more than two-thirds of human-generated TLS protected by hybrid ML-KEM; an arXiv paper citing an earlier Cloudflare report gives 1.8% of TLS 1.3 connections. You can't reconcile those without knowing the measurement and the date, so treat any single number as a snapshot. A 2026 measurement study found roughly half of the domains it analysed with no post-quantum readiness at all, and about half with partial readiness via hybrid key exchange.
AWS has deployed hybrid ML-KEM for KMS, ACM and Secrets Manager, opt-in and client-dependent rather than on by default (AWS); Google Cloud has quantum-safe KEMs in Cloud KMS. The handshake overhead runs to about a kilobyte extra in each direction, with minimal latency impact. If you run a TLS endpoint, this is mostly a matter of upgrading the stack and turning it on.
The half that is not¶
Authentication. Certificates and signatures (ML-DSA, SLH-DSA) are a materially harder migration, and the reasons are structural rather than cryptographic:
- Signatures and keys are much larger. Certificate chains grow, and some protocols have size assumptions baked in.
- The PKI is a multi-party system. Changing it means CAs, browsers, OSes and every validating client moving roughly in step.
- Long-lived roots. A root certificate issued now may have twenty years ahead of it.
The actual bottleneck¶
The 2026 measurement study frames it correctly: the barrier is the operational and compatibility work of migration, no longer the absence of standards.
More specifically, the barrier is crypto-agility: whether a system can change algorithm at all. Anything that hard-codes a cipher suite, pins a certificate by key or needs a firmware update to change its cryptography cannot pivot inside the relevant timescale. Industrial control systems, IoT fleets and embedded devices are the named problem cases.
That changes what the engineering work is. The thing to build now is the ability to change algorithms without a redeployment: negotiated suites, rotatable trust anchors, no algorithm identifiers compiled into firmware.
A system with crypto-agility can adopt whatever wins later. A system without it needs replacing, and that bill won't land on a cryptography budget line.
The cheerful reading is that the industry is being forced to build something it should have had anyway.
Crypto-agility is the ability to respond when any algorithm breaks, not a post-quantum feature. Algorithms break on a schedule nobody controls. MD5, SHA-1, RC4, DES: each took years to retire, and the delay was never mathematical. Somebody had compiled an identifier into something they could not change. A fleet that can rotate its algorithms by configuration can also rotate a compromised key in an afternoon, respond to a CA incident the same day and shorten certificate lifetimes without a project. Post-quantum is the business case that finally pays for those capabilities.
For an engineer the toil that disappears is the emergency crypto migration: the fortnight of finding every place a cipher suite was named, in configuration files, in firmware, in a vendor appliance nobody has the password for. Do the work once and it never happens again, for any future algorithm.
Rotatable trust anchors also mean a device deployed in a water treatment plant for twenty-five years can accept a new root without a truck roll. The alternative is that it either keeps trusting a root long past its credibility, or stops working. Both happen now, and the second is how you discover the first.
Who set the standards, and who pays for the migration¶
The chokepoint here is distributional: the standards were set by a few, and the migration cost falls on everybody.
The NIST process was open, competitive and better run than it had to be; ML-KEM, ML-DSA and SLH-DSA have had more scrutiny than their predecessors. Hold that and still notice the shape of it. A standards process led by one country's agency, contributed to by a small academic community and a handful of large companies has produced a mandatory change to the cryptography of every connected device on earth. Nobody voted, and the bill is itemised on somebody else's timetable.
Where that bill lands is the part to watch. The hyperscalers have already migrated their key exchange, because for them it is a configuration change across infrastructure they control and a line in a compliance document they can sell. For everybody else it is a hardware refresh. A hospital with infusion pumps, a utility with meters, a manufacturer with controllers on a twenty-year cycle: crypto-agility means replacement, and the deadline becomes an unfunded capital programme with a cryptographic justification. Expect that to move more on-premises infrastructure into managed cloud services, because there the cryptography is somebody else's problem and priced monthly.
Watch the certificate authorities too. Larger keys, shorter lifetimes and more frequent rotation all increase the operational dependency on the CA, and automation-only issuance makes every TLS endpoint dependent on a live service relationship rather than a file.
The open version is in good shape, for once. OpenSSL and the common libraries have the algorithms, and you can run your own post-quantum PKI on your own hardware today. What is scarce is people who have done the migration, which argues for doing it early rather than buying your way out.
Here at AxisOps the position is that cryptographic agility is an ownership property. A system whose algorithms you can change is a system you control; one that needs a vendor's firmware release is a system you are renting. Treat any device that cannot have its cryptography changed by configuration as having a disposal date rather than a lifespan.
Harvest-now-decrypt-later¶
The case for urgency is that traffic recorded today can be decrypted once a capable machine exists. A real threat model, wheeled out as a scare tactic more often than it's assessed.
The sober version is a question whose answer differs per organisation: what of today's traffic is still sensitive in fifteen years? For most session traffic, nothing at all. For long-lived secrets, medical records, state communications and anything with a statutory retention period, quite a lot.
Do that analysis before you buy anything. The answer decides whether this is urgent for you or merely eventual, and the two have very different price tags.
Related, on where the threat comes from: error correction is the whole game.