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

Part of the Post-Quantum PKI Migration Guide

In one sentence: Post-quantum certificate chains are 3–5x larger than classical equivalents (individual signatures up to 13x), 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-22KB with quantum-safe certificates. Multiply by millions of connections per day.
• Latency increases on constrained networks. Larger certificates may not fit in a single TCP flight on servers using default congestion windows, adding a round trip 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 roughly 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:

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.

TLS 1.3 PQC Cipher Suites and Negotiation

TLS 1.3 doesn't require new cipher suites for PQC—the symmetric ciphers (AES-256-GCM, ChaCha20-Poly1305) are already quantum-resistant. What changes are the named groups (for key exchange) and signature algorithms (for certificate authentication), negotiated via ClientHello extensions.

Key exchange: named groups

Authentication: signature algorithms

What this means in practice: A PQC-ready ClientHello advertises X25519MLKEM768 in its supported_groups extension and ML-DSA-65 in its signature_algorithms extension. No changes to the TLS record layer, handshake state machine, or symmetric cipher negotiation are required. The server selects PQC algorithms if it supports them, or falls back to classical algorithms if it doesn't.

Current PQC TLS Support (March 2026)

PQC adoption in TLS is split into two tracks: key exchange (protecting session confidentiality, deployed now) and authentication (protecting certificate integrity, not yet in public web PKI).

Key exchange (ML-KEM): deployed in production

Authentication (ML-DSA certificates): not yet in public web PKI

Post-quantum certificate authentication is blocked by two dependencies: the CA/Browser Forum must update its Baseline Requirements to permit ML-DSA in publicly-trusted certificates, and IETF must finalise the OID and encoding standards for PQC in X.509. Both are expected in 2026-2027.

What you can do today: Private PKI (internal certificates) can use ML-DSA certificates now via DigiCert Private CA, AWS Private CA (GA since November 2025), and open-source tools like OpenSSL 3.5+ with OQS provider. This lets teams test PQC certificate compatibility against their infrastructure before public PKI support arrives.

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. Research presented at NIST's 5th PQC Standardization Conference (2024) confirmed that the extra round trip from large PQC chains is the dominant performance cost, but that it is amortised quickly once application data transfer begins.

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 (CNSA 2.0) 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.

QUIC and HTTP/3: Different Transport, Same PQC Challenge

QUIC (the transport protocol underlying HTTP/3) integrates TLS 1.3 directly into its handshake rather than layering TLS on top of TCP. The same PQC algorithms apply—ML-KEM for key exchange, ML-DSA for certificates—but the interaction with QUIC's transport mechanics creates different trade-offs:

• No TCP fragmentation concerns: QUIC's CRYPTO frames can span multiple QUIC packets natively. The large PQC certificate chain doesn't cause TCP-level fragmentation or interact with TCP's congestion window the same way. This is a structural advantage over TCP-based TLS for PQC.
• Amplification limit is the constraint: Before the client's address is validated, QUIC servers may only send 3x the data received from the client (anti-amplification measure). A PQC ClientHello with X25519MLKEM768 key share is ~1.3KB, allowing the server to send ~3.9KB before validation—well below the ~17KB needed for a full PQC certificate chain. This means the server must wait for the client to ACK and provide address validation before completing the handshake, potentially adding latency.
• 0-RTT resumption is native: QUIC's built-in 0-RTT support amortises the PQC handshake cost effectively for returning connections. The large initial handshake happens once; subsequent connections resume without it.
• Encrypted from the start: QUIC encrypts almost everything, including the handshake. PQC-sized handshakes don't expose larger plaintext payloads to network middleboxes, reducing the risk of middlebox interference that has been observed with large TLS handshakes over TCP.

Bottom line: QUIC handles PQC certificate sizes more gracefully than TCP-based TLS in most respects, but the amplification limit introduces a different latency constraint. For services already using HTTP/3, the PQC transition may be smoother than for TCP-only infrastructure.

Practical Mitigation Strategies

1. 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

2. TLS certificate compression (RFC 8879) — with caveats

Certificate compression can reduce the on-wire size of certificate chains, and both client and server support is growing. However, the effectiveness for PQC certificates is more limited than for classical certificates. Classical certs benefit from compressing repetitive ASN.1 structures, but PQC public keys (1,952 bytes for ML-DSA-65) and signatures (3,309 bytes) are high-entropy data that resists compression. The IETF's PQC recommendations for TLS (draft-ietf-uta-pqc-app, February 2026) notes that certificate compression's "impact on PQ or PQ/T hybrid certificates is limited due to the larger sizes of public keys and signatures."

In practice: Expect modest reduction from compressing the X.509 structural overhead, certificate metadata, and any repeated issuer fields—but don't plan capacity based on 50%+ compression ratios for PQC chains. The bulk of the size increase (keys and signatures) will not compress meaningfully.

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
• Cached Information extension (RFC 7924): Allows clients to indicate they've already cached the server's certificate chain. The server can skip retransmitting it, eliminating the PQC size penalty for repeat connections entirely. Trade-off: the cached certificate fingerprints in ClientHello create a privacy concern (session correlation)—acceptable for enterprise/API use, less so for public web.

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. Session resumption and aggressive connection reuse 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, 47 days by 2029) 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 late 2026 or early 2027

NIST is finalising a fourth standard: FN-DSA (based on the Falcon algorithm), a lattice-based signature scheme using NTRU lattices. The draft was submitted for review in August 2025. 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. Santesson, S. & Tschofenig, H. (2016). RFC 7924: TLS Cached Information Extension. IETF.
9. Stebila, D. et al. (2024). Hybrid Key Exchange in TLS 1.3. IETF Internet-Draft.
10. Ounsworth, M. et al. (2026). Composite ML-DSA for Use in X.509 PKI and CMS. IETF Internet-Draft.
11. Reddy, T. & Tschofenig, H. (2026). Post-Quantum Cryptography Recommendations for TLS-based Applications. IETF Internet-Draft (draft-ietf-uta-pqc-app-01).
12. Paquin, C. et al. (2023). Benchmarking Post-Quantum Cryptography in TLS. NIST PQC Conference.
13. NIST. (2024). The Impact of Data-Heavy Post-Quantum TLS 1.3 on the Time to Last Byte. 5th PQC Standardization Conference.