Cloudflare wants to sign the post-quantum web. Bitcoin can’t find a signer.
The post-quantum cryptographic answers are now largely agreed. Applying them — especially to authentication — is the hard part. Cloudflare’s move to become a certificate authority shows one way it gets done for the web. Bitcoin shows why the same answer doesn’t transfer everywhere. And Europe’s €47.5 million quantum-internet bet won’t help anyone migrating before 2029.
Four things landed in the space of three weeks, and together they make a tidy argument.
The first is a list. Filippo Valsorda — Go cryptography maintainer and one of the more reliably sober voices in the field — published an updated set of “Cryptographic Right Answers”, the developer cheat-sheet tradition that runs back to Colin Percival in 2009. Every asymmetric answer has changed since 2018, most since 2024, and the transition is now a three-year job.
The second is infrastructure. Cloudflare announced it intends to become a public certificate authority (CA), with post-quantum certificates scheduled for the first quarter of 2027 — a direct attack on the hardest unsolved piece of web migration: authentication.
The third is a migration that can’t simply apply the list. Coinbase, custodian of roughly 12% of all bitcoin, set out what it thinks Bitcoin’s post-quantum transition needs — and the answer is considerably more than “pick ML-DSA”.
The fourth is the other quantum security story. The European Commission has awarded the Quantum Internet Alliance €47.5 million to build a quantum network prototype, and a Strathclyde paper from earlier this year quantifies just how hard satellite quantum key distribution really is.
Read together: the algorithms are ready, key exchange is well under way, authentication is where the work now sits, and physics-based alternatives are a research programme, not a migration plan.
The right answers, 2026 edition
Valsorda’s list is worth reading in full, but the parts that matter for infrastructure operators are short.
Key exchange is X25519 + ML-KEM-768 inside a standard protocol. That means X25519MLKEM768 in TLS, its equivalent in SSH, and the X-Wing combination for HPKE (Hybrid Public Key Encryption, the IETF standard for encrypting to a public key). Anything without ML-KEM in its name is on the avoid list. He goes further than most: if implementing the hybrid would keep you on classical key exchange for even an extra month, go straight to pure ML-KEM-768. Harvest-now-decrypt-later makes every classical handshake an active liability.
Signatures have moved too — to ML-DSA-44. This is the bigger shift. As recently as January 2026, the advice was to wait and see on post-quantum authentication. Valsorda now says move, and he rejects hybrid or “composite” signatures for most uses. His reasoning: either you can already rotate back to classical keys if ML-DSA breaks, or your time horizon is long enough that the classical half will fall anyway. He also suggests using fewer signatures altogether — an HMAC or a random session token often does the job a signed token is doing.
Symmetric crypto is fine. Grover’s algorithm does not meaningfully threaten AES-128, let alone AES-256. Pop the champagne for your encrypted backups. The asymmetric layer is where the work is.
The TLS stack matters as much as the algorithm. He recommends memory-safe stacks (rustls, Go’s crypto/tls) or well-maintained OpenSSL forks (BoringSSL, AWS-LC). He pointedly declines to recommend OpenSSL itself, and notes that OpenSSL earlier than 3.5 doesn’t support X25519MLKEM768 at all. If you’re in the cloud, use the provider’s load balancer — but check you’ve actually selected a post-quantum security policy. On RHEL 9 and derivatives, post-quantum is opt-in.
For websites, the certificate advice is about plumbing. Wire up a popular, well-supported ACME client (Automated Certificate Management Environment, the protocol Let’s Encrypt made standard) and keep it up to date, because Merkle Tree Certificates roll out in 2027 and you want to be positioned to receive them. That sentence turns out to be the hinge for the next section.
Two smaller notes. The list assumes no compliance regime; CNSA 2.0 (the US National Security Agency’s post-quantum suite) and FIPS 140-3 environments will substitute in places. Notably, CNSA 2.0 still endorses stateful hash-based signatures (LMS/XMSS) for firmware signing, which Valsorda puts on his general avoid list. And his footnotes include a long run of 2026 CVEs in smaller TLS libraries — certificate validation bypasses, mostly. The algorithm is rarely what breaks.
Cloudflare becomes a CA: the authentication problem, at web scale
Post-quantum key exchange is a configuration change; post-quantum authentication is a supply-chain problem. Every TLS connection relies on a certificate chain issued by a CA and trusted by the browser, and ML-DSA signatures are large — roughly 2.4 KB each against 64 bytes for today’s elliptic-curve signatures. Put several in every handshake and you get exactly the slowdowns described in our 10 KB and 40 KB cliffs piece.
Cloudflare’s 29 September announcement, covered by Quantum Computing Report, is its answer. It is a vendor announcement about a service that doesn’t exist yet, and should be read that way. But the design choices are instructive.
Merkle Tree Certificates (MTCs) avoid sending big signatures with every connection. Instead of signing each certificate individually, the CA batches certificates into a public, append-only log and signs only the log’s checkpoint. A server then presents a short proof — a handful of hashes — showing its certificate is in that log. Cloudflare co-authored the IETF draft, Chrome has named MTCs as its preferred route to post-quantum web authentication, and Cloudflare plans production issuance in Q1 2027. Quantum Computing Report cites Chrome Beta trials showing MTCs were slightly faster than classical chains at the median; that is Cloudflare’s own trial data, not independent measurement.
Backwards compatibility is bought, not built. A new root takes years to reach the world’s devices and never reaches the ones that have stopped updating. So Cloudflare has signed an agreement to acquire an established GlobalSign root (trusted since 2012) while applying to the Chrome, Apple, Microsoft and Mozilla root programmes for new roots aimed at Chrome’s new Quantum-resistant Root Program. Old root for old devices, new roots for the post-quantum future.
Automation is a condition of issuance. Cloudflare will be ACME-first and will only issue to clients that support ACME Renewal Information (ARI, RFC 9773), which lets the CA tell clients when to renew. The aim is to be able to pull renewal windows forward and replace certificates quickly during an incident, rather than choosing between revoking promptly and keeping customer sites online.
The pitch is resilience against concentration. Cloudflare points out that much of the free, automated certificate ecosystem runs through Let’s Encrypt, and proposes itself as a second large, free, automated issuer — plus reproducible builds, attested HSMs and a public operational dashboard. The irony that the reduction in concentration risk comes from a company already fronting more than 20% of global web traffic is left as an exercise for the reader.
The useful takeaway is that, for public websites, post-quantum authentication is going to arrive largely through CAs, browsers and ACME clients — if you have the automation to receive it. Analyst firm Futurum makes the corresponding point: public certificates aren’t where most enterprise post-quantum exposure sits. Internal PKI — private CAs, VPNs, device certificates, service-to-service authentication — is, and nobody is going to fix that for you.
Bitcoin: what migration looks like when you can’t just ship it
If Cloudflare shows the web’s authentication problem being solved centrally, Coinbase’s post shows what happens when there is no centre. It’s a vendor post with a clear commercial interest — Coinbase’s institutional custody business shapes several of its asks — so read it as a stakeholder position rather than neutral analysis. The constraints it lays out generalise well beyond crypto-assets.
Generic rankings don’t transfer. Coinbase makes the point directly: TLS or PKI rankings of signature schemes don’t map onto Bitcoin, because every Bitcoin signature is stored forever and verified by every node. Size and verification cost dominate in a way they never do in a TLS handshake — and there is no MTC-style trick, because there is no CA to batch through. “Use ML-DSA-44” is the right answer for a web server and an open question for a blockchain.
Separate the container from the signature. The most transferable idea in the post is that the output format (the structure that locks funds) should be decoupled from the signature algorithm, so schemes can be added, replaced or supplemented without a redesign. Coinbase favours proposals such as BIP-360’s P2MR and P2TRv2 on this basis, along with a “1-of-2” transition where the same funds can be spent with either a classical or a post-quantum key. This is crypto-agility (the ability to swap algorithms without rebuilding the system) expressed in consensus rules.
State is dangerous. Stateful hash-based signatures can be smaller and faster, but reusing state can mean immediate forgery. Coinbase notes that a geographically distributed signing fleet — which is how any large operator achieves availability — can’t easily hold the exclusive lock stateful signing requires. Anyone considering LMS or XMSS for firmware signing should read that paragraph twice.
The lost-key problem has no clean answer. Coins with permanently exposed public keys, reused keys, dormant holdings and lost seeds form what Coinbase rightly treats as a separate governance problem: freeze, rate-limit, sunset or rescue, each with losers. The post asks that any rescue mechanism be shown to be quantum-safe itself, which is not a given.
Bitcoin is an extreme case: no central authority, irreversible transactions, and signatures that live forever. But “long-lived signed artefacts that can’t be re-signed” also describes legal records, engineering certificates and archived contracts.
The scenic route: quantum networks
The Quantum Internet Alliance award is genuine progress for quantum networking. The consortium — more than 50 institutions across 12 EU member states — will build a prototype linking quantum computers over metropolitan-scale fibre spanning hundreds of kilometres, with the University of Innsbruck and AQT receiving €5.4 million for trapped-ion network nodes. Secure communications is one stated application, alongside distributed quantum computing and precision timing.
It’s worth being clear about what this is: a research prototype for quantum networking, of which quantum key distribution (QKD) is one application. It isn’t a migration path for anyone with a 2029 deadline.
The physics explains why. QKD in fibre is limited by exponential loss to roughly 100 km without repeaters that don’t yet exist at scale; satellites are the proposed workaround. That’s where the Strathclyde paper comes in.
The team modelled a low-Earth-orbit satellite sending entangled photon pairs to two optical ground stations at once (the BBM92 protocol, which doesn’t require trusting the satellite), with a rigorous finite-key security analysis that accounts for the statistical penalty of having only a few minutes of data per pass.
Distance is the hard ceiling. At a typical 500 km orbit, the model generates key only when the two ground stations are within about 1,800 km of each other — roughly 37% of the distance the satellite can actually see. Continental coverage needs at least four ground stations per span.
Darkness is required. Key generation works at night and, with careful data selection, through twilight. Full daylight suppresses it.
The model is generous, and reality was less so. Adjusted to approximate China’s Micius satellite, the model predicts hundreds of kilobits per pass. Micius actually reported a final key on the order of a hundred bits after multiple passes. The authors attribute much of the gap to real overpass geometry and loss, and acknowledge that their intrinsic error rate assumption is optimistic.
The headline annual figure for an idealised configuration — about 870 megabits a year between two ground stations 500 km apart — is plenty of AES keys. But QKD distributes keys; it doesn’t authenticate who you’re exchanging them with. That still needs classical or post-quantum signatures — which, as the rest of this piece shows, is the hard part. This is central to why the NSA does not recommend QKD for national security systems, and the UK’s NCSC has held a similar position since 2020: post-quantum cryptography is cheaper, easier to maintain, and still needed anyway.
The NZ read
Valsorda’s list is effectively the checklist our scans test against. Our June 2026 re-scan of 118 NZ critical infrastructure entities found 52.2% negotiating post-quantum key exchange — but only 25 doing so at their own origin servers. Nine endpoints were still TLS 1.2-only, which rules out X25519MLKEM768 entirely; TLS 1.3 is a prerequisite. Forty-nine classical origins hadn’t moved. Each is a “right answer” not yet applied, and the usual blockers are the ones Valsorda names: an old OpenSSL, a load balancer without a post-quantum policy selected, an operating system that needs to opt in.
Post-quantum web authentication will arrive through automation — so check you have some. Cloudflare’s model makes ACME and ARI support a condition of issuance, and MTCs only reach sites whose certificate tooling can receive them. Organisations still renewing certificates by hand — common with paid, manually validated certificates — will be last in the queue. A certificate inventory that records how each certificate is renewed, not just when it expires, is now a migration prerequisite.
The CDN lesson applies to certificates too. Cloudflare-fronted endpoints in our scan, such as the Reserve Bank and Payments NZ, are likely to see post-quantum authentication at the edge early, on Cloudflare’s timeline rather than their own. That’s welcome, but it’s the same trade-off we saw with key exchange: KiwiRail had post-quantum protection in April only because Imperva provided it, and when that changed its origin fell back to classical. CDN-delivered PQC is only as stable as the CDN contract. The durable position is post-quantum at the edge and the origin — for certificates as well as key exchange.
Internal PKI is the bigger job, and nobody is measuring it. Our scans test public key exchange, because that’s what harvest-now-decrypt-later threatens today. Private CAs, VPN gateways, device and service certificates, and code and firmware signing all need their own migration, with longer lead times and more vendor dependencies. For NZ banks, whose cryptographic decisions are largely made by Australian parents, that dependency chain runs through Sydney and Melbourne.
The Bitcoin lessons generalise. Design for crypto-agility so the next algorithm swap isn’t another rebuild. Treat stateful signatures with real caution. And identify the long-lived signed artefacts you can’t re-sign — seven-year AML/CFT records, engineering IP, legal archives — before deciding what to do about them.
QKD is not a reason to wait. Auckland to Sydney is a little over 2,000 km, beyond the modelled reach of a single-satellite link on the Strathclyde baseline, and New Zealand has no QKD programme of the European kind. Meanwhile NZ remains the only Five Eyes member without a formal PQC migration deadline, and the industry’s 2029 target — now described by Valsorda as consensus — is a little over three years away. Southern Cross Cables showed between April and June that an operator can move its own origin to post-quantum key exchange within weeks. Standard TLS libraries, configured correctly, and certificate tooling that can keep up, are the route available now.
References
- Valsorda, F. (12 October 2026). (Post-Quantum) Cryptographic Right Answers. words.filippo.io/right-answers
- Goldsmith, S. / Cloudflare (29 September 2026). Building a certificate authority for the whole Internet. blog.cloudflare.com
- Abdel-Kareem, M. / Quantum Computing Report (30 September 2026). Cloudflare Launches Public Certificate Authority to Secure the Web Against Quantum Threats. quantumcomputingreport.com
- IETF. Merkle Tree Certificates (Internet-Draft, PLANTS working group). datatracker.ietf.org
- Agrawal, S. / Coinbase (13 October 2026). Working Together on Bitcoin’s Post-Quantum Readiness. coinbase.com
- Flint, R. / Quantum Zeitgeist (13 October 2026). Coinbase wants to safeguard Bitcoin funds lost to quantum attacks. quantumzeitgeist.com
- Quantum Zeitgeist (14 October 2026). Quantum Internet Alliance wins €47.5 million for network prototype (sourced from AQT). quantumzeitgeist.com
- Sidhu, J. S., McCarthy, S. E., Paterson, C., & Oi, D. K. L. (February 2026). Operational limits to entanglement-based satellite quantum key distribution. arXiv:2602.11833
- US National Security Agency. Post-Quantum Cybersecurity Resources — Quantum Key Distribution and Quantum Cryptography. nsa.gov
- Kaysec (3 June 2026). Seven Weeks Later: NZ Critical Infrastructure PQC — The June 2026 Update. kaysec.spinsphere.xyz
- Kaysec (15 April 2026). NZ Critical Infrastructure: First Public PQC Readiness Assessment. kaysec.spinsphere.xyz
Kaysec is the post-quantum security practice of Spinsphere, a New Zealand-based quantum technology company. We help NZ organisations with cryptographic inventory, HNDL risk assessment, TLS configuration auditing, and PQC migration planning. Get in touch.
If it lives long, protect it.
English
日本語
简体中文
한국어