In August 2024 NIST published the first final post-quantum cryptography standards: ML-KEM derived from Kyber for key exchange, ML-DSA derived from Dilithium for digital signature, and SLH-DSA based on Sphincs+ as a conservative signature. Twenty months have passed since then, and the conversation has moved from “when to start” to “how it’s really going”. In April 2026, with two full years of real deployment to look at, there is enough data to separate what has worked from what remains stuck.
What Has Actually Been Migrated
The most advanced area is public-web TLS. Major browsers enabled X25519+ML-KEM hybrid exchanges by default through 2025, and Cloudflare, Google, and the large CDNs negotiate post-quantum on almost every new connection to sites they serve. Telemetry from Mozilla and Cloudflare puts hybrid handshakes over 60% of global web traffic. For services sitting behind a modern CDN, migration has already happened without operations needing to do anything special.
SSH is the second area with real progress. OpenSSH 9.9 made sntrup761x25519-sha512 the default exchange a while back, and OpenSSH 10.0 added mlkem768x25519-sha256 aligned with the final standard. Servers updated since 2025 come with hybrids negotiated out of the box. In environments with automatic configuration management, Debian Trixie or RHEL 10, SSH migration happened without intervention. In environments where configuration is frozen by policy or fear of breaking old jump hosts, it remains stuck.
Corporate VPN is the third area with movement. WireGuard itself has not incorporated post-quantum into its base protocol, and that will likely require a major revision that does not yet exist in stable form. But enterprise VPN vendors, Palo Alto, Fortinet, Cisco, Check Point, have added IKEv2 options in hybrid mode using ML-KEM, and many large companies have enabled that option on site-to-site tunnels. For remote users with proprietary clients, the situation depends on the vendor and client, with uneven results.
What Remains Stuck
The hardest part has been, predictably, signatures. ML-DSA signatures are five to ten times larger than classical equivalents, and that hits places where size matters. X.509 certificates with ML-DSA plus their chains weigh several kilobytes; in TLS this inflates the handshake enough to cause visible issues on marginal networks. Let’s Encrypt’s ML-DSA chain trials began in 2025 and remain in limited pilots in 2026 because the production rollout cost turned out higher than expected.
Code signing is another slow front. SLH-DSA is quite large, tens of kilobytes per signature, which clashes with legacy firmware formats and embedded devices where every kilobyte counts. Serious vendors are migrating, but in phases, and field-deployed legacy devices will remain classically signed throughout their service life. The real mitigation here is device replacement on normal cycles, not forced retroactive migration.
DNSSEC is the most problematic and honest case. Post-quantum signatures are too large to fit in UDP packets without fragmentation, and DNS over fragmented UDP is a well-known operational nightmare. The IETF has been discussing solutions since 2024 and there have been several drafts, but no canonical solution as of April 2026. It will likely require a different transport or a purpose-designed signature scheme, and that will take time. Meanwhile DNSSEC remains a case where migration cannot happen by “flipping the new option on”.
The Real Operational Problems
The serious problems of 2025 and early 2026 have been engineering, not cryptographic. Implementation incompatibilities because an intermediate draft crystallised differently from the final standard, causing incidents where a client would not negotiate with a later-updated server. Incompatibility with hardware acceleration, because old HSMs don’t support ML-DSA and need specific firmware or replacement. CPU cost: ML-DSA is competitive for sign and verify, but ML-KEM adds cycles over pure X25519 that show up on nodes handling thousands of handshakes per second.
Less technical but more frequent: inventory. Most organisations discovered during migration that they didn’t know where their cryptography lived. Old libraries linked into production binaries, calls into crypto APIs inside third-party code, signatures embedded in proprietary formats. The crypto-agility effort, having the inventory and the capacity to swap algorithms without rewriting applications, has in many cases been larger than the migration itself. And it still is, for anyone who didn’t tackle it in 2024.
Harvest Now, Decrypt Later: What It Means Today
The underlying economic motivation is unchanged: encrypted traffic captured now with classical algorithms could be decrypted a decade from now if a Shor-useful quantum computer exists. Information that outlives 2035 and remains confidential must be protected today. This affects long-lived industrial secrets, diplomatic communications, long-term medical records, unpublished patents, legal records.
The pragmatic consolidation is that, for ephemeral consumer traffic, retail user accounts, web searches, short-lived application sessions, classical cryptography remains acceptable because decrypting it in 2035 will carry little value. For long-lived sensitive traffic, migration should already be done. This segmentation by secret lifetime is what distinguishes security teams that think about real risk from those that write uniform policies.
How It Looks From April 2026
Official forecasts still pointed to late decade for a quantum computer able to break RSA or ECC keys at current sizes, and in 2026 that expectation has not materially changed. IBM today has four-thousand-physical-qubit processors but noise that keeps the usable logical qubit well below what Shor needs at cryptographically relevant scale. Google, IonQ, and Quantinuum continue progressing on fault tolerance, with real milestones but still far from breaking production TLS. The pragmatic window remains seven to ten years for real threat.
# Quickly check whether your server negotiates post-quantum
openssl s_client -connect example.com:443 -tls1_3 -groups X25519MLKEM768:X25519 </dev/null 2>&1 \
| grep -E 'Server Temp Key|Cipher'When It’s Worth It
Post-quantum migration is happening, but not uniformly. Ephemeral public traffic has almost solved itself. Intra-corporate traffic depends on refreshing equipment and configurations. Signatures and long-term validation remain the tricky cases, and DNSSEC is the extreme example of a non-trivial transition.
When to invest today: if your organisation handles secrets with lifetimes over ten years, you should already have a plan and have executed part of it. If your main workload is public web behind a modern CDN, migration probably rolled over you already and what’s missing is documentation. For everyone else, useful work in 2026 isn’t flipping post-quantum on everywhere, it’s honest inventory, closing the crypto-agility gap so algorithms can change without a big project, and refreshing broken systems sensibly on their natural cycle. Insurance is cheap when it’s not raining; this is one of those.
