Summary

  • Cloudflare's current Automatic Key Exchange guide says requests to its legacy Origin Post-Quantum Encryption API no longer change the zone's key-agreement behaviour.
  • Disabling automatic selection does not remove the separate restrictions on allowed algorithms.
  • The documentation establishes a control boundary, not a measured customer failure or the date on which the old API stopped taking effect.

A configuration interface can outlive the configuration it once controlled. Cloudflare's current origin guide provides an unusually explicit example: the Origin Post-Quantum Encryption API remains available, but requests to it are no-ops. Keeping the endpoint reachable does not mean keeping its former effect.

That distinction accompanies Cloudflare's September 8 account of Automatic Key Exchange. The system probes origin capabilities outside the live request path and chooses an initial TLS key share, seeking to avoid a server asking for another one through HelloRetryRequest. This is the connection from Cloudflare to an origin, not the visitor's connection to Cloudflare.

The old vocabulary survives

The legacy API reference is marked Deprecated. It still describes the values preferred, supported and off, and presents an update operation. The operating guide, meanwhile, says the requests no longer affect behaviour and directs customers to Automatic Key Exchange and Compliance requirements.

There is a documentation boundary here, not evidence of a secretly failed customer deployment. This report has not exercised that API against a customer's zone. The guide does not establish a retirement date; the reference's Deprecated label does not supply one either. Nor does the September 8 announcement establish when the old requests became ineffective. Dating all three events to the launch would manufacture a migration history.

For an operator, however, the implication is immediate: an old automation's continued ability to form a valid request is insufficient evidence that it still governs the intended setting.

Two decisions replace one familiar label

Automatic selection chooses a preference within an allowed set. The compliance control restricts the set itself. Turning off the former stops scanning and reordering; it does not turn off the latter. A rollback instruction saying only “disable automation” therefore leaves a security-policy decision unspecified.

The distinction matters most for a zone that requires hybrid post-quantum groups. Stopping preference optimisation does not restore classical groups excluded by that requirement. Conversely, allowing a wider set is not the same action as asking the platform to choose an efficient first share. Either decision may be reasonable, but each needs its own owner and intended result.

Scope also limits what the controls prove. The mechanism applies to new TLS 1.3 origin connections, not reused connections, and excludes Cloudflare Tunnel. Current preferences are zone-wide; the announcement places finer per-origin or per-subdomain choices on the future roadmap. An origin still needs compatible cryptographic software. The selection service cannot install that capability on the customer's behalf.

The development is thus more than a faster handshake. It changes where an operator must express intent. A familiar API name is a poor substitute for understanding the controls that now have operational effect.