Infrastructure

Post-Quantum Now Needs OpenSSL 3.5 on Your Origin

Cloudflare switched on post-quantum authentication to customer origin servers on 29 July. It is the first part of its post-quantum work that does nothing until you change a machine you run yourself.

InfrastructureBy Servola Tech Desk2026-07-295 min read

AI-assisted, edited by humans. | Editor-in-Chief: Leon Soliman | Editorial standards

Post-Quantum Now Needs OpenSSL 3.5 on Your Origin

Key takeaways

Cloudflare enabled post-quantum authentication between its network and customer origin servers on 29 July. It is the first piece of its post-quantum programme that stays switched off until you change your own machine: the origin has to present an ML-DSA certificate, and generating one needs OpenSSL 3.5.0 or later on that server.
Two products carry it. Authenticated Origin Pulls now accepts ML-DSA at the per-zone and per-hostname levels, with global-level support still to come, and the Custom Origin Trust Store will now hold certificate authorities that sign with ML-DSA.
Cloudflare recommends ML-DSA-44, the smallest of the three parameter sets in FIPS 204, on performance grounds. It sits at NIST security category 2, while ML-DSA-65 at category 3 is the more common default recommendation. That is a choice your security team makes, not one it inherits.
Cloudflare took a production incident on 10 June 2026 during its own rollout, caused by KeyUsage enforcement in the certificates. Plan this as certificate plumbing with a staging step, not as a setting you flip on a Friday.

The first post-quantum step your CDN cannot take for you

An engineer who opens Cloudflare's post-quantum status page has been able to read good news for three years without doing anything. Post-quantum encryption on the leg between a visitor's browser and Cloudflare's edge has been on by default since 2023, using the hybrid key agreement now written as X25519MLKEM768, and no customer configured it. It arrived the way weather arrives.

On 29 July that stopped being the shape of the work. Cloudflare announced post-quantum authentication on the other leg, between its network and the origin servers its customers run, using ML-DSA signatures. Authentication is not something a proxy can do on your behalf, because the thing being authenticated is your server. To use it, that server has to hold and present a certificate signed with an algorithm it has probably never seen.

What actually shipped

Two products carry the change. Authenticated Origin Pulls is the mechanism by which Cloudflare presents a client certificate to your origin, so the origin can refuse connections that did not come through Cloudflare, and it now accepts ML-DSA at the per-zone and per-hostname configuration levels. Global-level support is stated as coming later. The Custom Origin Trust Store, which lets a customer upload its own certificate authorities rather than rely on the public set, will now accept authorities that sign with ML-DSA, so an origin certificate can be validated against a post-quantum signer.

All three parameter sets from FIPS 204 are supported: ML-DSA-44, ML-DSA-65 and ML-DSA-87. The key agreement on the connection remains the hybrid X25519MLKEM768. In other words the confidentiality half of this hop was already handled; what changed is the half that proves who is at each end.

Five things that have to change on a machine you own

The requirement list is short and every item lands on your side of the connection. You need OpenSSL 3.5.0 or later on the origin to generate an ML-DSA certificate chain at all. The certificate has to be uploaded in the seed-only encoding that FIPS 204 defines, which is not the encoding most tooling produces by habit. The origin web server, NGINX in Cloudflare's own example, has to be configured either to present the ML-DSA certificate or to verify the client certificate against it. If you use the Custom Origin Trust Store, the zone's SSL/TLS mode has to be Full (strict). And trust in the quantum-vulnerable authentication mechanism has to be removed afterwards, because leaving it in place lets an attacker negotiate the old path and makes the new one decorative.

None of that is exotic. OpenSSL 3.5.0 was released on 8 April 2025 as a long-term support line carrying updates until April 2030, and it was the first release to ship the three NIST post-quantum standards natively. The difficulty is not the version number. It is that the origin is frequently the least-visited machine in the estate: an appliance, a vendor-managed box, a virtual machine nobody has rebuilt since it was provisioned, or a load balancer whose TLS stack is somebody else's problem until it is not.

Cloudflare's own rollout is the evidence for taking a staging step. On 10 June 2026 it had a production incident during this deployment, caused by KeyUsage enforcement in the certificates. That is a certificate-extension detail, hit by a team that builds TLS libraries for a living, on infrastructure they control end to end. A mid-sized company doing the same change on a Thursday afternoon should assume it will find something similar.

Why the recommended parameter set is the smallest one

Cloudflare recommends ML-DSA-44 for most applications, describing it as the most performant option. That is a defensible engineering call, and it is also the smallest of the three sets in FIPS 204, sitting at NIST security category 2. The more common default recommendation elsewhere is ML-DSA-65, at category 3. Post-quantum signatures are large compared with the ones they replace, and on a hop that carries every request between edge and origin, the size difference is a real latency and bandwidth cost rather than a theoretical one.

The point for an owner is that this is now a decision with your name on it. If your security policy or your auditor has already settled on category 3 for signing, adopting the CDN's recommendation quietly creates an exception you will have to explain. Write the parameter set down, with the reason, before someone else discovers the mismatch during a review.

The deadline that is real and the one that is not

Be clear about the urgency, because the two halves of post-quantum have genuinely different clocks. Encrypted traffic recorded today can be decrypted by a future machine, which is what makes key agreement a present-tense problem. A signature cannot be forged backwards in the same way: nobody will use a quantum computer in 2032 to retroactively fake a handshake that happened this morning. The reason to start now is not that you are being attacked, it is the length of the queue behind the change, which runs through certificate authorities, hardware, vendor appliances and every origin you forgot you had.

Cloudflare has put dates on its own queue: full post-quantum security across its products by 2029, and an initial deployment of Merkle Tree Certificates on the visitor-facing side targeted for 2027. Those are its deadlines, not yours. Yours is whichever audit next asks what protects the connection between your CDN and your servers, and the honest answer today, for almost everyone, is classical cryptography with a supported replacement sitting unused.

Frequently asked questions

We are behind Cloudflare and its page says post-quantum. Are we not already covered?

Only on the visitor-facing leg. Post-quantum encryption between a browser and Cloudflare's edge has been on by default since 2023 and needed nothing from you. The connection from Cloudflare to your own origin authenticated with classical cryptography until this release, and it will continue to do so until you install an ML-DSA certificate on that server. The status page describes Cloudflare's side of the path, not yours.

What is the minimum work to try this without breaking a live site?

Take one non-critical hostname, since Authenticated Origin Pulls now supports ML-DSA at the per-hostname level. Confirm the origin runs OpenSSL 3.5.0 or later, generate the chain in the FIPS 204 seed-only encoding, configure the web server to present or verify it, and set the zone to Full (strict) if you are using the Custom Origin Trust Store. Leave the classical path trusted until the new one works, then remove it, because leaving both means an attacker can choose the old one.

Which parameter set should we standardise on?

Decide it deliberately rather than accepting the default. Cloudflare recommends ML-DSA-44, the smallest and fastest of the three in FIPS 204, at NIST security category 2. ML-DSA-65 at category 3 is the more common recommendation elsewhere and is what many internal policies already name. On a high-volume origin hop the size difference is measurable, so pick the level, record why, and make sure the same answer appears in your policy and on your servers.

The interesting thing about this release is not the algorithm, which has been standardised since 2024, but where the work landed. For three years post-quantum arrived at most companies as something a supplier had already done, which trained people to treat it as a procurement question. This is the first step that stops at the edge of the estate and waits. Every hop that a vendor cannot upgrade on your behalf is a hop that will still be classical in 2029 unless somebody owns it by name. Find out today which of your origins can even generate an ML-DSA certificate. That single answer tells you how long the rest of this will take.

CloudflareML-DSAOpenSSLPost-quantum cryptographyOrigin serversmTLSFIPS 204

Cloudflare Meters the Web for Machines

Cloudflare's Monetization Gateway uses x402 and stablecoins to charge AI agents per request. What EU owners must weigh on MiCA, PSD2 and VAT first.

3 min read

Decisions

OpenSSL Fixed It in June Without a CVE

A remote memory-exhaustion flaw was fixed on 9 June with no CVE and no advisory. Severity-triggered patching could not see it. Schedule-based patching caught it by accident.

5 min read

Law & Regulation

The EA Buyout Now Hinges on Brussels

The largest take-private in history has cleared EA shareholders and US antitrust. The last real gate is the EU - and not classic merger review, but the Foreign Subsidies Regulation, facing its first blockbuster test.