Intel / blog

Post-quantum authentication to origins is now supported

Source: blog.cloudflare.com
Author: Cloudflare
Date: Published Jul 29, 2026

Context

Cloudflare added post-quantum signatures to the connection between its network and a customer's origin server. This addresses authentication: proving which server is on the other end. Its Custom Origin Trust Store can verify an origin's certificate using ML-DSA signatures, while supported Authenticated Origin Pulls configurations let the origin verify Cloudflare in return. The announcement concerns this backend connection, not completion of the browser-facing migration.

Downgrade resistance also depends on configuration. If either verifier still accepts quantum-vulnerable credentials, an attacker capable of forging them could use that alternative. Cloudflare therefore says those trusted fallbacks must be removed when requiring post-quantum authentication.

Key takeaways · AI-distilled

The threat model moved. Years of post-quantum work targeted eavesdroppers stockpiling traffic to decrypt later; the newer worry is a quantum attacker forging classical credentials and impersonating servers in real time.
Post-quantum support on both ends is not enough. If the verifier still trusts any classical credential, an on-path attacker just forges that one instead — you have to actually remove the old trust anchors.
Cloudflare can afford bulky ML-DSA signatures on the origin hop because it pools connections: one handshake's cost is amortized over many requests, so the compact certificate designs needed for browsers are unnecessary here.
Because Cloudflare and its customers already share an account relationship, origin authentication can run on a custom PKI — no intermediate certificates, no Certificate Transparency, and no waiting on public WebPKI timelines.
Of the three FIPS 204 sizes, ML-DSA-44 is the recommended default: fastest, at NIST category 2 strength. Keys must be uploaded in the seed-only encoding, which needs OpenSSL 3.5.0 or later to generate.

Key quotes

“We instead implemented the necessary functionality in Cloudflare’s CIRCL library to patch in support.”

“we have an admission to make: we snoozed Pingora Origin’s update to BoringSSL for four years, instead maintaining an internal fork to patch in additional functionality as needed.”

“Now, BoringSSL lives up to its name: over the past several years, there have been no CVEs or major changes.”

“The result was that even after testing the changes for weeks and a very slow release rollout looking for just this sort of regression, a small number of customers’ certificates were deemed invalid after the change, leading to an incident on June 10, 2026.”

Read the source blog.cloudflare.com