A Post-Quantum Future for Let’s Encrypt

This article explores the future of TLS in a post-quantum world. It details where Let’s Encrypt is headed with post-quantum cryptography, which parts of the TLS stack change first, and how to prepare your servers, clients, and automation for a quantum-resistant transition. Hybrid approaches such as Post-Quantum SSH on VPS have already combined classical and post-quantum algorithms to maintain current security while anticipating future threats.

Why “Harvest Now, Decrypt Later” Demands Immediate Action

The key challenge is not a future browser warning; it is that traffic captured today could be decrypted later. This “harvest now, decrypt later” scenario enables attackers to record encrypted TLS sessions now and decrypt them once quantum-capable systems emerge. Think of it as stealing a locked filing cabinet today with the expectation that the key will be found in the future.

While NIST IR 8413 does not label a date when RSA-2048 or similar algorithms become vulnerable, it does set a planning window. Organizations should expect significant transition work by the 2030 timeframe and begin preparing well in advance. Infrastructure lifecycles often span 5–10 years – this includes load balancers, embedded clients, enterprise proxies, mobile apps, and certificate automation systems. Waiting too long until the threat is evident may cause disruptions and increased risks.

In addition to cryptographic risks, there is a compliance risk. If TLS sessions carry sensitive data such as API tokens, health data, legal documents, or internal admin traffic, retroactive decryption could transform “secure in transit” into data that is eventually plain text. Archived packet captures, CDN logs, and intercepted backbone traffic become increasingly vulnerable over time.

The bottom line is: the longer your data’s shelf life, the faster you must act.

What Let’s Encrypt’s Post-Quantum Plan Means for Your TLS Infrastructure

For most operators, the first major change won’t be about swapping certificates; it is about introducing hybrid TLS at the handshake layer. This involves browsers and servers combining a classical key exchange with a post-quantum one to keep backward compatibility while adding quantum resistance. The impact will be seen in your web server, TLS library, reverse proxy, CDN edge, and monitoring systems long before the certificate renewal process is affected.

Let’s Encrypt’s current direction can be broken down into phases. Initially, there is near-term testing for hybrid TLS compatibility, which is then followed by broader production readiness once standards and client support solidify. The industry is following NIST’s post-quantum work – with ML-KEM (formerly Kyber) selected for key establishment, and ML-DSA (formerly Dilithium) along with SLH-DSA chosen for signatures, all standardized in 2024. In practice, the new key exchange in TLS might be adopted sooner than replacing certificate signatures in every system given the delicate nature of the certificate ecosystem.

The sequence is clear: handshake support comes first, followed by certificate issuance, with automation bridging the two.

For issuance workflows, ACME is not the sole concern. The challenge lies in the surrounding components – whether it’s the version of OpenSSL or BoringSSL, builds of nginx or HAProxy, container images, Kubernetes ingress controllers, or internal scripts that assume current key types and certificate sizes. Even if your renewal pipeline handles RSA or ECDSA correctly, failures may occur if downstream parsers, HSM policies, or mTLS clients reject the new algorithms.

Consider this process less as an isolated crypto upgrade and more as an automation audit. When renewing certificates through CI/CD, verify where keys are generated, how CSRs are parsed, and which systems inspect certificate metadata. Inflexible systems elevate your migration risk from mathematical to operational. The decision becomes not just when to switch, but where in your TLS path you are the least adaptable.

Comparing Post-Quantum Algorithm Families for TLS

If your TLS path is rigid, the primary question becomes which post-quantum algorithm family minimizes operational difficulties while ensuring security. For mainstream HTTPS, the preferred solution is a lattice-based key exchange in hybrid mode. This option has seen extensive real-world testing in browsers, TLS libraries, and certificate tooling. Although hash-based and code-based systems have niche applications in signatures or long-term verification, they are less suited to typical HTTPS handshakes.

The conclusion is that ML-KEM-based hybrid key exchange is the best practical option. It increases data sizes by only kilobytes – not megabytes – and integrates smoothly into the evolving TLS framework.

Lattice-Based Algorithms (e.g., Kyber)

Lattice-based cryptography offers a balance of security, compact packet size, and deployability. ML-KEM, which succeeds Kyber, is based on module learning with errors – a problem that has withstood extensive academic and NIST scrutiny. For TLS, the takeaway is that ML-KEM-768 proves compact enough for busy web servers. In practical terms, ML-KEM-768 adds around 1.18 KB of public key material and 1.09 KB of ciphertext, meaning a hybrid handshake with X25519 sees only a small increase in data. On broadband, this might result in a single-digit millisecond delay; on mobile, the impact, while larger, is still manageable compared to the hefty sizes of code-based alternatives.

The strong industry backing, including ACVP testing focused on ML-KEM and ML-DSA, makes lattice-based choices easier to justify from both procurement and architecture perspectives.

Hash-Based and Code-Based Options

Hash-based signatures, such as SLH-DSA, are designed for high-confidence signing based on robust hash security rather than compact TLS handshakes. However, their larger sizes (8 KB to 30 KB+ per signature) make them less appealing for handshake operations. This is much like sending invoices in padded envelopes – secure but inefficient.

Similarly, code-based cryptography using systems like Classic McEliece offers strong security but at the cost of enormous public keys (hundreds of kilobytes to around a megabyte). These sizes would severely impact handshake performance, memory, and distribution of certificates. As a result, current ACME-related testing centers on hybrid TLS and lattice-based algorithms, leaving code-based methods primarily in research or specialized applications.

Performance Implications for Real-World TLS Deployments

Many websites will not face outright compatibility issues but rather experience heavier handshakes that lead to slower initial visits, increased CPU usage per connection, and reduced capacity on smaller VPS instances. For example, a server already nearing a 55% CPU ceiling during traffic surges could see that figure rise to 75% or more under hybrid PQC load.

A classical TLS 1.3 connection using X25519 finishes the handshake with minimal payloads, while a hybrid exchange like X25519 + ML-KEM-768 adds only a few kilobytes. On a low-latency network, this may mean only a 2–8 ms delay. Over networks with 90–140 ms round-trip times, such as 4G or long-haul links, this can extend connection setup by 10–30 ms. Although these delays are small, combined with other processing delays they can affect user experience metrics like Largest Contentful Paint (LCP).

CPU cost is another factor. Hybrid key exchanges require more cryptographic processing compared to classical ECDHE, and the cost of signature verification may rise as certificate practices change. Benchmarks vary with TLS library, CPU generation, and hardware acceleration, but lab tests generally show modest latency increases along with noticeable CPU load—especially on systems with 1–2 vCPUs handling many short-lived HTTPS connections.

Connection reuse can mitigate much of this overhead. Techniques such as HTTP keep-alive, upstream connection pooling, and TLS session resumption help reduce the frequency of full handshakes. For example, a sample nginx configuration might set a longer connection timeout to prevent unnecessary handshakes for repeat asset requests:

http {
    keepalive_timeout 30s;
    keepalive_requests 1000;
}

You can verify this setup using the following commands:

inginx -t && systemctl reload nginx
curl -I -v https://yourdomain.com 2>&1 | grep -i "keep-alive"

Additionally, this OpenSSL command checks for TLS session resumption:

openssl s_client -connect yourdomain.com:443 -tls1_3 -sess_out sess.pem < /dev/null
openssl s_client -connect yourdomain.com:443 -tls1_3 -sess_in sess.pem < /dev/null | grep -i reused

For those planning PQC trials, selecting infrastructure with sufficient vCPU headroom and low network RTT is essential to reduce handshake overhead. It is also worth noting that VPSus VPS solutions are configured with modern 2–4 vCPU options and optimized network configurations across multiple regions, which can support the additional cryptographic workload.

Building a Crypto-Agility Roadmap for Your Organization

If your TLS path is difficult to modify, the solution is not to wait for standards to settle but to build crypto-agility now. This means establishing the capability to switch algorithms, libraries, and certificate settings with minimal disruption. In practice, you should plan a 90-day assessment, a 90–180 day hybrid pilot, and a 6–18 month full migration based on the number of clients, proxies, and internal services involved.

Phase 1: Assessment (Days 0–90)

Begin by developing a comprehensive certificate and termination inventory that covers your public sites, API gateways, load balancers, ingress controllers, service meshes, outbound mTLS, and any other interface that terminates TLS within your network. Record key details such as certificate source, ACME client, TLS library, and client population. An overlooked enterprise proxy or outdated runtime can later trigger outages.

For example, you could run the following command on Linux hosts to quickly scan for public-facing certificates:

find /etc /usr/local/etc /opt -type f \( -name "*.crt" -o -name "*.pem" -o -name "fullchain*.pem" \) 2>/dev/null | head -100
openssl version -a
nginx -V 2>&1 | head -5

Verify with these commands as well:

haproxy -vv 2>/dev/null | head -20
apachectl -V 2>/dev/null | head -10

Assign ownership appropriately: Platform or SRE teams should manage TLS termination points; Security teams must define acceptable algorithms and fallback policies; Application teams need to identify any pinned clients or SDK constraints; and Compliance or Legal should review retention and regulatory requirements.

Phase 2: Hybrid Pilot (Days 90–270)

The best initial step is to launch a hybrid TLS pilot on non-critical or low-blast-radius endpoints such as staging environments, internal dashboards, or a regional API edge. This is not about making every endpoint quantum safe immediately; rather, it is about proving that your stack can negotiate new ciphers, renew certificates, and fallback gracefully if necessary.

A key milestone in this phase is the ACME client and automation review. Update your client and scripts by deploying hooks, revising parser logic, managing secret distribution, scheduling certificate reloads, and setting up monitoring checks. Often, automated renewal pipelines fail not during the certificate request but due to issues in the supporting code.

Perform fallback testing by simulating three scenarios: a modern browser, an older managed client, and a scenario where the hybrid option is not available. This will clarify which clients negotiate successfully, which fallback to classical TLS, and which may fail altogether. To monitor the handshake, try this OpenSSL probe:

openssl s_client -connect pilot.example.com:443 -tls1_3 -groups X25519:P-256 2>/dev/null | grep -E "Server Temp Key|Protocol|Cipher"

Then verify with:

curl -I --tlsv1.3 https://pilot.example.com

Phase 3: Full Migration (6–18 Months)

A full migration should be driven by policy rather than ad-hoc fixes. Establish change windows, define rollback triggers, and enforce a compliance checkpoint before rolling out widely. Prepare a rollback plan that details how to revert to previous TLS library versions, configuration settings, and certificate profiles, and identifies the responsible personnel.

For cases where many clients are unknown, a prolonged hybrid mode may be needed. Conversely, if you control both endpoints, the migration can be accelerated. An incomplete inventory after 90 days indicates a need for improved asset visibility. For further guidance on security strategy, consider the insights provided in Top VPS Security Questions Answered by Experts.

Case Studies: Lessons from Early PQC Pilots

Piloting post-quantum TLS on controlled infrastructure is the fastest way to de-risk your migration. Early pilots reveal that while the cryptography itself is manageable, the surrounding stack – including libraries, middleboxes, and rollout discipline – is what determines success.

An indie developer’s approach highlights the value of a PQ-TLS test harness deployed across global VPS nodes. For instance, this bash snippet compares connection timings:

for i in {1..10}; do
  curl -o /dev/null -s -w "connect=%{time_connect} tls=%{time_appconnect} starttransfer=%{time_starttransfer}\n" https://pilot.example.com
done

Verify with:

curl -I https://pilot.example.com

The results show that network distance dominantly affects performance impact.

Navigating Compliance and Standards for Quantum-Safe TLS

For a successful PQ-TLS pilot, it is crucial to demonstrate compliance with auditor, regulator, and internal risk requirements. Post-quantum migration is not only about cryptography but is also a governance challenge connected to NIST standardization, national security directives, and data retention policies.

NIST finalized its core PQC standards in 2024 by selecting ML-KEM for key establishment and ML-DSA for signatures. Broader guidance from NIST indicates that legacy cryptography may not protect long-term data, pushing organizations to plan for migration well before 2030. Similarly, directives like CNSA 2.0 and regulations such as GDPR (which requires “appropriate technical and organisational measures”) emphasize the need for a quantum-resistant posture.

The takeaway is clear: while 2024 marked the beginning of modern PQC standards, 2030 remains the critical deadline for many organizations. Hybrid certificates and handshakes, though transitional, require thorough documentation outlining client support and fallback mechanisms.

To further secure your environment, consider these steps:

1. Turn off HTTP/2 on any public IIS site that doesn’t strictly require it and enforce strict header, request, and timeout limits if maintained.
2. Document exceptions and schedule regular patch reviews. Track server builds, IIS versions, and bindings to facilitate a quick rollback if needed.
3. Deploy a reverse proxy or managed WAF. This offers an added layer of defense against malformed HTTP/2 traffic.

By integrating these measures, your infrastructure becomes more adaptable and secure.