Loading story…
IETF RFC 10024 establishes three hybrid post-quantum TLS 1.3 key-agreement groups that combine ML-KEM with elliptic-curve Diffie-Hellman. X25519MLKEM768 is the only group designated Recommended in IANA’s TLS Supported Groups registry; NIST-curve variants remain available for compliance-focused deployments. The standard formalizes an approach already used by browsers, CDNs, and TLS libraries and discourages use of earlier Kyber768 draft code points, reducing a standards barrier to mitigating harvest-now-decrypt-later exposure.
Cloudflare has deployed Automatic Key Exchange to probe origin-server capabilities and select the strongest mutually supported TLS 1.3 group, prioritizing X25519MLKEM768. The rollout increased post-quantum traffic across scanned origins from roughly 25 billion to 45 billion daily connections, with 99.2% of post-quantum handshakes completing in one network round trip; retry-dependent handshakes fell from about 52% to 3.7%, cutting 90th-percentile handshake latency by more than 150 ms. Organizations still need origins that support X25519MLKEM768 to receive end-to-end hybrid key-establishment protection, while post-quantum TLS authentication remains constrained by limited public WebPKI support for ML-DSA certificates and trusted roots.
Track how attackers are adapting to this technology.
10 events from the most recent confirmed update back to the earliest known activity.
The IETF published RFC 10024 as a Proposed Standard defining X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 hybrid TLS 1.3 key-agreement groups. IANA marked X25519MLKEM768 as Recommended and relabeled the earlier Kyber768 draft groups as obsolete and discouraged.
Executive Order 14412 required U.S. federal civilian agencies to migrate high-value assets and high-impact systems to post-quantum key establishment by the end of 2030 and to post-quantum digital signatures by the end of 2031.
More than two-thirds of human-initiated TLS traffic to Cloudflare negotiated a hybrid post-quantum key exchange.
Chrome enabled X25519MLKEM768 by default starting with Chrome 131.
Firefox enabled the hybrid X25519MLKEM768 TLS key-agreement group by default beginning with Firefox 132.
NIST finalized the ML-KEM post-quantum key-encapsulation mechanism in FIPS 203.
Cloudflare began deploying hybrid key exchange at its edge using the experimental X25519Kyber768Draft00 group.
Cloudflare began automatically probing TLS 1.3-capable origins and selecting the strongest mutually supported key-exchange algorithm, prioritizing X25519MLKEM768. During rollout, post-quantum traffic among scanned origins rose from about 25 billion to 45 billion daily connections and retry-required handshakes fell from about 52% to 3.7%.
After its earlier experimental Kyber deployment, Cloudflare adopted the standardized X25519MLKEM768 hybrid key-exchange group.
rustls 0.23.44 enabled ML-DSA certificate verification by default for private-PKI use cases.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Follow how adversaries are adapting to this technology, and where it touches your stack today.
3 references tracked. Mallory keeps watching after this page renders.
postquantum.com
Open sourcesdxcentral.com
Open sourcedatatracker.ietf.org
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
The IETF has moved `draft-ietf-tls-mlkem` to IETF-wide Last Call, advancing a specification that defines pure `ML-KEM-512`, `ML-KEM-768`, and `ML-KEM-1024` NamedGroups for key establishment in TLS 1.3. If approved, the document would become an Informational RFC and give implementers a stable reference for standalone ML-KEM in TLS, while the IANA registry would continue to mark the pure ML-KEM groups as **Recommended = N** and the hybrid `X25519MLKEM768` group as **Recommended = Y**. The proposal remains contentious after multiple Working Group Last Calls, appeals, and objections from cryptographers who argue that pure ML-KEM lacks the resilience of hybrid key exchange if one component later proves weak. The latest draft adds clarification on the meaning of the registry recommendation flag and expands security considerations around randomness exposure in ML-KEM. Despite the debate, downstream standards bodies including **O-RAN**, **IEEE 802.11**, and **3GPP** have backed publication to obtain a stable post-quantum reference for their own specifications.
Aug 1, 2026
Let's Encrypt said it will use **Merkle Tree Certificates (MTCs)** as its preferred approach for post-quantum authentication on the public web, arguing that conventional post-quantum signatures such as `ML-DSA` would make standard TLS certificate chains too large for reliable internet-scale handshakes. The model batches certificate issuance under a single signed Merkle tree head and delivers compact inclusion proofs, reducing handshake overhead while making Certificate Transparency inherent to issuance. Let’s Encrypt said current subscribers do not need to take immediate action, but future ACME clients and related tooling will need updates as the ecosystem moves toward the new format. The move aligns Let’s Encrypt with broader work by **Google, Cloudflare, Chrome, DigiCert, and the IETF**, as browser and infrastructure vendors push for scalable post-quantum TLS ahead of government migration deadlines from the NSA, NIST, and the EU. Let’s Encrypt plans a staging environment for MTC issuance in late 2026 and a production-ready deployment in 2027, while continuing to track `ML-DSA` support for traditional X.509 use cases outside the browser ecosystem. It also said the more urgent near-term defense remains post-quantum encryption against harvest-now-decrypt-later threats, urging operators to enable hybrid key exchange such as: ```text X25519MLKEM768 ```
Jun 29, 2026
Cloudflare has added post-quantum authentication to **Authenticated Origin Pulls** and **Custom Origin Trust Store**, enabling customers to use **ML-DSA** signatures for Cloudflare-to-origin TLS and build fully post-quantum-secure mutual TLS on that link. The company said the protection is effective only if organizations also remove trust in classical authentication paths to avoid downgrade attacks, and positioned the release as a key step toward its stated goal of full post-quantum security by 2029. Cloudflare also noted that post-quantum authentication for browser-facing WebPKI traffic will follow a different approach based on **Merkle Tree Certificates**. The rollout comes amid broader industry acceleration toward quantum-safe security. Cloudflare Radar has been tracking worldwide post-quantum encryption adoption, while Microsoft said the timeline for quantum risk is shifting and urged faster migration planning. Cloudflare said the new capability required changes across its Go-based control plane and **Pingora Origin** data plane, and disclosed that a **BoringSSL** upgrade triggered a June 10, 2026 incident when stricter `KeyUsage` enforcement caused compatibility problems before the issue was patched and resolved.
Jul 29, 2026