Post-quantum authentication to origins is now supported • William OGOU Cybersecurity Blog

Cloudflare’s Authenticated Origin Pulls (AOP) and Custom Origin Trust Store (COTS) now support post-quantum authentication. This means customers can configure mutually authenticated TLS connections between Cloudflare and their origin servers using ML-DSA signatures, one of the digital signature standards selected by NIST for the post-quantum era.

This article is adapted from the Cloudflare engineering post by Luke Valenta and Kevin Guthrie. Read the original announcement for Cloudflare’s full implementation notes and product documentation.

The practical result is important: a customer can protect both directions of the Cloudflare-to-origin trust relationship against future quantum attacks. The sections below explain why this connection is different from browser-to-Cloudflare traffic, how to configure a fully post-quantum mutual TLS setup, and what Cloudflare’s rollout reveals about the larger migration from post-quantum encryption to post-quantum authentication.

Reaching a Major Milestone

For the past several years, the first priority in post-quantum cryptography (PQC) has been encryption. Organizations have been upgrading key exchange mechanisms to defend against harvest-now, decrypt-later (HNDL) attacks. In an HNDL attack, an adversary records encrypted traffic today and stores it until a sufficiently capable quantum computer can decrypt it.

That threat remains urgent, but the migration target has expanded. Advances in quantum computing and cryptanalysis have pushed organizations to think about a second problem: an attacker with a quantum computer could break classical public-key credentials and use forged certificates or signatures to impersonate a trusted party.

Cloudflare previously announced a target of 2029 for full post-quantum security across its systems. The first milestone is now complete: AOP and COTS support post-quantum authentication through the Module-Lattice-Based Digital Signature Algorithm (ML-DSA). This is a meaningful shift from protecting only the confidentiality of a connection to also protecting the identities that establish trust on that connection.

For background on the broader migration, see The Definitive Post-Quantum Cryptography Migration Checklist. The security of new algorithms also depends on continued public scrutiny; our article on AI-driven mathematical cryptanalysis explores why algorithmic review remains essential even after standardization.

The Origin Connection Is Different

Cloudflare-to-origin connection

When a visitor requests a website proxied by Cloudflare, the request normally involves two separate TLS connections:

Connection 1: visitor to Cloudflare. A browser or other client connects to Cloudflare. Cloudflare may answer from cache or apply security rules without contacting the origin.
Connection 2: Cloudflare to the origin. If the content is not already available at the edge, Cloudflare opens a connection to the customer’s origin server and retrieves the response.

Protecting sensitive visitor data requires both connections to resist quantum attacks. Cloudflare enabled post-quantum encryption for visitor-to-Cloudflare traffic in 2022 and for Cloudflare-to-origin traffic in 2023. Post-quantum authentication is a separate challenge because the two connections have different trust models.

For visitor-to-Cloudflare traffic, the public WebPKI must support a new generation of certificates at Internet scale. Cloudflare is working with Google and other participants in the Internet Engineering Task Force (IETF) on Merkle Tree Certificates (MTC), a design intended to make fast post-quantum certificates practical for the web. Initial deployments are targeting 2027.

The origin connection has several advantages for an earlier deployment:

Cloudflare is the TLS client. It can use connection pooling to combine requests from across its network into a smaller number of long-lived origin connections, spreading the cost of larger post-quantum signatures across many requests.
Cloudflare and its customers already have a trust relationship through the Cloudflare account. They can use a custom PKI designed for the origin use case instead of waiting for every WebPKI component to support large post-quantum certificates.
Custom trust stores do not need to carry the same intermediate-certificate and Certificate Transparency overhead required by the public Internet.
Products such as Cloudflare Tunnel can protect legacy origin systems by forwarding traffic through a tunnel that uses post-quantum encryption, with post-quantum authentication support continuing to expand.

These constraints make the Cloudflare-to-origin connection a practical place to deploy ML-DSA authentication before post-quantum certificates become common in the public WebPKI. Customers using the WebPKI are not left behind: Cloudflare plans to add MTC support to the origin connection in the future.

The distinction between key exchange and authentication is also central to a successful TLS migration. For a deeper explanation of hybrid key exchange and TLS 1.3 prerequisites, see The Quantum-Proof Handshake: Your Blueprint for Migrating to Post-Quantum TLS.

Configuring Fully Post-Quantum Origin Connections

Cloudflare added ML-DSA support for all three FIPS 204 parameter sets:

ML-DSA-44: The recommended option for most applications. It offers the best performance of the three choices while reaching a comfortable NIST category 2 security strength.
ML-DSA-65: A higher security category with larger keys, signatures, and computational costs.
ML-DSA-87: The strongest parameter set, with the largest performance and bandwidth overhead.

The remainder of this guide uses ML-DSA-44. The same product workflow applies to the other parameter sets when they are appropriate for your risk model and performance budget.

Custom Origin Trust Store

When Cloudflare connects to an origin configured with Full (strict) SSL mode, it validates the origin certificate against a default trust store containing commonly trusted Certificate Authorities (CAs) and Cloudflare’s Origin CA.

The Custom Origin Trust Store product, which requires Advanced Certificate Manager, lets a customer replace that default trust store with a set of CAs under the customer’s control. COTS now accepts ML-DSA CAs. Cloudflare will trust an origin certificate that chains to the uploaded ML-DSA CA when connecting to the origin.

Uploading a COTS CA replaces the default publicly trusted CAs for the zone. If the goal is to prevent downgrade attacks, upload only post-quantum CAs and make sure the origin presents a certificate that chains to one of them.

Authenticated Origin Pulls

An origin can also require proof that an incoming request came through Cloudflare. Authenticated Origin Pulls configures Cloudflare to present a client certificate while connecting to the origin. The origin verifies that certificate and establishes mutual TLS (mTLS), so both sides of the connection are authenticated.

AOP is available on all Cloudflare plan levels. It supports global, per-zone, and per-hostname configuration. The per-zone and per-hostname configurations now accept ML-DSA certificates and private keys in the FIPS 204 seed format. Cloudflare’s TLS client presents the uploaded certificate when it connects to the origin.

The global configuration level is not included in this initial ML-DSA rollout. Supporting it requires a more involved control-plane change and is planned for a later phase.

Avoiding Downgrades

Supporting a post-quantum algorithm on both sides is necessary, but it is not sufficient. A downgrade remains possible if the verifying side continues to trust quantum-vulnerable authentication mechanisms.

For example, an on-path attacker who can forge a classical credential may be able to impersonate an origin or Cloudflare even when both parties also support ML-DSA. The verifier must remove trust in those classical credentials if the connection is required to be fully post-quantum secure.

This is straightforward for a deliberately narrow custom trust store but more nuanced for a complex PKI. Review the Cloudflare AOP and COTS configuration guide and confirm that no quantum-vulnerable CA or certificate path remains trusted.

Quick Start

The following walkthrough generates an ML-DSA certificate chain and configures both products through the Cloudflare API. It requires OpenSSL 3.5.0 or later. Cloudflare currently accepts private keys in the FIPS 204 seed-only encoding.

1. Generate Certificates

Create the origin server certificate chain used by COTS:

# Create a private ML-DSA-44 CA for the origin server
openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out origin-ca.key

openssl req -new -x509 -key origin-ca.key \
  -out origin-ca.crt -days 10950 \
  -subj "/CN=Origin Server CA"

# Create the origin server certificate, signed by the origin CA
openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out origin-server.key

openssl req -new -key origin-server.key \
  -out origin-server.csr \
  -subj "/CN=origin.example.com"

openssl x509 -req -in origin-server.csr \
  -CA origin-ca.crt -CAkey origin-ca.key -CAcreateserial \
  -out origin-server.crt -days 5475 \
  -extfile <(printf "basicConstraints=CA:FALSE\nkeyUsage=digitalSignature\nsubjectAltName=DNS:origin.example.com\n")

Create the Cloudflare client certificate chain used by AOP:

# Create a private ML-DSA-44 CA for Authenticated Origin Pulls
openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out aop-ca.key

openssl req -new -x509 -key aop-ca.key \
  -out aop-ca.crt -days 10950 \
  -subj "/CN=Authenticated Origin Pull CA"

# Create the client certificate Cloudflare will present, signed by the AOP CA
openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out aop-client.key

openssl req -new -key aop-client.key \
  -out aop-client.csr \
  -subj "/CN=cloudflare-aop-client"

openssl x509 -req -in aop-client.csr \
  -CA aop-ca.crt -CAkey aop-ca.key -CAcreateserial \
  -out aop-client.crt -days 5475 \
  -extfile <(printf "basicConstraints=CA:FALSE\nkeyUsage=digitalSignature\n")

Protect the generated private keys carefully. The AOP private key is uploaded to Cloudflare so that Cloudflare can authenticate itself to the origin; it should not be reused for another purpose.

2. Upload the Origin CA to Custom Origin Trust Store

The API accepts the certificate as a JSON string:

CA_CERT=$(jq -Rs . < origin-ca.crt)

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/acm/custom_trust_store" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --json "{\"certificate\": $CA_CERT}"

Remember that uploading a COTS CA replaces the default publicly trusted CAs for the zone. Upload only post-quantum CAs when protection against authentication downgrades is required.

3. Upload the AOP Client Certificate

This example uses zone-level AOP. For per-hostname AOP, use the /origin_tls_client_auth/hostnames/certificates endpoint instead.

CERT=$(jq -Rs . < aop-client.crt)
KEY=$(jq -Rs . < aop-client.key)

# Upload the ML-DSA client certificate
curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/origin_tls_client_auth" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --json "{\"certificate\": $CERT, \"private_key\": $KEY}"

# Enable zone-level Authenticated Origin Pulls
curl -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/origin_tls_client_auth/settings" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --json '{"enabled": true}'

Keep CLOUDFLARE_API_TOKEN outside shell history and CI logs. Use a narrowly scoped token rather than a global API key.

4. Set Full (Strict) SSL/TLS Mode

COTS is active only when the zone uses Full (strict) mode. AOP without COTS requires Full or a stricter mode.

curl -X PATCH "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/settings/ssl" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --json '{"value": "strict"}'

5. Configure the Origin Server with NGINX

If you are using COTS and the origin presents the ML-DSA server certificate:

server {
    listen 443 ssl;
    ssl_certificate     /etc/ssl/origin-server.crt;
    ssl_certificate_key /etc/ssl/origin-server.key;
    ssl_protocols       TLSv1.3;
}

If you are using AOP and the origin verifies Cloudflare’s client certificate:

server {
    listen 443 ssl;
    ssl_client_certificate /etc/ssl/aop-ca.crt;
    ssl_verify_client      on;
}

For full post-quantum mutual TLS, use both configurations together:

server {
    listen 443 ssl;
    ssl_certificate        /etc/ssl/origin-server.crt;
    ssl_certificate_key    /etc/ssl/origin-server.key;
    ssl_client_certificate /etc/ssl/aop-ca.crt;
    ssl_verify_client      on;
    ssl_protocols          TLSv1.3;
}

6. Verify the Post-Quantum Handshake

The TLS handshake between Cloudflare and the origin happens server-to-server. A request from an outside browser does not expose the origin handshake, so verify each side separately.

Verify COTS

If the origin IP is directly reachable during testing, connect directly and validate the ML-DSA certificate:

openssl s_client -connect <ORIGIN_IP>:443 \
  -servername origin.example.com \
  -CAfile origin-ca.crt \
  -brief

Look for Signature type: mldsa44 in the output. If the origin is firewalled to accept only Cloudflare IP ranges, inspect the origin TLS logs or use a packet capture tool such as ssldump or tcpdump to confirm that Cloudflare negotiated TLS 1.3 with the ML-DSA certificate.

Verify AOP

Confirm that a direct connection without a valid client certificate is rejected:

openssl s_client -connect <ORIGIN_IP>:443 \
  -servername origin.example.com \
  -brief

With ssl_verify_client on enforced, this connection should fail with an SSL alert.

Verify the Full Cloudflare-to-Origin Path

The most reliable way to confirm that Cloudflare is presenting the ML-DSA client certificate is to inspect origin logs. NGINX can log the client certificate serial number and subject:

log_format pq_verify '$remote_addr - $ssl_client_serial $ssl_client_s_dn';
access_log /var/log/nginx/pq-verify.log pq_verify;

After sending a request through Cloudflare, inspect the log and confirm that the serial number matches the aop-client.crt certificate uploaded to AOP.

For key agreement, make sure the origin TLS library supports X25519MLKEM768 and that the group is preferred in the configuration. The negotiated post-quantum key agreement should appear in origin logs or packet captures.

The Boring Details

Deploying this feature required changes in two systems: the control plane that manages TLS settings and certificates, and the data plane that establishes TLS connections to customer origins.

Control Plane

Cloudflare’s SSL/TLS configuration service runs in a highly available setup across critical data centers. It processes settings updates and distributes them through Cloudflare’s globally distributed key-value store so that data plane services can use current customer configuration while serving live traffic.

Adding ML-DSA support to AOP and COTS required the control plane to parse and validate ML-DSA certificates. The service is written in Go, but Go’s standard X.509 and TLS libraries did not yet support ML-DSA when the work began. Cloudflare therefore implemented the required functionality in its CIRCL cryptographic library.

That patch was manageable for one service, but repeating it across every service that needs post-quantum authentication would create a long-term maintenance burden. The expected Go 1.27 release in August 2026 will include native ML-DSA support, allowing Go services to adopt it through a routine version update and eventually remove the extra CIRCL integration.

Data Plane

Once customers could upload ML-DSA certificates, the origin-facing data plane had to use them. Cloudflare’s Pingora-based origin service handles millions of requests per second and is responsible for delivering origin-bound requests safely to their destinations.

The TLS provider handles most of the cryptographic work. Post-quantum authentication did not require quantum hardware or exotic physics; it required a modern TLS implementation. In this case, the key dependency was an update to BoringSSL.

Cloudflare had kept Pingora Origin on an internal BoringSSL fork for four years while patching in the functionality it needed. When post-quantum authentication support landed in BoringSSL in April 2026, the benefit of returning to an updated upstream version justified the migration effort.

The update exposed an interoperability problem. One of the changes enforced KeyUsage rules in TLS certificates more strictly. The behavior matched the specifications, but a small number of certificates in the real-world ecosystem did not meet those rules. After a slow rollout and weeks of testing, some customer certificates were rejected, causing an incident on June 10, 2026.

Cloudflare rolled back the change and shipped a compatibility patch that retained support for RSA certificates with technically invalid KeyUsage values. After that correction, fully post-quantum secure TLS to origins was ready for customers to use.

The incident is a useful reminder that a cryptographic migration is also an interoperability migration. Standards compliance, library behavior, certificate profiles, and legacy deployments must all be tested together.

We Are Only Getting Started

ML-DSA support is becoming increasingly common across TLS libraries. Routine software updates will bring post-quantum authentication to more operating systems, frameworks, proxies, and applications. Keep cryptographic libraries updated, but test upgrades against the certificates and trust stores that your production systems actually use.

Go 1.27 is expected to bring native ML-DSA support to Go-based services. As support spreads, organizations can move from experimental integrations to standard library capabilities and reduce the maintenance cost of post-quantum authentication.

Cloudflare’s origin rollout is one milestone in a much larger migration. The next steps include expanding product support, improving certificate and PKI tooling, and ensuring that quantum-vulnerable authentication paths are not left available as silent downgrade options. Cloudflare maintains a PQC in Cloudflare Products tracker for current encryption and authentication support.

What This Means for Security Teams

The feature is specific to Cloudflare origins, but the engineering lessons apply broadly:

Separate confidentiality from authentication. A post-quantum key exchange protects the session secret. It does not automatically make the certificates and signatures used to authenticate the endpoints post-quantum secure.
Start with controlled trust domains. Private PKIs, service-to-service connections, and managed origin paths are easier places to deploy larger PQC signatures than the public WebPKI.
Remove downgrade paths. Supporting ML-DSA while retaining trust in classical CAs does not provide full post-quantum authentication.
Plan for library support. Native support in OpenSSL, BoringSSL, Go, and other TLS stacks will reduce custom integration work, but upgrades still need compatibility testing.
Inventory before migrating. Track certificates, trust stores, TLS providers, key exchange groups, and data lifetimes. The PQC migration checklist provides a practical starting point.

Post-quantum security is not a single algorithm or switch. It is a chain of protocol support, certificate issuance, trust configuration, library behavior, and operational verification. Cloudflare’s support for ML-DSA authentication at the origin is an important example of that chain becoming deployable in production.

Frequently Asked Questions (FAQ)

What is post-quantum authentication?

Post-quantum authentication uses signatures and certificates designed to resist forgery by both classical and quantum computers. In this Cloudflare feature, ML-DSA signatures authenticate the origin server and the Cloudflare client during the Cloudflare-to-origin TLS connection.

What is the difference between COTS and AOP?

Custom Origin Trust Store authenticates the certificate presented by the origin server. Authenticated Origin Pulls authenticates Cloudflare to the origin by having Cloudflare present a client certificate. Using both provides mutual TLS, where both sides verify the other.

Which ML-DSA parameter set should most customers use?

ML-DSA-44 is Cloudflare's recommended choice for most applications because it provides the best performance of the supported FIPS 204 parameter sets while reaching NIST category 2 security strength. ML-DSA-65 and ML-DSA-87 are available when a higher security category is required.

Why is Full (strict) SSL mode required for COTS?

COTS replaces the trust store used to validate the origin certificate. Full (strict) mode is required so Cloudflare validates the certificate chain and hostname instead of accepting an unvalidated origin connection. AOP without COTS requires Full or a stricter SSL/TLS mode.

Does enabling ML-DSA automatically prevent downgrade attacks?

No. The verifying party must also remove trust in quantum-vulnerable certificates and authentication mechanisms. If classical trust anchors remain accepted, an attacker capable of forging a classical credential may still use them to impersonate an endpoint.

Relevant Resources

Cloudflare announcement: Post-quantum authentication to origins is now supported
Cloudflare documentation: Post-quantum cryptography to origins
NIST standard: FIPS 204: Module-Lattice-Based Digital Signature Standard
PQC planning: The Definitive Post-Quantum Cryptography Migration Checklist
TLS migration: The Quantum-Proof Handshake: Your Blueprint for Migrating to Post-Quantum TLS