Cloudflare adds post-quantum authentication to origins

We wrote last week about the gap in the post-quantum internet's progress: the browser-to-edge hop is largely migrated, but only about 4% of origin servers, the machines actually running your application behind the CDN, could negotiate post-quantum key agreement at all, and authentication had barely started anywhere. This is the vendor with the clearest view of that gap moving to close one half of it.

What actually shipped

• Authenticated Origin Pulls (AOP): upload an ML-DSA client certificate, and Cloudflare presents it during the mTLS handshake to your origin, so your origin can verify the request genuinely came from Cloudflare using a post-quantum signature.
• Custom Origin Trust Store (COTS): upload an ML-DSA certificate authority, and Cloudflare trusts it when validating your origin server's certificate under Full (strict) encryption mode, so the certificate proving your origin's identity can itself carry a post-quantum signature.
• Three FIPS 204 parameter sets: ML-DSA-44, ML-DSA-65, and ML-DSA-87, trading signature and key size for security margin, with ML-DSA-44 recommended as the most performant default.

Why authentication, not just key exchange, is the harder half

Key exchange migrated first because it is comparatively easy to swap: negotiate a different group in the handshake, and the session is protected. Authentication is harder because it runs through certificate chains, certificate authorities, and roots that are expensive to reissue and risky to rotate under load, which is exactly why ML-KEM became a browser default two years before post-quantum signatures showed up anywhere near production TLS. AOP and COTS are a narrower, more tractable slice of that problem: they let an operator swap the certificates on one specific, self-controlled hop, Cloudflare to origin, without touching public CA infrastructure or a browser's trust store at all.

That narrowness is the point. It gives teams a real place to test ML-DSA certificates in production traffic today, on a connection they fully control, ahead of the much harder work of migrating public-facing certificate authorities. It also lands the same month Go 1.27 put ML-DSA in its standard library: the tooling to generate these certificates and the infrastructure to serve them are arriving on the same timeline.

The point

If Cloudflare sits in front of your infrastructure, this is worth testing on a non-production origin this quarter: generate an ML-DSA-44 certificate, configure AOP or COTS, and confirm your origin's TLS stack actually negotiates it. And whether or not you use Cloudflare, the underlying question is the same one every post-quantum migration runs into: you cannot decide which hops need this until you know where your certificates and their signature algorithms actually live, which is a cryptographic inventory problem before it is a configuration problem.

References

• Post-quantum authentication to origins is now supported (blog.cloudflare.com) - Cloudflare's announcement, July 29, 2026.
• Post-quantum between Cloudflare and origin servers (developers.cloudflare.com) - setup documentation for AOP and COTS with ML-DSA.
• FIPS 204, ML-DSA (csrc.nist.gov) - the standard behind the certificates.
• quantakrypto: post-quantum key exchange is now the web's default - the origin gap this closes part of.
• quantakrypto: Go 1.27 brings post-quantum signatures to the stdlib - the tooling landing on the same timeline.
• quantakrypto: build a CBOM with qScan - finding which hops still need this.