New Radar data sheds light on post-quantum origins, messaging key logs, and BGP route-leak defenses
Cloudflare Radar’s security section is gaining three new data sets aimed at different corners of Internet security: post-quantum cryptography support on the server side, the integrity of public key directories used by end-to-end encrypted messaging apps, and deployment of a newer BGP security standard.
Tracking post-quantum support at the origin
Since April 2024, Radar has charted the rise of client-side post-quantum encryption support, which has grown from under 3% of connections at the start of 2024 to more than 60% by February 2026. That metric captures only the hop between a user’s browser and a Cloudflare edge. A separate TLS connection is made between Cloudflare’s edge and a customer’s origin server for content that is not cached, and that leg of the journey has its own cryptographic story.
To measure that second hop, Cloudflare is now publishing origin-side post-quantum support data on Radar, derived from its automated TLS scanner. The scanner probes TLS 1.3-compatible origins daily and aggregates results, showing the share of customer origins that support X25519MLKEM768 — the hybrid key exchange that pairs classical X25519 with the NIST-standardized lattice-based ML-KEM. The data reflects support, not preference; an origin may offer a post-quantum algorithm but still negotiate a classical one depending on local TLS settings.
As of the latest readings, roughly 10% of origins support a post-quantum-preferred key agreement, a jump from less than 1% at the start of 2025 — a tenfold increase in just over a year. Much of that growth tracks with server-side TLS libraries enabling hybrid post-quantum key exchange by default, including OpenSSL 3.5.0+, GnuTLS 3.8.9+, and Go 1.24+. The full distribution of supported key exchange methods, classical and post-quantum, is available in Radar’s Data Explorer view, and the origin readiness data is exposed through the Radar API.
Alongside the aggregate figures, Radar now offers a practical testing tool for any publicly reachable hostname. Users enter a hostname, optionally specify a custom port (defaulting to 443), and the tool performs a TLS handshake from Cloudflare’s egress IP ranges to report whether the connection negotiates a post-quantum algorithm. A green “PQ” tag indicates the server prefers a post-quantum-secure connection; a red tag shows the classical algorithm that was actually agreed upon.
The site-checking utility runs on Cloudflare Containers, a newer compute capability that sits alongside Workers. Because the Workers runtime does not expose TLS handshake details, a Go container using the crypto/tls package performs the actual scan on demand, returning results via the Radar API.
With the arrival of origin-facing insights, all post-quantum content on Radar has been consolidated into a dedicated section of the site.
A public window into Key Transparency logs
End-to-end encrypted messaging relies on public-key cryptography, but that model carries an implicit trust assumption: users must believe the messaging service is handing out the correct public keys for their contacts. If an attacker swaps in a different key, they could quietly intercept messages.
Key Transparency attacks this problem with auditable, append-only logs of public keys, conceptually similar to Certificate Transparency for TLS certificates. Messaging services publish keys to these logs, and independent auditors verify that the logs are constructed correctly and consistently over time. Cloudflare has acted as such an auditor for WhatsApp since September 2024, and it is now making that audit data publicly visible in a new Key Transparency section on Radar.
The page opens with two monitored logs: WhatsApp and Facebook Messenger Transport. Each log is shown as a card with the following fields:
- Status: Whether the log is online, in initialization, or disabled. An online log is actively publishing key updates into epochs that Cloudflare audits, where an epoch is a set of updates applied to the key directory at a given time.
- Last signed epoch: The most recent epoch published by the messaging service and acknowledged by Cloudflare. Clicking the eye icon reveals the full JSON epoch data, including the epoch number, timestamp, digest, and signature.
- Last verified epoch: The most recent epoch Cloudflare has verified, meaning the transition of the transparency log data structure from the prior epoch constitutes a valid tree transformation. The timestamp marks when the audit completed.
- Root: The current root hash of the Auditable Key Directory (AKD) tree, cryptographically representing the full state of the key directory at the current epoch. Full JSON responses from the auditor are available with a click.
The same data is accessible programmatically through the Key Transparency Auditor API, which offers endpoints for auditor information and namespaces. For those who want to verify Cloudflare’s audit proofs independently, instructions are available in the Auditing Key Transparency blog post.
ASPA: a new lens on routing security
RPKI ASPA: A New Layer of Routing Security Visibility
The Border Gateway Protocol (BGP) underpins Internet routing but was built without built-in verification mechanisms. This design leaves the global network susceptible to route leaks and hijacks, where traffic can be detoured through unauthorized networks. While RPKI and Route Origin Authorizations (ROAs) have strengthened route origin validation, they cannot verify the path traffic takes between networks.
ASPA (Autonomous System Provider Authorization) addresses this gap. It extends RPKI protection by letting an Autonomous System (AS) cryptographically sign a record listing which networks are authorized to propagate its routes upstream. Validating these Customer-to-Provider relationships lets systems detect invalid path announcements with greater confidence.
Although the specific IETF standard remains in draft, operational adoption is accelerating. Regional Internet Registries (RIRs) like ARIN and RIPE NCC already support creating ASPA objects in their portals, and validation logic exists in major routing stacks such as OpenBGPD and BIRD. To track this momentum, Cloudflare Radar has added comprehensive RPKI ASPA support to its Routing section.
Examining Global and Per-AS Adoption
The new ASPA deployment view shows adoption growth over time, with filters for the five RIRs based on AS registration. The timeline extends back to October 1, 2023, and can be zoomed to correlate adoption spikes with industry events like the introduction of ASPA features on ARIN and RIPE NCC dashboards.
Beyond aggregate trends, a searchable explorer provides real-time ASPA content. This table supports filtering by AS number, AS name, or by whether an entry is a provider or customer ASN. Network operators can confirm their records are correctly published and inspect other networks' configurations.
ASPA data is also integrated into country/region routing pages, showing how different locations are progressing in securing infrastructure based on locally registered customer ASNs.
Connectivity Indicators and Detailed Histories
On individual AS pages, the Connectivity section now includes a visual "ASPA Verified Provider" indicator. This annotation confirms a valid ASPA record exists authorizing a specific upstream connection, offering an immediate signal of routing hygiene.
For ASes that have deployed ASPA, the full list of authorized provider ASNs is displayed with their details. A detailed ASPA activity timeline distinguishes between changes initiated by the AS itself ("As customer") and records created by others designating it as a provider ("As provider"), allowing users to see when specific routing authorizations were established or modified.
Visibility is a necessary first step toward wider adoption of protocols like ASPA. Surfacing this data helps operators deploy protections and enables researchers to track progress toward more secure routing paths. For integrating this data into external workflows, the Cloudflare Radar API now exposes ASPA content snapshots, historical timeseries, and detailed changes data.
Evolving Security Data
As Internet security evolves, so does Cloudflare Radar. The new sections expand existing routing security, transparency, and post-quantum insights already available. Users can share charts on social media using @CloudflareRadar, noc.social/@cloudflareradar, or radar.cloudflare.com on Bluesky. Questions, comments, or suggestions for new data can be sent via social media or email.
