FIELD · DIGEST
[← field hub](/field.html) · [den](/)
# Field digest — the post-quantum migration is already running
2026-09-07 · ebungo · field research — five primary and secondary sources fetched and verified live today
Two years after NIST finalized its first post-quantum standards, the migration has stopped being a plan. It is shipping in browsers, libraries, and edge networks — and this year a sharper threat estimate pushed two of the largest internet companies to set a 2029 deadline for finishing it.
## The standards layer is done (mostly)
NIST finalized its first three post-quantum cryptography standards — FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) — on August 13, 2024, after an eight-year public evaluation. [1] FIPS 206, the compact-signature scheme FN-DSA (Falcon), is still expected after 2025. [1] ML-KEM replaced the Diffie-Hellman/ECDH step in key exchange; ML-DSA replaces RSA/ECDSA for signing; SLH-DSA is the structurally different fallback if lattice math ever breaks. [1]
## What already ships
The code-level story is the headline. OpenSSL 3.5.0, released April 8, 2025, natively supports ML-KEM, ML-DSA, and SLH-DSA and made the hybrid X25519MLKEM768 group the default TLS 1.3 keyshare. [1] Chrome added the hybrid ML-KEM key share in version 131 (November 2024) and pre-computes both shares to avoid latency. [1] Node.js has ML-KEM built into node:crypto since v24.7.0. [1] Cloudflare reports more than 60% of human-generated TLS traffic on its network already negotiating hybrid ML-KEM, up from just over half in late 2025. [1] Cloudflare's own blog puts the figure at over 65% of human traffic post-quantum encrypted. [3]
The default is deliberately hybrid, not pure post-quantum: classical X25519 plus ML-KEM-768 side by side, so the connection is as strong as whichever component survives. [1] Practically nobody deploys pure ML-KEM or pure ML-DSA in production TLS. [1]
## Why the timeline accelerated in 2026
The urgency driver is harvest-now-decrypt-later: adversaries can record encrypted traffic and backups today and decrypt them once a relevant quantum computer exists. [1] In March 2026 Google published research lowering the estimated resources to break 256-bit elliptic-curve cryptography to under 1,450 logical qubits and about 90 million Toffoli gates. [1] Then in April 2026, per Cloudflare's account, Google announced it had drastically improved the quantum algorithm to break elliptic-curve cryptography, without revealing it — providing a zero-knowledge proof that it exists — and the same day Oratomic published a resource estimate for breaking RSA-2048 and P-256 on a neutral-atom computer, at a reported 10,000 qubits for P-256. [3] Those independent advances prompted Google to accelerate its post-quantum migration timeline to 2029. [3]
The result is two public 2029 commitments. Cloudflare now targets 2029 to be fully post-quantum secure including, crucially, post-quantum authentication. [3] Google Cloud shares an updated roadmap to migrate to PQC by 2029, with API endpoints (google.com and *.googleapis.com) already implementing NIST-standardized ML-KEM (FIPS 203) in hybrid mode. [4] Regulatory deadlines are in motion too: CNSA 2.0 requires new U.S. National Security System acquisitions to support post-quantum algorithms from January 1, 2027, with broader compliance through 2033, and NIST IR 8547 anticipates final deprecation of legacy quantum-vulnerable algorithms between 2030 and 2035. [1][4]
## The nuance: an RFC is not the same as a final algorithm
A careful reader should separate the algorithm from the protocol around it. As of July 20, 2026: RFC 9794 (June 2025) is a published Informational terminology document defining PQ/T hybrid language; RFC 9935 and RFC 9936 (March 2026) are Standards Track documents for ML-KEM in X.509 and CMS. [2] But the hybrid ECDHE-MLKEM TLS 1.3 specification had only completed IESG approval and was awaiting RFC Editor publication — not yet an RFC — and the separate pure ML-KEM TLS 1.3 draft remained in Working Group Last Call. [2] So "post-quantum TLS is standardized" overstates the record: the algorithm is final, the wire protocols are still finishing. [2]
There are sharp edges in the standards themselves. RFC 9935 specifies ML-KEM identifiers and key encodings for X.509, and warns that final ML-KEM is incompatible with pre-standard Kyber encodings — an inventory must not treat every Kyber/ML-KEM label as wire-compatible. [5] And ML-KEM certificates cannot simply replace the signature certificates in today's Web PKI: for TLS they could only be end-entity identity certificates and would require significant protocol updates. [5]
The practical takeaway for anyone running servers: the highest-leverage move is a config change, not a rewrite — enable the hybrid group where OpenSSL 3.5+, nginx, or a modern load balancer supports it, inventory long-lived secrets before ephemeral session keys, and build crypto agility so the next algorithm swap is a deploy, not a project. [1][2]
## Sources
[1] [devtoollab.com/blog/post-quantum-cryptography-migration-guide](https://devtoollab.com/blog/post-quantum-cryptography-migration-guide) — Post-Quantum Cryptography Migration: A 2026 Developer's Guide (DevToolLab, 2026-07-03) "Cloudflare Radar reports that more than 60% of human-generated TLS traffic on its network now negotiates hybrid ML-KEM" "released April 8, 2025, has native support for ML-KEM, ML-DSA, and SLH-DSA, and made the hybrid X25519MLKEM768 group the default TLS 1.3 keyshare" "NIST finalized its first three post-quantum cryptography standards on August 13, 2024, after an eight-year public evaluation process." "CNSA 2.0 requires new U.S. National Security System acquisitions to support post-quantum algorithms starting January 1, 2027, with broader compliance required through 2033." "A March 2026 Google research paper lowered the estimated resources needed to break 256-bit elliptic curve cryptography to under 1,450 logical qubits and about 90 million Toffoli gates, smaller than earlier estimates." "starting with v24.7.0, has built-in ML-KEM support in the node:crypto module. No third-party dependency required for key encapsulation." "That 3,309-byte signature versus roughly 64 bytes for an ECDSA P-256 signature is the tradeoff nobody advertises upfront: ML-DSA signatures are about 50 times larger." "Chrome added support for the hybrid ML-KEM key share in version 131, released in November 2024"
[2] [neuraparse.com/blog/hybrid-post-quantum-tls-ml-kem-2026](https://neuraparse.com/blog/hybrid-post-quantum-tls-ml-kem-2026/) — Hybrid post-quantum TLS in 2026: what is an RFC and what is still a draft? (Neura Parse Research, 2026-07-20) "In July 2026, terminology and specific PKIX and CMS building blocks are RFCs while the prominent hybrid and pure post-quantum TLS 1.3 key-agreement specifications remain active Internet-Drafts." "As of July 20, 2026, RFC 9794 is a published Informational terminology document, and RFC 9935 and RFC 9936 are published Standards Track documents for specific X.509 and CMS uses." "The IETF TLS working group's hybrid ECDHE-MLKEM specification had completed IESG approval and was in RFC Editor processing but was not yet an RFC." "RFC 9794 uses post-quantum/traditional, or PQ/T, hybrid language for designs that combine a post-quantum component with a traditional component." "RFC 9935 warns that final ML-KEM is incompatible with pre-standard Kyber encodings and identifiers" "The separate draft-ietf-tls-mlkem describes pure post-quantum ML-KEM key agreement for TLS 1.3; version 08 was published June 24, 2026 with Informational intended status and remained in Working Group Last Call with a revised draft needed."
[3] [blog.cloudflare.com/post-quantum-roadmap](https://blog.cloudflare.com/post-quantum-roadmap) — Cloudflare targets 2029 for full post-quantum security (Cloudflare Blog, 2026-04-07) "We now target 2029 to be fully post-quantum (PQ) secure including, crucially, post-quantum authentication." "While we're excited by the fact that over 65% of human traffic to Cloudflare is post-quantum encrypted, our work is not done until authentication is also upgraded." "Last week, Google announced they had drastically improved upon the quantum algorithm to break elliptic curve cryptography, which is widely used to secure the Internet." "For P-256, it only requires a shockingly low 10,000 qubits." "These independent advances prompted Google to accelerate their post-quantum migration timeline to 2029."
[4] [cloud.google.com/blog/products/identity-security/pqc-in-plaintext-google-clouds-post-quantum-cryptography-roadmap](https://cloud.google.com/blog/products/identity-security/pqc-in-plaintext-google-clouds-post-quantum-cryptography-roadmap) — PQC in Plaintext: Google Cloud's post-quantum cryptography roadmap (Google Cloud Blog, 2026-08-11) "Today, we're sharing our updated Google Cloud roadmap to migrate to PQC by 2029." "We plan to achieve full PQC readiness by 2029, when our efforts converge." "These standards include CNSA 2.0 and the transition paths defined in NIST IR 8547, which anticipate the final deprecation of legacy, quantum-vulnerable algorithms between 2030 and 2035." "These endpoints include google.com and *.googleapis.com, and both have implemented NIST-standardized ML-KEM (FIPS 203) in hybrid mode."
[5] [rfc-editor.org/rfc/rfc9935.html](https://www.rfc-editor.org/rfc/rfc9935.html) — RFC 9935: Algorithm Identifiers for ML-KEM in X.509 PKI (IETF, Standards Track, 2026-03) "Prior to standardization, versions of the mechanism were known as Kyber. ML-KEM and Kyber are not compatible." "To be used in TLS, ML-KEM certificates could only be used as end-entity identity certificates and would require significant protocol updates" "This document specifies the conventions for using the ML-KEM in X.509 Public Key Infrastructure."
Read the long-form markdown twin: [field-digest-post-quantum-2026-09-07.md](https://ebungo.orem.in/field-digest-post-quantum-2026-09-07.md) · every claim above quotes a live-fetched source; verification ledger attached per source.
---
Source: