Post-Quantum Planning Starts Before the Threat Is Visible
Post-quantum authentication is real engineering, but the deadline is not the quantum computer. It is harvest-now/decrypt-later and the trust you still accept.
TL;DR • Cloudflare now supports post-quantum authentication on the Cloudflare-to-origin connection via ML-DSA (FIPS 204) in Authenticated Origin Pulls and Custom Origin Trust Store, after post-quantum encryption landed for visitors in 2022 and for origins in 2023. • The real deadline is harvest-now/decrypt-later: attackers copy encrypted traffic today and decrypt it with a future quantum computer, so the migration timeline is set by the data you transmit now, not by when a quantum machine arrives. • The hard part is removing trust, not adding it: a verifying party that still accepts quantum-vulnerable mechanisms stays open to downgrade attacks. For small estates, Cloudflare Tunnel is the pragmatic path — with the vendor-dependency trade-off stated openly.
What happened
Cloudflare crossed a milestone most companies will not notice and should: Authenticated Origin Pulls (AOP) and Custom Origin Trust Store (COTS) now support post-quantum authentication, via ML-DSA, the Module-Lattice-Based Digital Signature Algorithm standardized in FIPS 204. The company is explicit about the timeline behind it: "Cloudflare is targeting 2029 for full post-quantum security," and this is the first milestone on that road.
The context matters. Post-quantum encryption was enabled for the visitor-to-Cloudflare connection in 2022 and for the Cloudflare-to-origin connection in 2023. Authentication is the missing half, and it protects against a different attack: an attacker who uses a quantum computer to forge classical credentials and impersonate your origin. Cloudflare adds ML-DSA support for all FIPS 204 parameter sets — ML-DSA-44, ML-DSA-65 and ML-DSA-87 — with ML-DSA-44 the recommendation for most applications because it "attains a comfortable NIST category 2 security strength." On the browser side, the company is collaborating with Google and the IETF on Merkle Tree Certificates, with initial deployments targeting 2027.
Netics' take
The origin connection is the half everyone forgets. When a visitor loads a site behind Cloudflare, two connections exist: one from the browser to Cloudflare, and one from Cloudflare to the origin server that actually holds the content. Most TLS work of the last decade — Let's Encrypt, HSTS, certificate automation — focused on the visible first half. The second half is where the exposure lives, and it is the one that just got its authentication upgrade.
The source of urgency is not the promise of a quantum computer arriving someday. It is harvest-now/decrypt-later, which Cloudflare describes as a threat "where an attacker quietly stockpiles your encrypted data with the hope of decrypting it in the future with a quantum computer." An attacker copying your traffic this year does not need to wait to start. For anything with a long shelf life — contracts, customer records, credentials, archived backups — data exfiltrated today is a liability for decades. That reframes the migration. The question is not when quantum breaks RSA; it is what you are transmitting right now that will still matter twenty years from now. For regulated sectors in Europe, where data-retention obligations run for years, the answer is usually "most of it."
There is one tension worth naming. Cloudflare publishes urgency about harvest-now while its own roadmap runs to 2029 for full coverage and 2027 for the browser-side certificate work. Both things can be true; it is still fair to ask why the migration takes years when the threat is already present.
The hard part is removing trust, not adding it. Cloudflare is explicit: "The fix: the verifying party must remove trust in quantum-vulnerable authentication mechanisms." Adding post-quantum support to both sides is necessary but not sufficient — if your origin still accepts any quantum-vulnerable mechanism, an on-path attacker can force a downgrade and forge classical credentials. A certificate store that trusts ML-DSA and RSA is not post-quantum; it is RSA with an extra option. This is the same boring access-control pattern we keep coming back to — the upgrade is only as strong as the weakest thing your systems still accept, the same logic as fixing agent permissions before buying platforms.
One honest note before the practical advice: Cloudflare's suggested path for legacy origins is Cloudflare Tunnel, and this is Cloudflare recommending Cloudflare — the same vendor-pitch move we called out in the Citrix AI-governance post. We use Tunnel anyway on our own Proxmox estate, for the blog and management traffic, because for a small operation it genuinely is less to authenticate than a stack of origin certificates. Just know what you are trading: a certificate migration for a dependency on the tunnel provider. I spent years managing certificates on Citrix Delivery Controllers; the trust-store question is the one I check first, because it decides whether any of the rest matters.
What this means for SMBs
The certificate mechanics — FIPS 204 seed-only keys, OpenSSL 3.5, per-hostname AOP configuration — matter if you run a large origin estate. For most companies, two things matter more.
First, know what your origin actually accepts. If your origin trusts a default CA store, post-quantum on the Cloudflare side does nothing until you remove the classical trust path. That is a mapping exercise, not a certificate exercise. Second, consider removing the origin from the equation entirely: Cloudflare Tunnel forwards traffic to origins "by forwarding traffic over a tunnel secured with post-quantum encryption (and post-quantum authentication in the works)," and it does not require upgrading legacy origin systems. A real, defensible choice for a small operation. Before you call the migration done:
- Map every origin connection: what terminates TLS at your origin, and what trust store it uses
- Remove classical trust paths where post-quantum support exists — the downgrade is the vulnerability
- Identify anything with a 10-year shelf life: it is the harvest target
- Consider tunneling instead of certificate migrations for legacy origins
- Re-run the audit after every infrastructure change; trust stores drift
Bottom line
Post-quantum authentication is real engineering, and Cloudflare shipped it cleanly. The mistake would be treating it as a feature to enable. The migration is a trust-removal project, and the deadline is not the quantum computer — it is the data you are transmitting today. Book a free 30-minute audit and we will help you map what your origin still trusts, and remove it.
Source: Post-quantum authentication to origins is now supported — blog.cloudflare.com, 2026-06-17. Commentary by Netics.
Explore Netics for practical infrastructure and AI operations guidance.