Two years ago, NIST published FIPS 203, 204, and 205 — the first generation of federally sanctioned post-quantum cryptography standards. The algorithms had been selected through an eight-year competition, scrutinized by cryptographers worldwide, and deemed ready to replace RSA and elliptic curve systems that Shor's algorithm will eventually break. The question since has been: how fast does the Internet actually migrate?
The answer, as of mid-2026, is bifurcated. Per-connection key agreement — the cryptography that protects each TLS handshake — has moved faster than nearly anyone predicted. Static signature systems, particularly DNSSEC, have not moved at all.
TLS: From experiment to majority
By late 2025, over half of human-initiated traffic protected by Cloudflare was using hybrid post-quantum key agreement — specifically X25519MLKEM768, a combination of the classical X25519 elliptic curve protocol and NIST's ML-KEM-768 (formerly Kyber) [1]. The trajectory is striking: from roughly 2% in early 2024 to majority support by October 2025 [1]. Chrome enabled it by default on desktop in March 2024 [2], followed by Android and Firefox later that year; OpenSSL 3.5 enabled it by default in April 2025 [1]; Apple began rolling it out system-wide with iOS 26 and macOS Tahoe 26 [3].
The speed matters because of the threat model. An adversary harvesting encrypted traffic today cannot decrypt it until they have a quantum computer capable of breaking X25519 — but once they have that computer, the harvest retroactively pays off. The window between "traffic is recorded" and "quantum computers exist" is the vulnerability period. ML-KEM closes that window.
What made TLS migration feasible was the protocol's design. TLS 1.3 negotiates key agreement during the handshake; both client and server can add support independently. If either side lacks post-quantum support, the handshake falls back to classical cryptography. No coordination required, no flag days, no certificate changes. The compatibility issues that did emerge — middleboxes confused by larger ClientHello messages, fragmented packets causing problems for load balancers — were real but tractable. Browser vendors and Cloudflare spent years "greasing" the protocol to surface these bugs before they became blockers.
The signature problem
Key agreement was the urgent migration. Signatures are the hard one.
When you visit a website, the key agreement protects against passive eavesdropping, but signatures authenticate — they prove you're talking to the site you intended, not an impostor. RSA and ECDSA signatures are just as vulnerable to quantum attack as X25519. The difference is timing: an active attacker needs a quantum computer now to forge signatures in real-time, whereas recorded traffic can wait decades to be decrypted. Signatures have seemed less urgent.
They are also harder to deploy. Unlike key agreement, where client and server negotiate freely, signatures require certificate infrastructure. A server needs a post-quantum certificate from a trusted CA, but CAs need hardware security modules that support the new algorithms, which need auditing, which takes time. Root certificate programs have differing timelines, and standards for hybrid certificates combining classical and post-quantum signatures remain under active development at the IETF [1]. Although the first post-quantum certificates may appear in 2026, they are unlikely to be broadly available or trusted by all browsers before 2027 [1].
CNSA 2.0 and the 2027 deadline
The National Security Agency's CNSA 2.0 timeline introduces a hard constraint: software and firmware signing must use exclusively post-quantum algorithms beginning January 1, 2027. This is eighteen months away. The White House has set federal agency deadlines of 2030 for high-risk systems and 2031 for remaining systems, with a full migration target of 2035 [4].
The tension is visible. Code signing is static like DNSSEC — signed artifacts persist, cannot be re-signed retroactively — but has a regulatory deadline forcing the question before the infrastructure is ready. Enterprise migration timelines typically run 5–10 years [4]. 2026 is the feasibility boundary: organizations must assess their cryptographic inventory now to meet 2027 compliance.
DNSSEC: The planning document stage
Where TLS reached majority deployment in two years, DNSSEC post-quantum transition remains largely at the planning-document stage. As noted in industry analysis, the root zone and major TLDs have not announced concrete algorithm transition timelines with the specificity visible in TLS deployments [2]. The IETF has work in progress, but DNSSEC's design makes migration harder: signatures are baked into the zone structure, rollover requires coordinated changes across the delegation chain, and the protocol lacks TLS's graceful negotiation mechanism.
This appears to stem from architectural constraints. Per-connection protocols can negotiate; static record protocols must migrate wholesale. The difference in deployment speed between TLS and DNSSEC measures something fundamental about protocol flexibility, not organizational will.
What comes next
The algorithms we deploy today may not be the final ones. NIST's ongoing signature competition is evaluating additional schemes that might outperform ML-DSA on size or speed. NIST selected HQC in March 2025 as a backup key encapsulation mechanism [1] — though at significantly higher bandwidth overhead than ML-KEM, with HQC-1 requiring almost double the wire data of ML-KEM-1024 [1]. The search continues for signature schemes that approach the efficiency of classical ECDSA.
But waiting for better algorithms is not a strategy. As Cloudflare's research team notes [1], quoting TLS 1.3 editor Eric Rescorla: "You go to war with the algorithms you have, not the ones you wish to have." The 50% deployment threshold for post-quantum key agreement means the baseline has shifted. The long tail of difficult upgrades — embedded systems, long-lived firmware, manually configured infrastructure — will take the remaining decade before 2035.
The practical question for 2026 is not whether to migrate, but what order to migrate in. Organizations should inventory their cryptographic dependencies, prioritize high-valued long-lived data, and understand that key agreement and signatures are separate problems with separate timelines. The TLS work is largely done. The signature work has barely begun. And the clock on CNSA 2.0's January 2027 deadline continues to run.
Sources:
– [1] Cloudflare: State of the Post-Quantum Internet in 2025
– [2] neuraparse.com: "Hybrid Post-Quantum TLS and ML-KEM in 2026"
– [3] stevenpg.com: "The Ultimate Guide to Post-Quantum Cryptography and TLS 1.3"
– [4] TechTimes: "Post-Quantum Migration Benchmark Debuts" (July 22, 2026)
– NIST Post-Quantum Cryptography Standards
– Cloudflare: Post-Quantum Key Agreement
– Cloudflare: Defending Against Future Threats
– RFC 9935/9945: ML-KEM for TLS
– NSA CNSA 2.0 Guidance
– hackernoon.com: "Why Google Is Replacing RSA With ECDSA"