Skip to Content

Understanding Cloudflare Radar’s Post‑Quantum Monitoring, Key Transparency, and Routing Security (2026)

28 February 2026 by
Suraj Barman

Context & History

Since early 2024 Cloudflare Radar has expanded from basic attack telemetry to a broader view of cryptographic health and routing integrity. The platform first reported client‑side support for post‑quantum (PQ) key exchanges, then added a public dashboard for Key Transparency logs, and most recently introduced origin‑facing PQ visibility and ASPA routing data. These additions reflect growing industry pressure to prepare for quantum‑era threats while keeping the public informed about the state of internet security.

Implementation & Best Practices

Deploying the new Radar data sets involves three layers: data collection, API exposure, and user‑facing tools. Begin by enabling the TLS scanner on your origin servers, then configure the Radar API to pull PQ support metrics. Next, integrate the Key Transparency audit endpoint into your monitoring stack, and finally, consume the ASPA routing dataset to spot potential BGP leaks. Following this sequence ensures that each component has the necessary context before the next is added.

Roadmap: 1) Activate the origin TLS scanner 2) Register for Radar API access 3) Add Key Transparency verification scripts 4) Pull ASPA routing tables 5) Build dashboards or alerts based on the aggregated data.

Post‑Quantum TLS Scanning

Cloudflare’s scanner probes TLS 1.3‑compatible origins for support of X25519MLKEM768, a hybrid key exchange that mixes classic X25519 with the lattice‑based ML‑KEM algorithm standardized by NIST. The scanner records support status daily, but it does not enforce a preference a server may support the algorithm yet still negotiate a classical exchange. To interpret results correctly, compare the scanner output with your server’s TLS configuration (e.g., OpenSSL 3.5.0+ or Go 1.24+). For deeper technical background, see the Post‑Quantum Cryptography article and the NIST ML‑KEM documentation.

Key Transparency Auditing

Key Transparency provides an append‑only log of public keys for end‑to‑end encrypted messaging services. Cloudflare’s auditor periodically verifies log consistency and publishes a real‑time status dashboard. To incorporate this into your security workflow, poll the public API for the latest verification timestamps and compare them against your internal key‑distribution checkpoints. Any deviation should trigger a review of the messaging platform’s key management pipeline. The audit logic is similar to Certificate Transparency, offering a familiar verification model for developers.

ASPA Routing Checks

ASPA (Autonomous System Provider Authorization) is an emerging standard that helps detect BGP route leaks by defining authorized provider relationships. Radar now surfaces country‑level and network‑level ASPA deployment metrics. Operators can download the ASPA dataset via the Radar API, cross‑reference it with their own BGP tables, and flag routes that violate authorized provider relationships. Regularly updating the ASPA view—ideally daily—reduces the window for unnoticed leaks.

Practical Tips

  • Schedule the TLS scanner to run during low‑traffic windows to avoid performance impact.
  • Store Key Transparency audit results in a time‑series database for trend analysis.
  • Automate ASPA validation with a script that alerts on any new unauthorized route announcement.
  • Leverage existing API security patterns see the guide on rate limiting for Express APIs for a solid baseline.
  • When building dashboards, ensure they respect accessibility standards the web interoperability article offers useful recommendations.

Takeaway: By systematically enabling the scanner, consuming the audit API, and applying ASPA checks, organizations can gain a clear picture of their quantum‑ready posture and routing health, while providing transparent evidence to customers and auditors.