A server configuration can say that post-quantum cryptography is enabled while a meaningful share of real traffic still negotiates classical protection. Cloudflare’s September 29 article, Is your domain using post-quantum encryption? Now you can see for yourself, introduces domain-level and per-request visibility into the TLS key-exchange group used on visitor and origin connections.
The product announcement is specific to Cloudflare’s platform, but the measurement lesson applies broadly: support, configuration, negotiation, and coverage are different facts. A cryptographic inventory that records only what a service can do cannot prove what clients and servers actually did.
Capability is not negotiated protection
TLS negotiation depends on both endpoints, protocol versions, preferences, network intermediaries, and configuration. A modern server may support X25519MLKEM768, the hybrid TLS 1.3 key-exchange group combining X25519 with ML-KEM-768, while older clients select a classical group or use TLS 1.2. An origin may support a hybrid group but fail to negotiate it because of ordering or proxy behavior.
Cloudflare’s new fields expose the selected key-exchange group rather than merely the available configuration. The company reports a large difference between aggregate browser-to-edge and edge-to-origin adoption, illustrating why a single percentage or “PQC on” flag can hide an unprotected segment.
There are at least four useful states to track:
- Implemented: the software or hardware contains the mechanism.
- Enabled: policy and configuration permit it.
- Negotiated: a real connection selected it.
- Covered: the relevant population and traffic consistently use it.
Each state answers a different governance question. Implementation supports procurement planning. Enablement supports configuration review. Negotiation supports operational verification. Coverage supports risk decisions and migration completion criteria.
Measure both sides of the proxy
Content-delivery networks, load balancers, service meshes, API gateways, and other intermediaries split one user journey into multiple cryptographic sessions. Protecting the browser-to-edge connection does not prove that the edge-to-origin connection uses the same protection.
A useful system-of-record model therefore represents each TLS termination point and connection segment. It links the public domain to the edge service, origin, client population, certificate, protocol version, key-exchange group, and owner. Without that topology, a dashboard can show high PQC adoption at the front door while an internal or origin segment remains classical.
The same model should distinguish confidentiality from authentication. X25519MLKEM768 addresses key establishment and helps mitigate harvest-now, decrypt-later risk. Certificates and their signatures remain a separate migration track. A connection can use post-quantum key agreement while authenticating the server with RSA or ECC.
Turn telemetry into evidence carefully
Per-connection logs make migration measurable, but raw logs are not automatically durable proof. Teams need defined time windows, sampling assumptions, retention, normalization, and coverage. They should know which traffic classes are missing, which connections bypass the measured path, and how bots, mobile apps, embedded clients, and partner integrations differ from browser traffic.
A practical evidence record should include:
- service or domain and each connection segment;
- observation source, field definition, and collection period;
- protocol version and negotiated key-exchange group;
- traffic volume and percentage by client or workload class;
- classical, deprecated-draft, unknown, and unencrypted outcomes;
- configuration and software versions in effect during measurement;
- exception owner and explanation for uncovered traffic; and
- the threshold and duration required to claim migration completion.
This evidence should be compared against policy. A rule might require hybrid key agreement for sensitive browser traffic while allowing a documented exception for a constrained partner client until a specified date. The finding should remain open until observed state meets the rule, not merely until a configuration change is submitted.
What organizations should do next
First, identify where TLS terminates and where sessions are re-encrypted. Treat visitor-to-edge, edge-to-origin, service-to-service, and administrative connections as separate inventory relationships.
Second, enable or collect negotiated-cryptography telemetry where platforms expose it. Preserve raw fields needed for verification, but avoid retaining sensitive traffic data beyond operational and legal requirements.
Third, segment the results. A global percentage can improve while a critical legacy API remains entirely classical. Prioritize by data lifetime, sensitivity, exposure, and client upgrade constraints.
Fourth, investigate rather than erase exceptions. Classical negotiation may indicate an old client, disabled TLS 1.3, unsupported origin, preference mismatch, or intermediary limitation. The remediation depends on the actual cause.
Finally, use trends to make removal decisions. Cloudflare notes that it has retained an older Kyber draft group while observed connections diminish. Deprecation should combine standards guidance with real dependency evidence so that teams neither preserve obsolete mechanisms indefinitely nor strand necessary clients without a plan.
How Vista Platform helps
Vista Platform is a self-hosted cryptographic system of record. Its operating loop—discovery, canonical inventory, evaluation, action, and proof—helps connect observed cryptography and imported evidence to assets, relationships, policies, owners, and remediation work.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or migrate every endpoint. Selected-asset Active Scan is targeted, not indiscriminate network scanning. Vista is not a vulnerability scanner, and incomplete observation is not proof of absence.
Where uncertainty remains
Cloudflare’s telemetry covers traffic visible to its services and uses its field definitions; it is not a universal view of an organization’s TLS estate. Adoption percentages can also change quickly as clients update. The operational principle is stable: migration claims should identify what was observed, where, when, and across which population—and should separate post-quantum key establishment from post-quantum authentication.
Source
- Is your domain using post-quantum encryption? Now you can see for yourself, Cloudflare, September 29, 2026.