📅 Published 7 May 2026

The "harvest now, decrypt later" threat has been the primary motivator for post-quantum cryptography adoption, and in 2026 the migration is no longer theoretical. NIST has published final standards for post-quantum key encapsulation (ML-KEM, formerly CRYSTALS-Kyber) and digital signatures (ML-DSA, formerly CRYSTALS-Dilithium; SLH-DSA, formerly SPHINCS+). Chrome, Firefox, and major TLS libraries have shipped hybrid key exchange that combines classical and post-quantum algorithms. Cloudflare, Amazon, and Google have enabled post-quantum TLS for their services. The migration has begun — not as a response to the existence of a cryptographically relevant quantum computer (which does not yet exist) but as preparation for one that might exist within the lifetime of data being encrypted today.

This page covers the practical state of post-quantum cryptography in 2026: what has been standardised, what is deployed, what web developers and system administrators need to do, and what can safely wait. The page is part of the security section and connects to the privacy and security topic hub.

The threat model​

Classical public-key cryptography (RSA, ECDSA, ECDH) relies on mathematical problems that are computationally hard for classical computers but solvable by a sufficiently powerful quantum computer running Shor's algorithm. Symmetric cryptography (AES) and hash functions (SHA-256) are less affected — Grover's algorithm provides a quadratic speedup, which means AES-256 provides roughly AES-128 equivalent security against a quantum adversary, which remains sufficient.

The threat is not immediate. No cryptographically relevant quantum computer exists in 2026, and credible estimates for when one might exist range from "possibly within 10 years" to "possibly never at scale." The urgency comes from the "harvest now, decrypt later" scenario: an adversary who records encrypted traffic today can decrypt it later when a quantum computer becomes available. For data with a long confidentiality requirement (government communications, medical records, trade secrets, personal data under GDPR's indefinite obligations), this threat justifies action now.

For most web applications, the practical risk is low. The encrypted shopping session from today is unlikely to be valuable to a quantum adversary in 2035. But the cryptographic infrastructure is migrating anyway because the cost of migration is lower now than it will be later, and the major platforms are driving adoption.

What has been standardised​

NIST published three post-quantum cryptographic standards in 2024:

ML-KEM (FIPS 203) — Module-Lattice-Based Key-Encapsulation Mechanism. Formerly known as CRYSTALS-Kyber. Used for key exchange (establishing shared secrets). This is the algorithm that matters most for TLS and web traffic encryption.

ML-DSA (FIPS 204) — Module-Lattice-Based Digital Signature Algorithm. Formerly known as CRYSTALS-Dilithium. Used for digital signatures (authentication, code signing, certificates).

SLH-DSA (FIPS 205) — Stateless Hash-Based Digital Signature Algorithm. Formerly known as SPHINCS+. A hash-based signature scheme that does not rely on lattice assumptions, providing cryptographic diversity in case lattice-based schemes are broken.

All three are based on well-studied mathematical problems. ML-KEM and ML-DSA use structured lattices; SLH-DSA uses hash functions. The security analysis is ongoing but no practical attacks have emerged.

What is deployed in 2026​

TLS hybrid key exchange​

Chrome and Firefox have enabled hybrid key exchange by default. The TLS handshake uses X25519Kyber768Draft00 (now transitioning to the final X25519MLKEM768 identifier) — a hybrid that combines classical X25519 ECDH with ML-KEM-768. The hybrid approach means the connection is at least as secure as the classical algorithm, even if the post-quantum algorithm is later found to be weak.

The practical impact on web developers: nothing needs to change in your application code. TLS library updates handle the hybrid key exchange transparently. The TLS handshake is slightly larger (ML-KEM-768 adds approximately 1 kilobyte to the handshake), which is negligible for most connections but can matter for very latency-sensitive applications or environments with extreme bandwidth constraints.

The TLS security landscape builds on the same infrastructure that the Let's Encrypt experiences and TLS ratings analysis on this site have documented — the certificate and key exchange systems are evolving but the deployment patterns are recognisable.

Certificate infrastructure​

Post-quantum certificates are not yet widely deployed. The X.509 certificate infrastructure (CAs, browser trust stores, certificate transparency logs) is preparing for post-quantum signatures but the migration is slower because:

1. ML-DSA signatures are larger than ECDSA signatures (~2.4 KB vs ~72 bytes for ML-DSA-65), increasing certificate chain size
2. Certificate chains with post-quantum signatures significantly increase TLS handshake size
3. Backward compatibility with older TLS clients must be maintained during the transition

Hybrid certificates (containing both classical and post-quantum signatures) are the expected transition mechanism, but the X.509 format changes are still being finalised.

What web developers should do now​

Immediate (low effort, no risk)​

1. Update TLS libraries. Ensure your TLS termination (web server, load balancer, CDN) uses a recent version that supports hybrid key exchange. If you use Cloudflare, AWS, or Google Cloud for TLS termination, this is already handled.

2. Verify hybrid key exchange is working. In Chrome DevTools, the Security tab shows the key exchange algorithm. Look for X25519Kyber768 or X25519MLKEM768. The Cloudflare Workers processing this site's requests, for example, negotiate post-quantum key exchange with supporting clients automatically.

3. Inventory your cryptographic dependencies. Identify where your applications use public-key cryptography beyond TLS: JWT signing, webhook verification, encrypted data at rest, API authentication tokens. These will eventually need migration.

Medium-term (plan but do not rush)​

4. Plan for larger TLS handshakes. If your application is sensitive to connection establishment latency (real-time applications, IoT, mobile in poor network conditions), test with post-quantum key exchange enabled and measure the impact.

5. Monitor post-quantum certificate deployment. When CAs begin issuing post-quantum certificates, evaluate the impact on your certificate chain size and TLS handshake performance.

6. Evaluate long-term data encryption. For data encrypted at rest with public-key cryptography that must remain confidential for 10+ years, consider migrating to hybrid encryption (classical + post-quantum) now.

What can wait​

7. Application-level signature migration. Moving JWT, webhook signatures, and API authentication to post-quantum algorithms can wait until library support matures and performance characteristics are well-understood.

8. Post-quantum VPN and SSH. OpenSSH has experimental post-quantum key exchange. WireGuard and other VPN protocols are working on it. For most deployments, the urgency is low because VPN and SSH traffic is ephemeral.

The honest assessment​

Post-quantum cryptography migration in 2026 is a "prepare but do not panic" situation. The TLS ecosystem is handling the transition transparently for web developers. The most important action — updating TLS libraries and ensuring hybrid key exchange works — requires minimal effort. The application-level migration (signatures, encrypted data) is genuinely complex but is not urgent for most web applications.

The bigger risk for most web applications is not quantum computing — it is the mundane vulnerabilities that have always dominated: weak authentication, SQL injection, XSS, misconfigured access controls. The passkeys guide on this site addresses one of the highest-impact security improvements available today, and it has nothing to do with quantum computers.

Invest in post-quantum readiness proportionally to the confidentiality lifetime of your data. For a web application serving public content, the urgency is near zero. For a service handling financial or medical records, the urgency is moderate and growing.