The origin hop needs its own post-quantum migration record

A website can have a successful post-quantum handshake at its public edge while leaving the operator with an unanswered question about the next connection. When a reverse proxy opens a separate TLS session to an origin, the evidence for that session must be collected separately.

Cloudflare's September 2026 Automatic Key Exchange announcement brings that second hop into sharper focus. The rollout changes how the proxy selects an initial key share for an origin connection. It is a useful development, but a complete migration record still needs to identify what was supported, what was selected and what was observed.

This analysis proposes a way to write that record. It does not report a production migration performed by this publication, and its examples are hypothetical.

Draw the connection before describing its protection

Start with two named endpoints and the cryptographic function under examination. “Browser to edge, key agreement” and “edge to origin, server authentication” are different entries. An application may also have other internal connections that require their own assessment.

This may sound more detailed than a management summary needs. In practice, it prevents a summary from silently expanding its scope. A green result for one pair of endpoints should not become a green result for every network path that happens to serve the same website.

The connection record should identify the environment and observation period. A staging origin running newer software can answer a compatibility question while saying little about a production backend that has not yet changed. Keeping those records distinct lets teams use staging results without overstating deployment.

Separate capability, preference and negotiation

A component can support an algorithm without selecting it on a particular connection. A configuration can express a preference without proving the outcome. An observed handshake can establish an outcome for that connection without proving that every backend behaves identically.

Cloudflare's origin documentation describes automatic selection and a zone-wide preference. It separately documents key agreement and signature features. That makes the documentation useful for understanding intended behavior, while leaving local verification to establish the behavior of a particular service.

A sensible evidence record would keep three fields: supported capability, intended selection policy and observed result. A discrepancy among them becomes a troubleshooting question. Combining them into one “enabled” flag conceals precisely the distinction an operator needs during a rollout.

Keep key agreement separate from signatures

Key agreement and authentication answer different questions in a secure connection. The origin documentation's separate treatment of those features is a reminder to name the function in every migration claim.

A team may be evaluating a hybrid key agreement while its certificate arrangements follow another transition plan. That is a describable intermediate state. It should not be presented as though a single switch changes every cryptographic dependency.

This article does not reproduce certificate-generation instructions or propose a universal trust-store configuration. Those choices depend on the actual service and supported product versions. The editorial point is narrower: a migration record should show where each function stands, so that a reader can understand the remaining work without guessing.

Read software features at the same level of precision

OpenSSL's October 2025 release announcement provides another example. Its LMS addition concerned signature verification. Treating that as a complete signing capability would change the meaning of the feature.

The background NIST SP 800-208 publication identifies LMS within stateful hash-based signatures. A standards reference supplies context; a library release identifies implementation scope; an application test establishes whether the relevant behavior works in a particular integration. Those sources cannot substitute for one another.

For an origin migration, use the same discipline when reading a dependency list. Record the actual version and operation involved, then identify the evidence that the application uses it. Merely finding a supported algorithm in an installed library does not complete that chain.

Make exceptions visible enough to manage

Imagine a service with two origins. One has the intended negotiated behavior and the other does not. A percentage of successful requests might look reassuring while leaving the second origin's migration unresolved.

Our proposed record would identify the exception, its owner, the reason it remains and the next review condition. It would also state whether the exception is a deliberate compatibility choice or an unexplained result. Those are different operational situations.

The point is not to demand perfection before reporting progress. It is to make progress specific. A team can accurately report that a defined set of origins has been verified while a named remainder is still under investigation.

For example, a change record could preserve a representative handshake from each backend before and after a load-balancer upgrade. If the selected agreement changes unexpectedly, the operator then has a specific comparison to investigate rather than a vague disagreement between dashboards.

Treat change capability as a continuing responsibility

NIST's December 2025 crypto-agility white paper frames cryptographic adaptation as a capability that spans systems and organizations. Its publication record establishes the final paper's date and scope; neither document certifies a particular service.

Our interpretation is that a useful migration record should survive the immediate upgrade. When a backend moves, a dependency changes or a policy is revised, the record should make clear which observations need to be repeated.

That leaves an operator with a concrete deliverable: a connection map, operation-specific capability records, observed negotiations, owned exceptions and a reason to revisit the evidence. Automatic selection can reduce configuration work. It does not remove the need to know what the service is actually doing, or the value of describing that behavior precisely.