AWS’s October 30, 2026 announcement describes two optional CloudFront headers for origins: CloudFront-Viewer-ISP and CloudFront-Viewer-TLS-Details. For a team investigating post-quantum connections, the practical question is what traffic its observations actually cover.

Start with the connection described by the header

AWS says CloudFront-Viewer-TLS-Details describes the cryptography on the viewer’s TLS connection, including key exchange, signature scheme and signature public key type. The ISP header supplies the viewer’s internet service provider name. The announcement says either header can be forwarded by adding it to an origin request policy and attaching that policy to the distribution.

Treat those fields as observations with a defined scope. A report about the viewer’s connection should identify that connection in its label; it should not silently describe the result as a verification of every encrypted link in an application.

If you also use Azure Front Door, check its client-to-edge and edge-to-origin TLS connections separately, including the negotiated key exchange group.

For the wider post-quantum migration plan, build an inventory of cryptographic purpose, data lifetime and vendor dependencies.

An origin record needs a sampling description

AWS’s origin-request guide explains that a cache miss sends a request to the origin to retrieve the object. It distinguishes origin request policies, which control forwarded information, from cache policies, which control the cache key.

The reporting implication is that a collection of origin records alone does not demonstrate coverage of every viewer request. Before quoting an adoption percentage, explain how records reached the origin, what period they cover and which records were usable. Forwarding a header and proving a complete measurement population are separate tasks.

Work through a fictional denominator

Imagine an invented worksheet containing 100 origin records from a trial. Of these, 60 have usable results and 40 are marked unclassified. Within the 60 usable records, the exercise labels 30 as matching its chosen post-quantum classification. These numbers are illustrative; they are not AWS traffic data or a tested classifier.

The fraction is 30 divided by 60, or 50% of usable records. Across all 100 collected records, the marked group represents 30%, with the 40 unclassified entries still visible. Neither calculation establishes that half of all visitors used post-quantum cryptography. A visitor count would require its own method, and the worksheet has supplied none.

Write the label before building the chart

A defensible worksheet label would state the observation point, time window, classification rule, denominator and unclassified count. Keep an example label such as 'classified origin records during this trial' attached to the result when exporting it. That wording makes the limit visible to someone who never saw the collection setup.

No AWS account, policy, origin log or TLS handshake was tested for this article. Review the supported header fields and your collection path before implementing a measurement; no production configuration change is implied by this explanation.

Primary sources

  • AWS announcement, October 30, 2026: https://aws.amazon.com/about-aws/whats-new/2026/10/cloudfront-viewer-isp-post-quantum-visbility/
  • AWS Developer Guide — control origin requests with a policy: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/controlling-origin-requests.html

Check the denominator

Conceptual illustration of an analyst comparing generic records beside abstract network equipment; not an AWS interface or measured traffic chart.
Conceptual illustration of an analyst comparing generic records beside abstract network equipment; not an AWS interface or measured traffic chart.