Skip to content
pqdoctor

Convince your boss

This page is written to be forwarded. If you’re the engineer, send it up; if you’re the boss, it’s the five-minute version of a decision you’ll be asked to make anyway. Everything on it is sourced, and the sources are at the bottom.

Todayis when encrypted traffic recorded now gets decrypted later, once a large quantum computer exists. The data leaves today.
2030NIST deprecates RSA-2048-class keys (draft); Australia says stop using classical public-key crypto; the EU’s high-risk systems are due
2035NIST disallows every quantum-vulnerable public-key algorithm (draft), including P-256, X25519 and Ed25519; the UK and EU finish
~70%of browser traffic to Cloudflare is already post-quantum, and Cloudflare goes post-quantum to your origin the moment your origin supports it (Cloudflare, 2026-09-29)

The one-minute version

Section titled “The one-minute version”

The risk is already here

Anyone can record our encrypted traffic today and decrypt it when a quantum computer is big enough. Anything that has to stay secret for more than a few years is exposed now, not on the day the computer arrives.

The dates are set

NIST, the NSA, the EU, the UK and Australia have published dates between 2026 and 2035. Big cryptographic migrations take years, so the start date is now.

Step one is cheap

The first and most urgent change, post-quantum key exchange, is mostly a library upgrade we’d do anyway (OpenSSL 3.5, Go 1.24, current Java and Windows). Browsers already support it.

We can measure it

pqdoctor tells us which servers are post-quantum, why each one isn’t, and the exact change that fixes it. The work becomes a list with owners.

How bad is it?

Section titled “How bad is it?”

Harvest now, decrypt later

Section titled “Harvest now, decrypt later”

A quantum computer of enough size runs Shor’s algorithm, which breaks the public-key cryptography the internet relies on: RSA, elliptic curves (ECDH, ECDSA, Ed25519) and classic Diffie-Hellman. Those algorithms protect the keys for nearly every encrypted connection and the signatures behind every certificate and software update.

Nobody has that computer yet. It doesn’t matter for data that’s already been recorded: an attacker stores the encrypted traffic today and decrypts it later. So for key exchange, the clock started when the traffic was sent.

Kind of cryptography Examples Quantum effect What to do
Key exchange ECDHE, X25519, RSA key transport, DH Broken by Shor Move to ML-KEM now: recorded traffic is the risk
Signatures and certificates RSA, ECDSA, Ed25519 Broken by Shor Move to ML-DSA / SLH-DSA; forged signatures only matter at the time of use, so this can follow key exchange
Symmetric encryption AES Weakened by Grover (roughly halves the key strength) AES-256 where data must last; AES-128 is still allowed by NIST
Hashes and MACs SHA-2, SHA-3, HMAC Weakened slightly Keep; SHA-384 or larger where CNSA 2.0 applies

Mosca’s rule: are we already late?

Section titled “Mosca’s rule: are we already late?”

Michele Mosca’s rule of thumb: let x be how long your data must stay secret, y how long the migration will take, and z how long until a quantum computer can break today’s keys. If x + y > z, you’re already too late for that data.

Health records, contracts, intellectual property, government data and long-term customer data easily have x of 10 years or more. Replacing cryptography across a company (finding every system, upgrading libraries, appliances and hardware security modules, re-issuing certificates) has historically taken years. You don’t need to know z exactly to see that x + y is already long.

Where things stand today

Section titled “Where things stand today”
Measure Figure Source
Browser traffic to Cloudflare using post-quantum key exchange about 70% Cloudflare, 2026-09-29
Origin servers Cloudflare connects to that use it “just about 15%” Cloudflare, 2026-09-29
Top 1 million sites with post-quantum key exchange; without Cloudflare 54%; 22% F5 Labs, 2026-09-22
Non-CDN origin servers in the Tranco top 10,000 28.1% (1,298 of 4,625); 61.3% weighted by traffic pqdoctor’s study, re-run, 2026-10-24

Browsers and the big edge networks are ready. The remaining step is the servers behind them, and that’s the part your organisation runs. Cloudflare’s share is climbing fast: origins it reaches with post-quantum key exchange went from 0.5% in 2023 to 12.8% in September 2026 and about 15% weeks later.

How late is it? The deadlines

Section titled “How late is it? The deadlines”

Every date is from the issuing body’s own document. NIST IR 8547 is still a draft.

Date Who Milestone
31 Dec 2026 EU Member states have national roadmaps and have taken first steps
1 Jan 2027 NSA (CNSA 2.0) New acquisitions for US national security systems must be CNSA 2.0 compliant
31 Dec 2028 UK NCSC Discovery done and a migration plan in place
31 Dec 2030 NIST (draft) 112-bit-strength RSA, ECDSA, ECDH and finite-field DH deprecated (RSA-2048 and similar)
31 Dec 2030 Australia (ASD) Stop using traditional asymmetric cryptography
31 Dec 2030 EU High-risk use cases migrated
31 Dec 2030 NSA (CNSA 2.0) Software and firmware signing exclusively on CNSA 2.0 algorithms
31 Dec 2031 UK NCSC The highest-priority migrations done
31 Dec 2031 NSA (CNSA 2.0) CNSA 2.0 algorithms mandatory, unless otherwise noted
31 Dec 2033 NSA (CNSA 2.0) Web browsers, servers and cloud services use CNSA 2.0 exclusively
31 Dec 2035 NIST (draft) All quantum-vulnerable public-key algorithms disallowed, including P-256, X25519 and Ed25519
31 Dec 2035 UK NCSC Migration complete
31 Dec 2035 EU Medium-risk use cases migrated (low-risk as far as feasible)

Even with no regulator in your sector, your customers, auditors and insurers will ask against these dates. Flarebox measures each of your zones against them.

On Cloudflare? You’re nearly there

Section titled “On Cloudflare? You’re nearly there”

If your sites run behind Cloudflare, most of the migration is already done for you, with nothing to switch on.

Already done by Cloudflare

  • Visitors to Cloudflare: post-quantum key exchange (X25519MLKEM768) for every browser that supports it, about 70% of browser traffic.
  • Cloudflare to your origin: post-quantum automatically whenever the origin supports it. Upgrade the origin and Cloudflare uses it, no setting to change.
  • The road ahead: Cloudflare plans to be fully post-quantum by 2029.

What's left for you

  1. Make the origin post-quantum-capable: a current TLS library (OpenSSL 3.5+, Go 1.24+, Caddy 2.10+, current Java and Windows), or add X25519MLKEM768 to a hand-set curve list.
  2. Can’t upgrade yet? Put a Cloudflare Tunnel in front: cloudflared tunnel run --post-quantum makes the Cloudflare-to-origin hop post-quantum without touching the old server.
  3. Then authentication: Cloudflare accepts ML-DSA for Authenticated Origin Pulls and in the Custom Origin Trust Store, so the edge-to-origin hop can be post-quantum both ways.

For a Cloudflare customer, the pitch to the boss is short: the edge is done; we finish the origins. Flarebox checks every origin behind your zones daily, says why each one isn’t post-quantum yet, and writes the fix or the tunnel config; pqdoctor sidecar does the same from the command line.

What to change: from X to Y

Section titled “What to change: from X to Y”

The standards are final: ML-KEM (FIPS 203, for key exchange), ML-DSA (FIPS 204, signatures) and SLH-DSA (FIPS 205, hash-based signatures), all published by NIST in August 2024. FN-DSA (Falcon, smaller signatures) is being standardised as FIPS 206, and NIST chose HQC in 2025 as a backup KEM built on different mathematics.

Priority: Now recorded traffic is at risk today · Next plan and start · Watch standards or ecosystem not ready yet · Fix anyway already broken without a quantum computer.

Key exchange

Section titled “Key exchange”
From To Why When
ECDHE with X25519 (TLS 1.3 today) X25519MLKEM768 (hybrid) Secure if either X25519 or ML-KEM holds; what browsers, Cloudflare and OpenSSL 3.5 use Now
ECDHE with P-256 / P-384 SecP256r1MLKEM768 / SecP384r1MLKEM1024 The hybrids for environments that must stay on NIST curves (FIPS) Now
Finite-field DH (DHE, ffdhe2048) X25519MLKEM768 Broken by Shor, and slower than ML-KEM Now
RSA key transport (TLS 1.2 TLS_RSA_* suites) TLS 1.3 with X25519MLKEM768 No forward secrecy even today; TLS 1.3 removed it Fix anyway
TLS 1.2 at all TLS 1.3 Hybrid post-quantum key exchange only exists in TLS 1.3 Now
Anything for US national security systems ML-KEM-1024 CNSA 2.0 names ML-KEM-1024; X25519MLKEM768 doesn’t satisfy it Next

Why hybrid first? ML-KEM is new. A hybrid combines it with X25519, so a connection stays safe if a flaw is ever found in either one. It costs about one extra kilobyte in the handshake, and ML-KEM itself is fast. Pure ML-KEM is the long-term end state.

Signatures and certificates

Section titled “Signatures and certificates”
From To Why When
RSA and ECDSA certificates for websites ML-DSA certificates, when browsers accept them from public CAs Browsers don’t yet; meanwhile measure chain sizes (ML-DSA-44 adds about 3.7 KB per certificate) and shorten long chains Watch
Private PKI: service-to-service mTLS, internal CAs ML-DSA-44 / 65 (ML-DSA-87 for CNSA 2.0) You control both ends, so you can move first; Cloudflare already accepts ML-DSA from origins Next
Long-lived root CAs ML-DSA-87 or SLH-DSA A root lives 10–25 years; SLH-DSA rests only on hash functions, the most conservative choice Next
Code, firmware and secure-boot signing (RSA, ECDSA) LMS / XMSS (NIST SP 800-208) or ML-DSA Devices ship for a decade and can’t be re-keyed in the field; CNSA 2.0 requires this exclusively by 2030 Next
Ed25519 / EdDSA ML-DSA (hybrid with Ed25519 where protocols support it) Broken by Shor like every elliptic-curve scheme Next
Documents, JWT / JOSE / COSE tokens signed with RSA or ECDSA ML-DSA IETF specifications are in progress; short-lived tokens can wait, archived signatures can’t Watch

Protocols

Section titled “Protocols”
Protocol From To When
HTTPS, APIs, any TLS X25519 / P-256 X25519MLKEM768: OpenSSL 3.5+, BoringSSL, AWS-LC, Go 1.24+, Caddy 2.10+, JDK 27, Windows Server 2025 (off by default) Now
Mail (SMTP, IMAP with STARTTLS) X25519 / P-256 Same as TLS: the mail server’s TLS library Now
SSH curve25519-sha256, ecdh-sha2-nistp256, diffie-hellman-group14 mlkem768x25519-sha256 (OpenSSH 9.9+, the default since 10.0) or sntrup761x25519-sha512 (default since OpenSSH 9.0) Now
VPN: IPsec / IKEv2 ECDH / DH groups ML-KEM as an additional key exchange (RFC 9370 framework) Next
VPN: WireGuard X25519 No post-quantum handshake in the protocol; a pre-shared key from a post-quantum exchange (e.g. Rosenpass) Next
Messaging X3DH and similar Signal’s PQXDH and Apple iMessage PQ3 show the pattern: hybrid ML-KEM in the handshake Next
Email encryption (S/MIME, OpenPGP) RSA / ECDH ML-KEM in CMS (KEMRecipientInfo, RFC 9629) and the OpenPGP post-quantum drafts Watch
DNSSEC RSA / ECDSA No post-quantum DNSSEC standard yet Watch
Behind Cloudflare The Cloudflare-to-origin hop, once the origin can Cloudflare uses post-quantum automatically when your origin’s TLS library supports it (above), or a Cloudflare Tunnel makes the hop post-quantum today Now

Symmetric crypto and hashes

Section titled “Symmetric crypto and hashes”
From To Why When
AES-128 AES-256 for data that must stay secret for decades Grover roughly halves the strength; NIST still allows AES-128, CNSA 2.0 requires AES-256 Next
SHA-256 SHA-384 / SHA-512 where CNSA 2.0 applies SHA-256 stays fine elsewhere Next
HMAC-SHA-256, ChaCha20-Poly1305, AES-GCM Keep Not meaningfully weakened

Already broken: fix regardless

Section titled “Already broken: fix regardless”
From To When
TLS 1.0 / 1.1, SSL TLS 1.3 (1.2 only where you must) Fix anyway
RSA-1024, DH-1024 Post-quantum (and classical ≥ 2048 meanwhile) Fix anyway
SHA-1 or MD5 signatures SHA-256+ (and then ML-DSA) Fix anyway
3DES, RC4, CBC-mode TLS suites AES-GCM or ChaCha20-Poly1305 Fix anyway

pqdoctor --audit reports all of these from a server’s configuration; see Audit.

What it really costs

Section titled “What it really costs”
  • Mostly upgrades you’d do anyway. Post-quantum key exchange arrives with current TLS libraries. In pqdoctor’s study, the most common reason an origin isn’t post-quantum is a TLS library that predates ML-KEM (OpenSSL 3.0–3.4, OpenSSL 1.1.1, Go before 1.24), or an AWS or F5 load balancer that has a post-quantum setting nobody switched on.
  • A kilobyte per handshake. The hybrid key share is 1,216 bytes instead of 32, and ML-KEM is fast.
  • A few old middleboxes. Some firewalls and proxies drop the larger handshake: under 1% of origins in the study (large-hello-dropped). They’re worth finding before customers do.
  • Bigger certificates, later. ML-DSA chains are several kilobytes larger, enough to cost an extra round trip on some connections. That’s a reason to start measuring now, not to wait.
  • Time to inventory. The real cost is knowing what you have. That part is tooling, not research.

The objections, answered

Section titled “The objections, answered”

“Quantum computers don’t exist yet.” Recorded traffic is decrypted the day one does. For key exchange, the exposure starts when the data is sent.

“We’re behind Cloudflare, so we’re covered.” Mostly, and that’s good news. Cloudflare already protects the visitor-to-Cloudflare hop, and it connects to your servers post-quantum automatically as soon as they can. The one hop left is your origin’s TLS library, or a Cloudflare Tunnel in front of it. See On Cloudflare? You’re nearly there.

“The standards aren’t finished.” ML-KEM, ML-DSA and SLH-DSA were finalised in August 2024. The protocols that matter most today (TLS 1.3 hybrids, SSH) are deployed by the browsers and big providers already.

“It will slow everything down.” About a kilobyte per handshake. Chrome and Cloudflare turned it on by default, for everyone.

“We’ll do it when compliance makes us.” The compliance dates are set (above), and the work before them (inventory, owners, library upgrades, appliance firmware) takes years. Starting when the audit asks means finishing late.

“Isn’t hybrid a half-measure?” It’s the safe measure: it can’t be weaker than what you have today, and it adds protection against the quantum threat. Every major deployment uses hybrid first.

A 90-day plan

Section titled “A 90-day plan”

  1. Weeks 1–2: inventory. Find every endpoint, including the forgotten ones: pqdoctor inventory reads certificate transparency logs, DNS zones, Cloudflare, Kubernetes, Terraform and AWS. Give each one an owner (owners.toml). See Across a company.

  2. Weeks 3–4: measure. Scan everything, inside and out. Every server that isn’t post-quantum gets a cause and a class: a config change, a library upgrade, or a provider setting. See One level down.

  3. Weeks 5–8: fix where it counts. pqdoctor plan ranks the few fixes that move the most traffic, with a proof of how close to the best possible plan it is; usually shared load balancers and ingress first. Apply config fixes safely with automatic rollback; put a sidecar in front of what can’t be upgraded yet. See The leverage plan.

  4. Weeks 9–12: keep it fixed. Tickets per team that close themselves when the server is fixed, a CI check that fails on regressions, and the fleet (in Flarebox) for the trend. Start the signature track: chain sizes, long-lived roots, firmware signing.

What success looks like after a quarter: every TLS endpoint inventoried with an owner; each one that isn’t post-quantum has a cause and an open ticket; the post-quantum share of traffic is reported every week; CI blocks regressions.

Send this to your boss

Section titled “Send this to your boss”

Copy it, change the bracketed parts, send it.

email.txt
Subject: Post-quantum cryptography: a 90-day plan


Hi [name],


Encrypted traffic recorded today can be decrypted once large quantum computers exist
("harvest now, decrypt later"). For anything we must keep secret for years, the risk
starts now, not when the computer arrives.


The dates are set: NIST deprecates RSA-2048-class keys after 2030 and disallows all
quantum-vulnerable public-key algorithms after 2035 (draft IR 8547); the EU, UK and
Australia point to 2030-2035; US national-security systems must buy CNSA 2.0-compliant
products from 2027.


The first step, post-quantum key exchange on our TLS servers, is mostly library and
load-balancer upgrades we would do anyway. Browsers already support it: about 70% of
browser traffic to Cloudflare is post-quantum, and Cloudflare switches its connection
to our servers to post-quantum automatically once they support it.


I'd like [one engineer, half-time, for a quarter] to:
  1. inventory every TLS endpoint and give each an owner (weeks 1-2),
  2. measure which are post-quantum and why not (weeks 3-4),
  3. fix the few shared terminators that carry most of our traffic (weeks 5-8),
  4. add a CI check and a weekly report so it stays fixed (weeks 9-12).


Background, sources and the full algorithm list: https://pqdoctor.com/convince-your-boss/


Thanks,
[you]

Where pqdoctor fits

Section titled “Where pqdoctor fits”
Check one serverIn the browser or with the CLI: is it post-quantum, why not, and the fix.
Roll it out across a companyInventory, tickets, the agent, the GitHub Action and the fleet.
Behind CloudflareFlarebox checks every origin behind your zones daily, with reports against the deadlines.
pqdoctor CLI or FlareboxThe two products, who each is for and why.

Sources

Section titled “Sources”