Why Cloudflare Added Post-Quantum Signatures Between Its CDN and Your Server

A browser does not always connect directly to a website

When you open a site that uses Cloudflare or another content delivery network (CDN), the request often passes through three points:

1. the user’s browser;
2. an intermediate Cloudflare node;
3. the website’s actual server.

Cloudflare may filter an attack, return a cached page, or forward the request. The path therefore usually has two separate connections: browser → Cloudflare and Cloudflare → website server.

The HTTPS indicator in a browser confirms a protected connection to Cloudflare. It does not tell the user what happens on the second leg. If that leg also uses HTTPS, Cloudflare separately validates the website server’s certificate.

Cloudflare has now added support for ML-DSA post-quantum digital signatures to this validation process.

What Cloudflare changed

On July 29, 2026, Cloudflare announced that two of its mechanisms can work with ML-DSA certificates and signatures.

• Custom Origin Trust Store gives Cloudflare a specific set of certificate authorities to trust when validating a website server.
• Authenticated Origin Pulls works in the opposite direction: the website server validates a certificate presented by Cloudflare.

The second case uses mutual TLS: Cloudflare validates the server, and the server also validates Cloudflare. This can help the server reject direct connections from unauthorized clients.

The announcement is specifically about authenticating the parties to a connection. It does not mean that all Cloudflare Internet traffic is already post-quantum.

ML-DSA in plain language

A digital signature is like a seal that cannot be reproduced correctly without a private key. One side presents a certificate and proves that it controls the corresponding key. The other side checks the signature, certificate validity, server name, and chain of trust.

ML-DSA is a new digital signature standard defined by FIPS 204. It was designed so that known attacks using a powerful quantum computer would not break the signature.

The important boundary is that ML-DSA does not encrypt traffic and is not a key-exchange algorithm. It proves authenticity. A complete post-quantum transition requires more than changing one signature algorithm.

Why test it now

Large-scale quantum attacks against TLS are not happening today. The practical reason to test early is to learn whether servers, proxies, libraries, and certificate-issuing systems understand the new format.

ML-DSA public keys and signatures are larger than commonly deployed classical alternatives. New TLS connections may therefore transfer more data and require additional computation.

A connection pool reduces how often a new handshake is required by reusing established connections. It does not make an individual handshake cheaper. A stable page after connections have warmed up is not enough to prove that the new algorithm causes no problems.

What can break

Cloudflare may support ML-DSA while another part of the path does not:

• a server or cryptographic library may not understand the format;
• the certificate issuer may be unable to create the required chain;
• a trust store may not contain the correct certificate authority;
• an intermediate proxy or inspection tool may reject the certificate;
• the system may silently fall back to a classical algorithm while the team records the test as successful.

Reading a certificate file is therefore not a complete test. Create a new connection and confirm which algorithm was actually used.

How to run a safe pilot

Prepare the test

1. Map the path. Show the browser-to-CDN and CDN-to-server connections separately. Record who validates whose certificate.
2. Choose a test hostname. Do not begin with all production traffic.
3. Test the valid case. A new connection should use the expected certificate, trust chain, and ML-DSA.
4. Create deliberate failures. The system should reject an untrusted, expired, or wrong-name certificate when policy requires it.

Measure the result

1. Compare measurements. Track TLS errors, new-handshake duration, request latency, CPU load, and memory use.
2. Increase traffic gradually. Define stop conditions before the rollout begins.
3. Verify rollback. Restore the old configuration and create a new connection. An existing pooled connection cannot prove that rollback worked.

What not to conclude

ML-DSA support between Cloudflare and a website server does not automatically change the browser-to-Cloudflare connection. It also does not prove that the entire TLS path is resistant to quantum attacks.

This is one focused step: a new way to verify a server or client on a specific connection. Its immediate value is not an urgent mass migration. It is a chance to test compatibility calmly before post-quantum algorithms become routine.

Sources

• Cloudflare — Post-quantum authentication to origins is now supported
• NIST — FIPS 204: Module-Lattice-Based Digital Signature Standard