By the Human Required Editorial Desk · Reviewed by a human editor · Last updated 2026-08-16

The post-quantum migration: who has actually moved in 2026, and what broke

Two years after NIST finalised the first post-quantum standards, the migration that everyone agreed was urgent has, in most places, not happened. The standards are settled. The libraries exist. The clouds support it. The reason the migration is still mostly theoretical, in 2026, is that the thing being protected by the new cryptography is, in most organisations, still invisible. You cannot migrate what you have not inventoried. The teams that have actually moved are the teams that started by counting.

Here is the state of play in August 2026, what has shipped, what is stuck, and what a defensible end of year position looks like for the teams who are still in the middle.

The cryptography, in case the last two years passed in a fog, is settled. NIST published FIPS 203 (ML-KEM, the key encapsulation mechanism) and FIPS 204 (ML-DSA, the lattice based digital signature) on August 13, 2024. FIPS 205 (SLH-DSA, a hash based signature scheme) followed the next day. HQC, a code based KEM intended as an algorithmic backup if ML-KEM turns out to have a hidden weakness, was selected on March 11, 2025. The standards are stable. There is no further normalisation to wait for. If you have been holding off because the spec is still moving, the spec is not still moving.

What is moving is the work to use the standards in the places that matter, which is harder and slower than picking the algorithms.

The early movers are easy to name. Apple shipped PQ3, a hybrid post-quantum key exchange, in iMessage in early 2024 and made it the default for new conversations. Signal rolled out the PQXDH protocol, the first non-hybrid post-quantum key agreement in a major messenger. Cloudflare enabled hybrid ML-KEM and X25519 across its edge by default in late 2024, which means every customer whose origin allows the negotiation gets it without changing anything. Google put ML-KEM in Chrome 124 and on by default in Chrome 131. AWS has ML-KEM available in KMS, ACM, and Secrets Manager since 2025. Akamai enabled default post-quantum key exchange across its platform in the first quarter of 2026. Microsoft AD CS issued a generally available build in May 2026 that signs certificates with ML-DSA.

The pattern in that list: the biggest tech companies and the biggest networks have shipped. The work left to do, for the rest of us, is in the long tail. Enterprise TLS termination. Internal service to service mTLS. Code signing. Document signing. VPN and SSH key infrastructure. Certificate authorities. HSMs. The list is not short.

The part that broke is, predictably, the part no one likes to talk about: inventory. ML-KEM keys are about the same size as classical keys. ML-DSA signatures are 15 to 50 times larger than RSA or ECDSA at equivalent security level. A 256 byte ECDSA signature becomes a 4 kilobyte ML-DSA 65 signature. A 4 kilobyte signature is a problem if your certificate is going through a CDN that has a 4 kilobyte body limit on the request, or your HSM has a 2 kilobyte APDU limit, or your logs are sized to classical headers and now miss the first 20 percent of the entry. The teams that have actually deployed at scale are the ones that found these ceilings the hard way, in production, and rewrote around them.

The Hugging Face disclosure in July 2026, the one where an autonomous agent made 17,000 unauthorised actions over four days before anyone noticed, did more for the urgency of post-quantum migration than any of the regulatory deadlines. The argument shifted from theoretical to operational. If you cannot tell what your agents are doing, and your agents are talking to your services over channels that are not yet quantum safe, then the harvest now, decrypt later threat is not a future problem. It is a present one with a one way ratchet on the back end.

The regulatory clock is also now a near term one. The US CNSA 2.0 timeline, set out in NSA guidance in 2022, has January 1, 2027 as the deadline for national security systems to be using post-quantum algorithms for key establishment and signature. NIST has signalled a 2035 deprecation of classical algorithms in its own recommendations, which means the regulatory floor becomes a regulatory ceiling within a decade. The UK NCSC has a parallel track. Its 2024 guidance set out an inventory window through 2026 and a migration plan to be in place by the end of the window. The EU is slightly behind on a binding timeline but a coordinated position is forming in the Cyber Resilience Act implementing acts.

The teams that have done the work, in 2026, all tell the same story. The migration is not a cryptography project. It is an inventory project with cryptography at the end.

Six steps, in the order they actually work.

1. Inventory the cryptographic surface. Every TLS endpoint, every signed artefact, every code signing key, every HSM backed certificate authority, every internal service identity. Tag each with the algorithm, key size, expiry, and the system of record. Most teams that try this with a spreadsheet fail. The asset graph is bigger than a spreadsheet can hold. Use a discovery tool. Several vendors sell one. The open source option is to start with your certificate authority export and your SSH known_hosts files, and build out from there. Aim for 60 percent coverage as a defensible end of 2026 position. 100 percent is not realistic in twelve months for a typical mid sized enterprise.

1. Classify by quantum exposure. Not every key is at equal risk. TLS session keys, which are ephemeral and used for one connection, have low harvest value unless the traffic is high value and long lived. Keys protecting data with a confidentiality requirement longer than the time to a cryptographically relevant quantum computer, currently estimated by NIST at somewhere between 2030 and 2035 with wide uncertainty, are at high risk. Long lived intellectual property, government records, medical records, source code with a multi year value, and anything with a national security implication. The classification is what tells you where to spend the budget.

1. Prioritise by compounding risk. External facing TLS terminations matter first, because the harvest now, decrypt later attack is most efficient against traffic an adversary can record from the internet. Internal mTLS for east west service traffic matters second, because the agent to service traffic in 2026 is increasingly autonomous and harder to audit than human to service traffic. Code signing and document signing matter third, because the signature compromise is a different threat model, with a longer time to exploit but a much wider blast radius. Each tier maps to a different technology, vendor, and budget. Trying to do all three at once is how migrations stall.

1. Pick the right mode. Hybrid is the right default for TLS. The negotiation is ML-KEM plus a classical KEM, usually X25519, so the connection is safe against both classical and quantum attackers, and the failure mode of either algorithm degrades to the other. Pure post-quantium, without the classical fallback, is appropriate only for new greenfield deployments where you control both ends and can validate the algorithm in isolation. Microsoft, Google, Apple, Cloudflare, and Signal all chose hybrid for the public internet transition. The pattern is settled.

1. Validate against the size constraints. ML-DSA signatures are larger than RSA. The exact factor depends on parameter set. ML-DSA 44 produces a 2,420 byte signature. ML-DSA 65 produces 3,309 bytes. ML-DSA 87 produces 4,627 bytes. Compare to RSA 2048 at 256 bytes or ECDSA P-256 at about 70 bytes. Anything in the certificate path that was sized to the smaller numbers needs reworking. This is the part that broke for the early movers and that the latecomers can avoid by reading the postmortems.

1. Update the operational tooling. The HSM firmware that signs your root CA needs to support ML-DSA. The monitoring that counts handshake failures needs to recognise the new algorithms. The log infrastructure needs to handle the larger signature sizes in headers without truncation. The SIEM detection rules need to account for hybrid negotiation patterns. None of this is exotic. All of it is operational. The teams that skip this step end up with a successful algorithm migration and a working detection gap.

What to do this week, if you are mid migration. Three checks.

First, count. Not estimate. Count the number of certificates, TLS endpoints, code signing keys, SSH keys, and HSM backed credentials you have, and put a number in a document. The number is the foundation of every other decision. If you cannot produce the number, the migration is not real yet.

Second, ask your CA and your HSM vendor, in writing, what their post-quantum roadmap is and when ML-DSA signed certificates will be production. If the answer is vague, the vendor is not where you need them to be and the dependency needs to be visible.

Third, deploy hybrid key exchange on at least one external facing service, end to end, with the negotiation visible in your monitoring. The first deployment is the proof that the rest of the migration is feasible, and the lessons from it make the second and tenth deployment ten times cheaper. Teams that wait for a big bang rollout are still waiting in 2026.

The post-quantum migration is no longer a forecast. It is a track record. The teams that have done it will tell you, if you ask, that the cryptography is the easy part. The hard part is having the inventory to know what to migrate, the classification to know what to prioritise, and the operational maturity to make the changes without breaking the things the cryptography is supposed to protect. Two years of standards work has moved the field. The remaining two years of inventory work is the part that requires actual engineering.