Let's Encrypt frames PQ migration as a coordination problem rather than a cryptography problem, committing to issue ML-DSA certificates by end of 2026 and deprecate pure-classical ECDSA after 2030. By publishing concrete dates, the CA that issues roughly half the world's TLS certificates is putting public pressure on root programs, browsers, and TLS libraries to align their own timelines or explain the delay.
By submitting the roadmap to HN where it drew 237 points, SGran amplified the framing that a dated commitment from a major CA is the catalyst the ecosystem has been waiting for. The high score reflects cryptographer enthusiasm that someone is finally putting timelines on what has been years of abstract 'crypto agility' talk.
The editorial highlights that ML-DSA-65 signatures are 3,309 bytes versus 64 for ECDSA P-256, blowing a typical certificate chain from one TCP segment to five or more. This collides directly with QUIC's 3x amplification limit on initial packets and TLS 1.3's round-trip budget — the exact metrics CDNs spend heavily to optimize, and a serious problem for embedded devices with hardcoded buffer sizes.
The thread split with operators immediately asking the practical second question after the cryptography applause: how big are the certs and what does that do to handshake latency? Their concern is that the migration is being driven by cryptographic correctness without enough attention to the bytes-on-the-wire consequences for real deployments.
Rather than a flag-day cutover, Let's Encrypt explicitly commits to a multi-year overlap where RSA and ECDSA continue to be issued alongside ML-DSA, with hybrid chains bridging the transition. This pragmatic approach acknowledges that root programs, TLS libraries, and embedded devices cannot all flip at once, and that pure-PQ issuance only makes sense after the ecosystem catches up.
Let's Encrypt has published its post-quantum roadmap, and unlike the usual industry hand-waving about "crypto agility," it comes with dates. The CA plans to issue its first ML-DSA (FIPS 204, the standardized form of CRYSTALS-Dilithium) certificates by the end of 2026, deprecate pure-classical ECDSA issuance some time after 2030, and operate hybrid chains in between. The post (`letsencrypt.org/2026/06/03/pq-certs`) frames this as a coordination problem more than a cryptography problem: Let's Encrypt can mint PQ certs the day NIST's CA/Browser Forum guidance lands, but nobody can use them until root programs ship trust anchors and TLS libraries negotiate the new algorithms.
The technical substrate is ML-DSA-44 and ML-DSA-65 — the two parameter sets most likely to clear browser performance bars. RSA and ECDSA aren't going anywhere immediately; Let's Encrypt is explicit that this is a multi-year overlap. What's new is that the agency that issues roughly half the world's public TLS certificates has now committed to a date, which forces the rest of the stack — Chrome's root program, Mozilla's CA policy, OpenSSL 3.x, BoringSSL, rustls, Go's crypto/tls — to either move or publicly explain why they aren't.
The HN thread (237 points) split predictably between cryptographers cheering the timeline and operators asking the obvious second question: how big are the certificates, and what does that do to my handshake.
Here is the number that will define the next four years of TLS engineering: an ML-DSA-65 signature is 3,309 bytes; an ECDSA P-256 signature is 64 bytes. A full certificate chain that today fits in a single TCP segment will, post-quantum, span five or more. That sounds academic until you remember that QUIC's initial packet is amplification-limited to 3x the client hello, that TLS 1.3's ClientHello-to-Finished round trip is the thing CDNs spend millions to shave milliseconds off, and that every embedded device with a hardcoded 4KB cert buffer is about to become e-waste or a CVE.
The community reaction in the HN thread crystallized around three camps. The first — call them the urgency camp — points out that "harvest now, decrypt later" attacks against today's TLS sessions are already economically rational for nation-states, and that the 2030 deprecation date is *late*, not early. The second camp, mostly people who run actual networks, is more worried about the handshake bloat than the quantum threat: they want hybrid certs (classical + PQ in one chain) to be the default for a decade, not a transitional kludge. The third camp asks the question nobody wants to answer: what happens to ACME-DNS-01 when the TXT record needed to prove control of a domain grows past the 255-byte string limit?
The honest answer is that PQ migration is going to expose every place in the stack where someone assumed signatures were small. DNSSEC has the same problem and has been quietly delaying its own PQ migration for similar reasons. OCSP stapling becomes more attractive because it amortizes the signature size across many connections. Certificate compression (RFC 8879) goes from "nice to have" to "mandatory." Pre-shared key resumption stops being a TLS 1.3 optimization and starts being a survival mechanism for mobile clients on flaky links.
There's also a quieter business story. Let's Encrypt's commitment puts pressure on DigiCert, Sectigo, and GlobalSign — all of whom have PQ pilots but no public issuance dates. The commercial CAs have historically used "enterprise-grade" features to justify their pricing; if the free CA ships PQ first, that narrative gets harder to sustain.
If you operate TLS at scale, three things move from "someday" to "this quarter's roadmap." First: audit every place in your infrastructure that assumes a certificate chain fits in a small fixed buffer — load balancer configs, hardware HSM firmware, IoT bootloaders, anything that parses X.509 with a hand-rolled ASN.1 reader. These are the things that will break in 2027, not gracefully. Second: turn on certificate compression now. It's been in TLS 1.3 since 2019, browser support is good, and it's the single biggest mitigation for PQ handshake bloat you can deploy without waiting for anyone else.
Third, and least obvious: rethink your TLS termination topology. If your edge terminates TLS and re-originates to backends over plaintext or mTLS-with-classical-certs, the post-quantum transition becomes a one-place problem instead of a fleet-wide one. Service meshes that do mTLS everywhere (Istio, Linkerd, Consul Connect) are going to have a worse time than centralized-edge architectures, because every pod-to-pod handshake pays the PQ tax. The 2026-2030 window is the right time to consolidate where cryptographic agility actually lives.
For application developers the impact is smaller but real. If you're shipping a CLI tool, mobile app, or embedded firmware that pins certificates or hardcodes a CA bundle, the bundle is about to get materially larger. If you depend on `acme.sh`, certbot, or lego, watch their release notes — the ACME client side of PQ is straightforward but not zero work.
The interesting question isn't whether Let's Encrypt hits its 2026 date — it probably will, because the CA software is the easy part. The interesting question is which large operator publicly fails first when the handshake bloat hits production, and what the postmortem looks like. Bet on something embedded, something with a 5-year refresh cycle, and something nobody thought to test with a 15KB certificate chain. The cryptography is solved; the engineering is about to start.
Interesting development. Merkle Tree Certificates throw away decades of cruft, but also decades of battle testing and ancillary tools. I trust the teams involved, but this will be a hell of a project.Still better than the alternatives that would saddle us with worse performance for ~ever.
From the article not everything is fully clear to me yet.What I do think though, is that Certificate Transparency as we currently have it is a fairly broken mess. Maybe partly due to RFC 6962.The easiest task might just be validating SCTs. Easy, you just validate a signature... But no, that doesn&#x
So what's the timeline for a quantum future? 20 years? 50 years? 100? My concern is that it's primarily a materials science problem (hence, it is going to take a very long time).
I've been working on a new project using ed25519 signatures and discovered they are not quantum resistant.... I went with ed25519 due to possibility of using openssh keys. Any opinion on this choice at the light of this article and other quantum computing news?
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
We are truly living in a science fiction future where quantum code cracking is not a remote possibility but a near term risk we are planning for.In Vernor Vinge's novel "A Fire Upon the Deep" one of the most valuable commodities were one time pads that are physically transported to co