Who Is Actually Post-Quantum? What CloudFront's New Viewer Headers Let You Measure

Ask ten teams whether their edge is ready for post-quantum cryptography and nine will say yes. Ask them what percentage of last Tuesday’s viewers actually negotiated a quantum-safe key exchange and you will get silence. That gap, between “we support it” and “our users use it”, is the one that matters.

On 30 October 2026, AWS announced that Amazon CloudFront can forward two new optional headers to your origin. CloudFront-Viewer-ISP carries the name of the viewer’s internet service provider. CloudFront-Viewer-TLS-Details describes the cryptography used on that viewer’s TLS connection. It is a small launch. It is also a way to answer a question many of us have been waving away.

The problem: support is not adoption

A quantum-safe key exchange only protects a connection if both ends choose it. The server can offer it all day; if the client does not ask, the handshake falls back to classical elliptic curves and nobody is told.

CloudFront supports two hybrid key exchanges for viewer connections, X25519MLKEM768 and SecP256r1MLKEM768, alongside the classical prime256v1, X25519 and secp384r1. The documentation is explicit that quantum-safe key exchanges work only with TLS 1.3. A viewer on TLS 1.2 cannot use them, whatever its software claims.

“Hybrid” is the important word. These groups run a post-quantum algorithm, ML-KEM, alongside a classical elliptic-curve exchange. RFC 10024 uses the term as defined in RFC 9954: the outputs are combined to provide security as long as at least one of the component algorithms remains secure, even if the others are compromised. RFC 10024, published in August 2026, defines three of them for TLS 1.3: X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024. ML-KEM itself is specified in NIST’s FIPS 203, published on 13 August 2024, in three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024.

So the standards exist and the edge supports them. What was missing was telemetry.

The challenge: the cost of not knowing

The reason to care is in RFC 10024 itself. It notes that a passive observer with access to a cryptographically relevant quantum computer can recover an elliptic-curve Diffie-Hellman ephemeral scalar. My reading is that a classical-only exchange offers no protection for recorded traffic against such an attacker, which is a reason to want hybrid exchange on the connections that carry things with a long shelf life.

Which brings the practical question: which of your viewers are not getting it, and why? In my experience the answer is rarely “our edge”. It is old clients, embedded devices, corporate TLS-inspection middleboxes, and API consumers pinned to an old library. None of those show up in a dashboard that says “post-quantum: enabled”.

The solution: two headers and an origin request policy

Both headers are opt-in, and they travel the same way as CloudFront’s other viewer headers: you add them to an origin request policy and attach it to a distribution’s cache behaviour.

Where the new headers come from: the viewer handshake ends at CloudFront, and the policy decides what the origin gets to see.

CloudFront-Viewer-TLS-Details is a JSON object. Beyond the TLS version, cipher suite and handshake type that the older CloudFront-Viewer-TLS header already gave you, it adds three fields:

• keyExchange, the group negotiated, for example x25519, secp256r1 or X25519MLKEM768.
• signatureScheme, how CloudFront authenticated itself, for example ecdsa_secp256r1_sha256.
• signaturePublicKeyType, the type and size of the key in the certificate CloudFront presented, for example rsa2048, ecdsa_secp256r1 or mldsa65.

The AWS example for a full TLS 1.3 handshake looks like this:

{"tlsVersion":"TLSv1.3","cipherSuite":"TLS_AES_128_GCM_SHA256","handshakeType":"fullHandshake","keyExchange":"X25519MLKEM768","signatureScheme":"ecdsa_secp256r1_sha256","signaturePublicKeyType":"ecdsa_secp256r1"}

Measuring your post-quantum share is then a matter of logging that header at the origin and counting how often keyExchange is one of the ML-KEM hybrids. Note what the example shows: a quantum-safe key exchange sitting beside a classical ECDSA signature. Key exchange and authentication are separate questions, and the header reports both.

There are two behaviours in the documentation that will wreck a naive count if you ignore them.

Resumed sessions. When a session is resumed, CloudFront sets the fields that do not apply to NONE. For a resumed TLS 1.2 session, keyExchange, signatureScheme and signaturePublicKeyType are all NONE. For a resumed TLS 1.3 session, keyExchange still carries the negotiated group, because TLS 1.3 performs a new key exchange on resumption; only the signature fields are NONE. If CloudFront cannot determine a field, it is left empty. Count NONE as “not post-quantum” and you will under-report. Treat it as “no data” and filter it out.

The ISP header may be absent. CloudFront-Viewer-ISP holds the name of the viewer’s provider, is not percent-encoded, and is simply not added when CloudFront cannot determine the ISP. A missing header is a normal outcome, not an error. CloudFront already offered CloudFront-Viewer-ASN and CloudFront-Viewer-Address; the ISP name is the human-readable layer on top, which is what you want when a provider’s customers all fail the same check and you need to tell someone a name rather than a number.

Per the documentation, the TLS headers can be added to an origin request policy but not a cache policy, and the ISP header can go only in an origin request policy, not in a cache policy or legacy cache settings. That is a feature, in my reading. The documentation says headers in a cache policy are included in the cache key, and a header with thousands of distinct values would fragment the cache. Here the origin sees the value and the cache key is untouched.

The same property sets the limit on what you can learn. The origin only sees requests that CloudFront forwards, and that is my inference rather than anything the launch states: cache hits never reach it. If your hit ratio is 95 per cent, the headers describe the other five, which skews towards uncacheable and personalised traffic. That is a biased sample, and a fine place to start, but do not publish “our post-quantum adoption is 41 per cent” off origin logs alone without saying what it is a sample of.

A sensible first experiment:

1. Create an origin request policy that includes both headers and attach it to one busy distribution.
2. Log the two headers at the origin, as separate fields.
3. After a week, group by keyExchange and by ISP.
4. Look at the long tail. The interesting rows are the ISPs where many viewers land on x25519 or secp256r1 despite a modern-looking user agent.

Footprint

Three judgment calls I would take from this.

First, adoption is a property of your audience, not your configuration. You can be perfectly configured and still see most of your traffic fall back, because the client decides. Knowing the number changes the conversation from “are we ready?” to “who is not?”, which is the conversation you can actually act on.

Second, TLS 1.2 is now a measurable post-quantum liability. Quantum-safe key exchange needs TLS 1.3 on CloudFront, so every TLS 1.2 viewer is by definition outside it. With tlsVersion in the same header you can finally put a size on that population before deciding whether to retire old protocol versions.

Third, the ISP header is a diagnostic tool before it is a security one. Slicing traffic and performance by network is useful the first time a single provider has a bad day. The announcement frames it the same way: break down traffic and performance by network, and isolate unusual traffic from a single provider.

None of this moves a single byte of your traffic to a safer cipher. It only tells you the truth about the traffic you have. For a migration that will take years, with the clients mostly out of your hands, that is the right thing to ship first.