Run openssl genpkey -algorithm mldsa44 on a stock Ubuntu 24.04 box and it fails. Unknown algorithm, because that release ships OpenSSL 3.0 and this wants 3.5.0. One command, and you already know most of what Cloudflare's 29 July post means for you: post-quantum authentication between Cloudflare and your origin server is live, on Authenticated Origin Pulls and Custom Origin Trust Store, using ML-DSA certificates you issue yourself from a CA you run. No public certificate authority anywhere in it. The cryptography has shipped. The tooling mostly has. The piece that turns this from a project into a version bump, native ML-DSA in Go 1.27, lands next month. So the real question is whether this is a this-quarter job or a line in the backlog, and that depends on things the announcement does not lead with.
The short answer
Cloudflare turned on post-quantum authentication for the edge-to-origin connection. Authenticated Origin Pulls takes ML-DSA client certificates, Custom Origin Trust Store takes ML-DSA certificate authorities, and you generate both yourself with OpenSSL 3.5.0 in seed-only key encoding. It is a private PKI, so nothing waits on the WebPKI. What it does not do is protect the visitor-facing leg, which still runs on classical signatures until Merkle Tree Certificates arrive around 2027.
The half of the path nobody looks at
Most post-quantum coverage is about browsers. Harvest now, decrypt later, the padlock, your certificate chain. Fine. But when a visitor hits a site behind Cloudflare there are two TLS connections, and the second one, edge to origin, is the one your team actually controls and the one that carries the same plaintext.
That leg has had post-quantum encryption since 2023. Authenticity is what just landed.
Image: Cloudflare, from the 29 July 2026 announcement by Luke Valenta and Kevin Guthrie.
Cloudflare frames it as the first milestone on a stated path to full post-quantum security by 2029, and the reasoning for why this leg went first is more interesting than the milestone. On the origin connection Cloudflare is the client, not the server. It pools connections, so the cost of a fat drop-in signature gets amortised across a lot of requests. And there is already a trust relationship, your account, which means the whole thing can run on a custom PKI instead of queuing behind the WebPKI. That is why ML-DSA to origin arrived years before ML-DSA in your browser. We went through why ML-DSA is the signature the industry keeps landing on in post-quantum TLS and the case for shipping ML-DSA, and the size trade-off there is the same one being amortised here.
What you actually configure
Two products, and they solve opposite directions of the same handshake.
Custom Origin Trust Store is Cloudflare verifying you. It replaces the default set of publicly trusted CAs for your zone with CAs you control, and it now accepts ML-DSA CAs, so Cloudflare will trust an origin certificate chaining to yours. It needs Full (strict) mode and Advanced Certificate Manager.
Authenticated Origin Pulls is you verifying Cloudflare. Cloudflare presents a client certificate to your origin so you can reject anything that did not come through the network, and the per-zone and per-hostname levels now take ML-DSA certificates and keys. AOP is free on all plans. Run both and you have mutual TLS that is post-quantum in both directions.
The generation step is where people will get stuck, and it is worth reading carefully before you start.
Two gotchas in that sequence, both documented and both easy to hit. The private key has to be in the FIPS 204 seed-only encoding, and Cloudflare’s upload endpoints reject the expanded-key format outright. And you cannot verify the real handshake from outside, because it happens server to server. You test each side separately, then confirm by logging the client certificate serial on the origin. In NGINX that is a one-line log_format with $ssl_client_serial, and a request through Cloudflare should show the serial of the certificate you uploaded.
The parts the headline skips
Here is the honest read, and it cuts both ways.
The downgrade line is the one I would put in front of whoever signs off. Uploading a CA to COTS wipes the default trust store for that zone. Leave a classical CA trusted alongside your shiny ML-DSA one and an attacker who can forge classical credentials still walks straight in, which means a partial migration here is much closer to worthless than to half done. Cloudflare says it plainly in the config guide. It is the kind of thing that gets skimmed.
There is also a small confession in the post that I found more useful than the feature itself. Pingora Origin, the service handling Cloudflare’s origin-bound traffic, had not updated BoringSSL in four years. They ran an internal fork instead, because BoringSSL had been quiet enough to make that look safe. Taking four years of commits at once brought in stricter KeyUsage enforcement, which is correct per the specifications and promptly invalidated a small number of customer certificates, causing an incident on 10 June 2026. Rolled back, patched to keep tolerating RSA certificates with technically invalid KeyUsage, then shipped.
Anyone who has deferred a dependency bump on something stable knows that shape. The bill arrives all at once.
Should you do this now
Depends entirely on your origin’s TLS library.
If you terminate on NGINX with OpenSSL 3.5.0 or later, this is a contained afternoon: generate two chains, upload, flip SSL mode to Full (strict), add ssl_verify_client on, then read your logs. If you are on a distribution OpenSSL, budget for that upgrade first and treat it as the actual work. If your origin is a Go service, waiting for Go 1.27 in August is the sane call, because after that it genuinely is a version bump plus a certificate.
Worth being clear about the threat model, though. This defends against an attacker who can forge classical credentials with a quantum computer, which nobody can do today. Cloudflare’s own stated reason for moving authentication up the queue is that recent progress in quantum computing and cryptanalysis pulled the timelines forward. That is a judgement call about the future, not a live incident, and it is fair to plan it as a 2027 deliverable rather than a Friday emergency. What I would not do is nothing at all, because the OpenSSL and Go version floors mean the prerequisite work has a long lead time even when the config change is small.
If you just want to see what your current certificate chain is signed with before any of this, our SSL certificate checker reads it back without an install. And if TLS 1.3 is still on your to-do list, that is the harder prerequisite here, since ML-DSA to origin assumes it: TLS 1.2 versus TLS 1.3 covers what changes.
Sources
Cloudflare’s announcement, Post-quantum authentication to origins is now supported (29 July 2026), by Luke Valenta and Kevin Guthrie. The configuration reference, Post-quantum between Cloudflare and origin servers, in the Cloudflare SSL/TLS developer docs. The original ship note, Post-quantum ML-DSA certificates for Authenticated Origin Pulls and Custom Origin Trust Store (17 June 2026), which is where the capability quietly appeared six weeks before the blog post explained it.
Frequently asked questions
What did Cloudflare actually enable on 29 July 2026?
Post-quantum authentication on the Cloudflare-to-origin connection. Two products changed: Authenticated Origin Pulls now accepts ML-DSA client certificates that Cloudflare presents to your origin during the mTLS handshake, and Custom Origin Trust Store now accepts ML-DSA certificate authorities that Cloudflare will trust when validating your origin certificate under Full (strict). Combined with the X25519MLKEM768 key agreement already deployed to origins since 2023, that makes the edge-to-origin leg post-quantum for both confidentiality and authenticity.
Which ML-DSA parameter set should I pick?
ML-DSA-44, unless you have a compliance reason not to. Cloudflare supports all three FIPS 204 sets and recommends ML-DSA-44 in writing, describing it as the most performant option while attaining a comfortable NIST category 2 security strength. ML-DSA-65 and ML-DSA-87 are accepted too, and they cost you more bytes on the wire for security levels most origin deployments do not need.
Why does OpenSSL reject the mldsa44 algorithm on my server?
Because you are almost certainly below 3.5.0. ML-DSA landed in OpenSSL 3.5.0, and long-term distributions have not caught up: Ubuntu 24.04 LTS ships the 3.0 series. You need 3.5.0 or later both on the workstation generating the certificates and on the origin terminating TLS. BoringSSL got post-quantum authentication support in April 2026, and Go picks up native ML-DSA in 1.27, expected August 2026.
Does this protect visitors to my site?
Not yet, and that distinction matters. A request through Cloudflare uses two connections: visitor to Cloudflare, and Cloudflare to your origin. This announcement covers only the second one. Post-quantum authentication on the visitor-facing leg depends on Merkle Tree Certificates, a design Cloudflare is developing with Google and others at the IETF, with initial deployments targeting 2027. Post-quantum encryption, as opposed to authentication, has been on for both legs since 2022 and 2023.
What is the downgrade trap with Custom Origin Trust Store?
Uploading a CA to COTS replaces the default publicly trusted trust store for that zone entirely. If you leave any quantum-vulnerable authentication path trusted, an on-path attacker who can forge classical credentials still gets in, and your post-quantum certificate has bought you nothing. Cloudflare is explicit: only upload post-quantum CAs if you want to avoid downgrade attacks. A partial migration here is closer to no migration than to a finished one.
Is any of this going to cost me money?
Authenticated Origin Pulls is free on every Cloudflare plan level, so the AOP half costs nothing beyond your time. Custom Origin Trust Store requires Advanced Certificate Manager to be enabled, which is a paid add-on. Cloudflare has previously committed to shipping post-quantum upgrades to all customers including free plans, but COTS specifically sits behind ACM today.
