Post-Quantum TLS: How PQC Changes Certificates, Handshakes, and Performance

Part of the Post-Quantum PKI Migration Guide

In one sentence: Post-quantum certificates are 10-15x larger and TLS handshakes will require more bandwidth and potentially extra round trips—but the performance impact is manageable with proper planning, and the alternative (broken encryption) is not.

Why This Matters: The Executive View

Your entire digital infrastructure runs on TLS—every website visit, every API call, every mobile app connection. The shift to quantum-resistant algorithms doesn't just change which mathematics protects those connections. It changes the physical characteristics of every certificate and every handshake.

For engineering leaders and CTOs, this means:

• Bandwidth budgets change. TLS handshakes that use 2-4KB today will use 15-30KB with quantum-safe certificates. Multiply by millions of connections per day.
• Latency increases. Larger certificates may not fit in a single TCP packet, adding round trips on high-latency links (mobile networks, satellite, global APIs).
• CDN and load balancer configurations need updating. Buffer sizes, timeout settings, and caching policies designed for RSA certificates won't work for ML-DSA.
• Hybrid mode doubles the overhead—temporarily. During the PQC transition, certificates contain both classical and quantum-resistant algorithms simultaneously.

None of this is a reason to delay. The performance impact is real but manageable. The alternative—continuing to use encryption that will be broken by quantum computers—is not. This guide quantifies the impact and provides practical mitigation strategies.

How TLS Works Today (Baseline)

Understanding what changes requires understanding the baseline. A standard TLS 1.3 handshake involves:

1. ClientHello: Client sends supported cipher suites, key share (ECDHE public key, ~65 bytes for P-256)
2. ServerHello + Certificate: Server responds with selected cipher suite, key share, and certificate chain (typically ~3-4KB for RSA-2048 chain)
3. Finished: Both parties derive session keys and confirm

This completes in one round trip (1-RTT). The total handshake data is typically 4-6KB, fitting comfortably within initial TCP congestion windows on most networks.

Today's certificate sizes

Sizes are approximate and include DER encoding plus typical X.509 extensions overhead.

What Changes with Post-Quantum Certificates

Certificate size comparison

The quantum-resistant algorithms standardised by NIST (FIPS 203, FIPS 204, FIPS 205) use fundamentally different mathematical structures—lattice-based cryptography for ML-KEM and ML-DSA, hash-based cryptography for SLH-DSA. These produce larger keys and signatures:

Sizes are approximate and include DER encoding plus typical X.509 extensions overhead.

Key takeaway: ML-DSA-65 (formerly CRYSTALS-Dilithium) certificates are approximately 3-5x larger than RSA equivalents. SLH-DSA is impractical for TLS; it's designed for root CAs and offline signing only.

Key exchange impact (ML-KEM)

ML-KEM (FIPS 203, formerly CRYSTALS-Kyber) replaces ECDHE for key exchange in TLS 1.3:

ML-KEM key exchange adds approximately 2KB to the handshake—significant but less impactful than the certificate size increase.

Total handshake size: quantum-safe vs classical

"Handshake size" below is the full server-to-client flight: ServerHello, certificate chain, server key share, extensions, and Finished message.

Sizes are approximate and include DER encoding, TLS record headers, and typical extensions overhead.

Performance Impact: What to Expect

Bandwidth

For a site handling 10 million TLS connections per day, the handshake bandwidth increase:

• Today: ~40 GB/day in handshake data
• With PQC: ~170 GB/day
• During hybrid transition: ~220 GB/day

For most enterprises, this is well within infrastructure capacity. For high-traffic services (CDNs, APIs processing millions of requests per second), it's a line item in capacity planning, not a crisis.

Latency

The critical question: does the larger handshake add round trips?

TLS 1.3 is designed to complete in 1-RTT. The initial TCP congestion window (IW) must accommodate the server's response (ServerHello + Certificate + key share). RFC 6928 set the standard minimum at IW10 (10 segments × 1,460 bytes = ~14.6KB), but modern TCP stacks and CDNs frequently use higher values. With ML-DSA certificates:

• Pure PQC (~17KB): Exceeds IW10 by a small margin. On a server still using the RFC 6928 default, this may require 2 RTTs instead of 1. However, many production environments already use IW20+ or larger, reducing the extra-RTT risk significantly—a pure PQC handshake fits comfortably within a 20-segment initial window (~29KB).
• Hybrid (~22KB): Still fits within IW20. Only environments stuck on IW10 (or constrained middleboxes) are likely to see an extra round trip.
• Impact when an extra RTT does occur: On a 50ms latency link, this adds 50ms to connection establishment. On a 200ms link (mobile, intercontinental), it adds 200ms.

In practice: Major CDN providers (Cloudflare, Fastly, Akamai) and cloud platforms already tune initial congestion windows well above IW10. If you control your servers, verify your current IW setting—the extra-RTT concern is often already mitigated. Where it isn't, combine IW tuning with TLS certificate compression (RFC 8879) and aggressive session resumption for the best results. Brotli compression often achieves 50–70% reduction on PQC chains in practice.

Computation

Good news: ML-KEM and ML-DSA are faster than RSA for cryptographic operations:

• ML-KEM key exchange: ~40 microseconds (vs ~1ms for RSA key exchange)
• ML-DSA signature verification: ~100 microseconds — comparable to RSA-2048 verify (~50μs) and ECDSA P-256 verify (~100-200μs depending on implementation). In practice, PQC verification is competitive with both classical schemes.
• ML-DSA signing: ~200 microseconds (vs ~2ms for RSA-2048 signing, ~100μs for ECDSA P-256). Server-side signing gets faster, not slower.

The computational overhead of PQC is neutral to positive. The bottleneck is bandwidth and packet size, not CPU. This is a welcome inversion from previous cryptographic transitions where new algorithms were typically slower.

Hybrid Certificates: The Transition Period

During the PQC transition (expected 2027-2032+), most organisations will deploy hybrid certificates that contain both classical and quantum-resistant algorithms. This ensures:

• Backward compatibility: Clients that don't support PQC can still connect using classical algorithms
• Forward security: Clients that support PQC get quantum-resistant protection
• Compliance: Federal mandates accept hybrid mode during the transition period

Hybrid certificate structure

A hybrid certificate contains two public keys and two signatures. The X.509 certificate includes the primary algorithm (e.g. RSA-2048) in the standard fields, plus the PQC algorithm (e.g. ML-DSA-65) in extensions:

• Primary: RSA-2048 or ECDSA P-256 (backward-compatible)
• Alternative: ML-DSA-65 (quantum-resistant)
• Cert size: Roughly double a pure classical certificate (~7-8KB per cert, ~20KB for chain)

Hybrid mode is temporary. Once the ecosystem fully supports PQC, certificates will contain only quantum-resistant algorithms, and sizes will stabilise at the pure PQC figures above.

Practical Mitigation Strategies

1. TLS certificate compression (RFC 8879)

Certificate compression can reduce the on-wire size of PQC certificate chains by 40-60%. Both client and server must support it, but adoption is growing. Modern browsers and web servers (nginx, Apache, Caddy) support or are adding support for certificate compression.

2. Verify and increase TCP initial congestion window

RFC 6928 standardised IW10, but many production servers, CDNs, and cloud load balancers already run IW20 or higher. Verify your current setting first—you may already be covered. If not, raising from IW10 to IW20 accommodates ~29KB of server response in the first flight, keeping PQC handshakes within 1-RTT:

# Linux: check current initial congestion window
ip route show default | grep initcwnd

# Linux: increase initial congestion window
ip route change default via $GATEWAY initcwnd 20

3. Aggressive session resumption

TLS session tickets and 0-RTT resumption bypass the full handshake for returning connections. This is already best practice but becomes critical with PQC: the expensive handshake happens once, and subsequent connections reuse the session.

4. Certificate chain optimisation

• Minimise chain length: Two levels (root + leaf) instead of three where possible
• Use ECDSA/ML-DSA for intermediates: Avoid RSA intermediates in hybrid chains (they add the most size)
• OCSP stapling: Include OCSP response in the handshake instead of requiring a separate lookup; reduces total round trips

5. Encrypted Client Hello (ECH)

Encrypted Client Hello (ECH, formerly ESNI) encrypts the ClientHello extensions inside an outer wrapper. In a hybrid PQC world, the ClientHello grows because clients advertise both classical and ML-KEM key shares. ECH wraps this larger payload inside the encrypted envelope, preventing middleboxes from choking on unexpected extension sizes. While ECH is primarily a privacy feature (hiding the SNI), it also provides a cleaner path for deploying hybrid key exchanges without triggering compatibility issues with network middleboxes that inspect ClientHello.

ECH is supported by Cloudflare and Firefox in production as of 2025, with Chrome rollout in progress. If your infrastructure uses a CDN that supports ECH, enabling it eases the hybrid ClientHello transition.

6. CDN and edge configuration

If you use a CDN (Cloudflare, Akamai, AWS CloudFront, Fastly), the CDN terminates TLS and the certificate size increase affects the CDN-to-client connection. Work with your CDN provider on:

• PQC certificate support timeline
• Hybrid mode configuration options
• Certificate compression enablement
• ECH support for hybrid key exchange compatibility
• Connection pooling and session resumption policies

Impact by Use Case

Public websites

Impact: Low to moderate. Users connect infrequently (session resumption covers repeat visits). The extra 50-200ms on first connection is unlikely to be noticed by humans. CDNs will handle the transition transparently for most sites.

APIs and microservices

Impact: Moderate. Service-to-service communication involves many TLS handshakes. Connection pooling and long-lived connections mitigate most impact. Services with very high connection churn (serverless functions, short-lived containers) will see measurable overhead.

Key mitigations for APIs:

• 0-RTT resumption (TLS 1.3 early data): For idempotent API calls between known services, 0-RTT eliminates the handshake entirely on resumed connections. This is the single most effective optimization for high-frequency service-to-service traffic—the large PQC handshake happens once, then 0-RTT takes over.
• Post-handshake client authentication: In mutual TLS (mTLS) scenarios, post-handshake client auth sends the client's PQC certificate after the handshake completes, spreading the bandwidth cost across multiple packets rather than cramming everything into the initial flight. This avoids the worst-case scenario where both server and client PQC certificates must fit in the initial exchange.
• Connection pooling: HTTP/2 and gRPC multiplexing over persistent connections amortises the PQC handshake cost across thousands of requests.

Mobile applications

Impact: Moderate to high. Mobile networks have higher latency (100-300ms RTT) and constrained bandwidth. The extra round trip for PQC handshakes is most noticeable here. Certificate compression and aggressive session pinning are essential.

IoT and embedded devices

Impact: High. Constrained devices with limited memory, bandwidth, and processing power. Some devices may not have sufficient resources for ML-DSA-65 certificate validation. Firmware updates will almost certainly be required.

Options for constrained environments:

• ML-DSA-44 (NIST Level 2): Smaller parameter set with 1,312-byte public keys and 2,420-byte signatures—roughly 35% smaller than ML-DSA-65. Suitable for devices where NIST Level 3 security is not mandated.
• Composite certificates: IETF is actively working on composite certificate formats (as of 2026 drafts) that combine classical and PQC algorithms more efficiently than current hybrid approaches. For IoT, composite certs using ECDSA + ML-DSA-44 may offer a practical size/security trade-off.
• Server-only PQC: Some constrained devices may only validate server certificates (not present their own). In this model the device needs ML-DSA verification support but not signing, reducing firmware requirements.

Plan for longer transition timelines for IoT fleets. Devices with 10-15 year operational lifetimes that are being deployed today should already support PQC in firmware—or have a credible over-the-air update path.

The Automation Imperative

Larger certificates combined with shorter lifetimes (200 days from March 2026, 100 days from March 2027) means your certificate infrastructure handles more data more frequently. Manual certificate management—already unsustainable—becomes completely impossible.

Certificate automation via ACME and similar protocols becomes mandatory infrastructure, not a nice-to-have. If your organisation still manages certificates via spreadsheets, tickets, or manual renewal processes, the PQC transition will force a complete operational transformation—and the sooner you start, the less disruptive it will be.

On the Horizon: Smaller Signatures and Composite Standards

The PQC landscape is still evolving. Two developments are worth tracking:

FN-DSA (Falcon) — FIPS 206, expected 2025-2026

NIST is finalising a fourth standard: FN-DSA (based on the Falcon algorithm), a lattice-based signature scheme using NTRU lattices. FN-DSA's key advantage is significantly smaller signatures: ~666 bytes at NIST Level 1 and ~1,280 bytes at Level 5—roughly 3-5x smaller than ML-DSA. This makes it potentially more attractive for TLS certificates, where signature size directly impacts handshake performance.

The trade-off: FN-DSA signing requires careful constant-time floating-point arithmetic, making it harder to implement safely on constrained hardware. It's not a drop-in replacement, but for server-side certificates where signing happens on capable hardware, FN-DSA could meaningfully reduce PQC's TLS overhead once standardised and widely supported.

IETF composite certificates (2026 drafts)

The IETF is developing standards for composite certificates that combine classical and PQC algorithms in a single certificate more efficiently than current hybrid X.509 extensions. Key drafts include draft-ounsworth-pq-composite-sigs and draft-ounsworth-pq-composite-kem. Composite certs aim to:

• Reduce overhead compared to carrying two full certificate chains
• Provide a standardised (not vendor-specific) hybrid format
• Enable fine-grained algorithm negotiation between peers

These standards are in active development as of early 2026. They won't change the fundamental size increases from PQC algorithms, but they'll make the transition period (hybrid mode) more efficient and interoperable.

Where to Go Next

References

1. National Institute of Standards and Technology (NIST). (2024). FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM).
2. NIST. (2024). FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA).
3. NIST. (2024). FIPS 205: Stateless Hash-Based Digital Signature Standard (SLH-DSA).
4. NIST. (2025). FIPS 206 (Draft): FN-DSA — FFT over NTRU-Lattice-Based Digital Signature Algorithm.
5. Rescorla, E. (2018). RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. IETF.
6. Chu, J. et al. (2013). RFC 6928: Increasing TCP's Initial Window. IETF.
7. Ghedini, A. & Vasiliev, V. (2020). RFC 8879: TLS Certificate Compression. IETF.
8. Stebila, D. et al. (2024). Hybrid Key Exchange in TLS 1.3. IETF Internet-Draft.
9. Ounsworth, M. et al. (2026). Composite ML-DSA for Use in X.509 PKI and CMS. IETF Internet-Draft.
10. Paquin, C. et al. (2023). Benchmarking Post-Quantum Cryptography in TLS. NIST PQC Conference.