Cloudflare Post-Quantum Setup

If your site is behind Cloudflare, post-quantum support is not one switch. The visitor-to-edge connection, the edge-to-origin connection, and origin authentication are separate TLS capabilities. Each can be in a different migration state.

Cloudflare has also deployed ML-DSA-44 DNSSEC validation on 1.1.1.1. That is a separate DNS authenticity layer, not part of the TLS configuration described here. See our post-quantum DNSSEC deployment guide for the signature-size and Internet-Draft limitations.

Cloudflare accepts the hybrid X25519MLKEM768 key agreement from compatible visitors. For origin pulls, Cloudflare’s Automatic Key Exchange detects what an origin supports and prefers X25519MLKEM768 when both classical and post-quantum options are available. ML-DSA authentication is a separate, opt-in configuration through Authenticated Origin Pulls (AOP) and Custom Origin Trust Store (COTS).

This guide explains what is automatic, what still depends on your infrastructure, and how to verify each layer without claiming more than a test proves.

Cloudflare PQC capability map

Layer	Current Cloudflare behavior	What you control	PQ mechanism	Important limitation
Visitor → Cloudflare edge	Cloudflare accepts it automatically when a compatible client offers it	Client/browser support and traffic measurement	Hybrid `X25519MLKEM768` key agreement	Public edge-certificate signatures are still classical
Cloudflare edge → origin	Automatic Key Exchange is enabled; Cloudflare prefers the hybrid group when the origin supports it	Origin TLS 1.3 stack, supported groups, and preference	Hybrid `X25519MLKEM768` key agreement	Classical fallback remains available when the origin does not support the hybrid group
Cloudflare authenticates to origin	Optional through zone-level or per-hostname AOP	ML-DSA client certificate, trusted CA, and strict verification at the origin	ML-DSA signature in mTLS	Global AOP uses a Cloudflare-provided certificate and is not configurable for this workflow
Cloudflare authenticates origin	Optional through COTS with Full (strict) mode	ML-DSA CA and origin certificate configuration	ML-DSA certificate signature	COTS replaces the zone’s default public CA trust; downgrade-safe policy matters
`cloudflared` → Cloudflare	Cloudflare Tunnel supports PQ key agreement	Deploying and maintaining the tunnel	Hybrid `X25519MLKEM768` key agreement	Cloudflare documents PQ signatures as not yet supported on this path

Key agreement protects the confidentiality of captured traffic against a future cryptographically relevant quantum computer. Authentication answers a different question: whether the peer is who it claims to be. A connection with hybrid key agreement can still use a classical certificate signature.

Visitor to Cloudflare edge

For proxied HTTPS hostnames, Cloudflare supports X25519MLKEM768 on inbound TLS 1.3 connections. A compatible browser or client offers the hybrid group and Cloudflare can select it without a per-zone PQ toggle.

This protects the visitor-to-Cloudflare leg against harvest-now-decrypt-later attacks. It does not mean:

the Cloudflare edge certificate uses a post-quantum signature;
the separate origin connection negotiated the same group;
every client used the hybrid group;
the complete application path has post-quantum authentication.

Cloudflare documents ClientTLSKeyExchangeGroup in the http_requests Logpush dataset and Log Explorer for measuring which key-agreement group inbound requests used. That field describes the visitor-to-edge connection only.

Cloudflare edge to origin

The older model of manually enabling an origin-PQ setting is no longer accurate. Cloudflare now uses Automatic Key Exchange to learn an origin zone’s preferred key agreement.

Automatic Key Exchange is on for existing zones and defaults on for new zones. When the origin supports both classical and post-quantum choices, Cloudflare prefers X25519MLKEM768. Cloudflare applies the learned preference across the zone and continues to advertise other permitted groups. An origin can request another key share with a TLS 1.3 HelloRetryRequest.

The practical requirement is therefore on the origin side:

Terminate TLS 1.3 with a library and server configuration that supports X25519MLKEM768.
Confirm that the origin accepts and preferably selects the hybrid group.
Check any load balancer, proxy, firewall, or other middlebox in front of the origin for compatibility with the larger hybrid TLS handshake.
Keep a tested classical path while introducing the capability unless your policy explicitly requires rejection of classical key agreement.

OpenSSL 3.5 and later supports X25519MLKEM768; it is one option, not the only compatible TLS implementation. The old Origin Post-Quantum Encryption API may still exist, but Cloudflare says requests to it are no-ops and do not change current behavior.

Classical fallback is not itself a failed connection. It preserves interoperability with an origin that cannot negotiate the hybrid group. It does mean that the affected connection did not receive ML-KEM protection, so teams with a strict requirement need monitoring and an explicit enforcement design rather than an assumption that preference equals enforcement.

Origin authentication with ML-DSA

Hybrid key agreement does not replace certificate authentication. Cloudflare supports ML-DSA for two origin-facing features:

Authenticated Origin Pulls (AOP): Cloudflare presents an ML-DSA client certificate so the origin can authenticate Cloudflare during mTLS.
Custom Origin Trust Store (COTS): Cloudflare trusts an ML-DSA certificate authority when validating the origin certificate under Full (strict) mode.

These can be deployed independently. Using both addresses authentication in both directions on the Cloudflare-to-origin connection, but only when each verifier is configured to require the intended ML-DSA trust path.

Requirements and key format

Cloudflare’s current documented workflow requires:

a TLS 1.3 origin stack with ML-DSA support;
OpenSSL 3.5 or later on the workstation used to generate the documented certificates;
an ML-DSA-capable TLS library at the origin;
ML-DSA private keys in seed-only encoding when uploaded to Cloudflare.

Cloudflare currently rejects expanded ML-DSA private-key encodings at its upload endpoints. Its example generation workflow uses ML-DSA-44 and the OpenSSL provider parameter:

openssl genpkey \
  -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out leaf.key

Follow Cloudflare’s complete certificate-generation procedure rather than treating this single command as a deployable certificate workflow.

AOP configuration boundary

ML-DSA client certificates are supported for zone-level and per-hostname AOP. You generate the required CA and leaf material, configure the selected AOP scope, and install the CA certificate at the origin so it can verify the client certificate Cloudflare presents.

The global AOP scope is different: it uses a Cloudflare-provided certificate and is not configurable for this ML-DSA upload workflow. There is no general dashboard step that generates a “Post-Quantum (ML-DSA)” origin certificate for you.

COTS configuration boundary

For COTS, upload the ML-DSA CA that should authenticate the origin and serve a matching ML-DSA leaf certificate from the origin under Full (strict) mode.

This change needs careful rollout. Cloudflare warns that configuring COTS replaces the default publicly trusted certificate authorities for that zone. The origin certificate chain, rollback procedure, and availability impact should be tested before production enforcement.

Avoid authentication downgrade

Presenting an ML-DSA certificate is insufficient if the verifier still accepts an unintended classical certificate path. To make the authentication property meaningful:

the origin must require the intended ML-DSA client certificate for AOP;
the COTS configuration must trust only the intended post-quantum CA path;
rollback must be deliberate rather than an unnoticed downgrade.

This is an authentication-policy decision, separate from whether X25519MLKEM768 was negotiated for key agreement.

Cloudflare Tunnel and Cloudflare One

Cloudflare Tunnel creates an outbound TLS 1.3 connection from cloudflared to Cloudflare’s network. Cloudflare documents X25519MLKEM768 key agreement on this path, so a tunnel can provide a PQ-protected origin connection without exposing and upgrading a public origin TLS endpoint in the same way.

The boundary remains important: Cloudflare currently lists post-quantum signatures as not yet supported for Cloudflare Tunnel authentication. The tunnel’s hybrid key agreement should not be described as ML-DSA authentication.

The Cloudflare One Client, formerly WARP, likewise uses TLS 1.3 with hybrid ML-KEM for its MASQUE connection to Cloudflare. Combining PQ-capable on-ramps and off-ramps can protect traffic across public-network segments, but that does not automatically migrate the application’s own identities, certificates, stored data, or internal service connections.

How to verify each layer

1. Measure visitor-to-edge negotiation

Use Cloudflare’s ClientTLSKeyExchangeGroup field in Logpush or Log Explorer and look for X25519MLKEM768.

This proves: the recorded visitor-to-edge TLS connection used the hybrid group.

This does not prove: the edge-to-origin connection used it, or that either connection used a post-quantum signature.

2. Test origin support and preference

Cloudflare recommends the BoringSSL bssl client to test the origin directly:

bssl client -connect origin.example.com:443 -curves X25519MLKEM768

Check that the handshake output identifies X25519MLKEM768 as the negotiated group.

This proves: the tested origin endpoint can negotiate the hybrid group with that client configuration.

This does not prove: a particular production Cloudflare-to-origin request negotiated it. It also does not test ML-DSA authentication.

3. Test the ML-DSA origin configuration

After configuring the AOP/COTS certificate material, Cloudflare documents a direct OpenSSL 3.5+ test using the appropriate CA, client certificate, and private key:

openssl s_client \
  -connect origin.example.com:443 \
  -servername origin.example.com \
  -CAfile ca.crt \
  -cert leaf.crt \
  -key leaf.key \
  -brief

The expected output includes Signature type: mldsa44 and Negotiated TLS1.3 group: X25519MLKEM768.

This proves: the directly tested endpoint and supplied credentials can complete the configured ML-DSA-authenticated handshake while negotiating the hybrid group.

This does not prove: every Cloudflare origin pull uses that path, that classical alternatives are rejected, or that other application and internal-network legs have migrated.

What a Cloudflare deployment still does not establish

Even after these changes, avoid describing an entire workload as “quantum safe.” A defensible status report should record capabilities per connection:

which connections negotiate hybrid PQ key agreement;
which connections use ML-DSA authentication;
whether classical fallback is permitted;
what telemetry or test evidence supports the status;
which internal and third-party connections remain classical.

Public WebPKI certificates presented by Cloudflare to visitors still use classical signatures. Cloudflare’s product matrix lists post-quantum visitor-to-edge signatures as planned. Application-level signing, stored-data protection, identity systems, and non-Cloudflare network paths remain separate migration work.

Practical rollout checklist

Measure visitor-to-edge key-agreement adoption rather than assuming every client supports it.
Inventory the TLS termination and middleboxes on the origin path.
Add and directly test X25519MLKEM768 support at the origin.
Let Automatic Key Exchange learn the origin capability and monitor actual behavior where telemetry is available.
If PQ authentication is required, design AOP and/or COTS as a separate certificate project.
Generate Cloudflare-compatible seed-only ML-DSA keys and test certificate chains before enforcement.
Define classical fallback and rollback policy explicitly.
Record evidence per connection instead of assigning one PQ status to the entire domain.

FAQ

Do I need to enable post-quantum key agreement in the Cloudflare dashboard?

Not for visitor-to-edge key agreement, and not through the old manual origin-PQ model. Cloudflare accepts compatible visitor handshakes and uses Automatic Key Exchange for origins. Your origin must still support X25519MLKEM768 for that leg to negotiate the hybrid group.

Does Cloudflare automatically make my origin post-quantum?

No. Cloudflare can detect and prefer the hybrid group, but it cannot add support to an origin TLS stack that lacks it. Authentication also remains a separate configuration.

Does ML-DSA replace ML-KEM?

No. ML-KEM contributes to key establishment; ML-DSA provides digital signatures. On the origin path, X25519MLKEM768 is the hybrid key-agreement group, while ML-DSA can be used through AOP and COTS for authentication.

Does Cloudflare Tunnel use post-quantum signatures?

Not according to Cloudflare’s current product matrix. Tunnel supports X25519MLKEM768 key agreement, while signatures are listed as not yet supported.

Is classical fallback insecure?

It is an interoperability path, not a failed handshake. It does not provide ML-KEM protection for that connection. Whether it is acceptable depends on the system’s threat model and enforcement requirements.

Sources

Cloudflare Docs: Post-quantum between Cloudflare and origin servers — Automatic Key Exchange, origin testing, AOP/COTS, ML-DSA requirements and downgrade guidance
Cloudflare Docs: PQC in Cloudflare products — Capability status by connection and product
Cloudflare Docs: PQC support — Supported browsers, libraries, servers and algorithm terminology
Cloudflare Docs: Post-quantum cryptography in Cloudflare One — Cloudflare One Client, Tunnel and network-path behavior