What happened
In its October 2025 'State of the post-quantum Internet' report, Cloudflare said over half of human-initiated traffic to its network now uses post-quantum key agreement — hybrid X25519MLKEM768, which pairs classical X25519 with NIST's ML-KEM-768 (FIPS 203). Client adoption was driven by browsers enabling it by default (Chrome desktop from March 2024, plus Firefox and Apple platforms). Server-side lags: about 39% of the top 100,000 domains support PQ key agreement (up from 28% six months earlier), and only 3.7% of origins behind Cloudflare (up from 0.5% in 2023). A key gap remains: server-certificate signatures are still classical (ECDSA/RSA), so authentication is not yet post-quantum.
Why it matters
The quantum threat isn't only future tense: 'harvest now, decrypt later' means traffic captured today can be decrypted once a capable quantum computer exists, so key agreement had to move first. It has — quietly, at majority scale — but the migration is half done: signatures, and therefore authentication, are still classical, and your own origins and internal services are almost certainly not covered by what the browser-plus-CDN edge did for you.
The edge did the easy half for free; the rest is your problem. The Staff move is inventory: where do you hold long-lived secrets or data that must stay confidential for years (the harvest-now targets), and which of your internal TLS, VPNs and origins still lack PQ key agreement? Plan the signature migration separately — it's the harder, later phase — and prefer crypto-agile designs so swapping algorithms isn't a rewrite.
What is 'harvest now, decrypt later,' and why did post-quantum TLS deploy key agreement (ML-KEM) before post-quantum signatures? What would you migrate first?
Probes threat modeling, crypto-agility, and the confidentiality-vs-authentication distinction.