Post-Quantum Cryptography and SSL Certificates: What Changes and When

Post-quantum SSL means protecting TLS connections against future quantum computers. As of October 2026, the first part is already live: major browsers use a hybrid post-quantum key exchange with many servers. Certificates are the second part and are still in development. You do not need a new certificate today, but you do need a setup that can switch algorithms quickly.

Key fact (as of October 2026)	Status
Post-quantum standards	NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) in August 2024
Key exchange in browsers	Chrome uses hybrid X25519 + ML-KEM key exchange by default since Chrome 131 (November 2024)
Server software	OpenSSL 3.5 (2025) added ML-KEM, ML-DSA and SLH-DSA
Post-quantum certificates	Not yet in browser trust stores; Google targets a quantum-resistant Chrome root store for 2027
Phase-out of RSA/ECC	Draft NIST guidance (IR 8547) proposes deprecation by 2030 and disallowance by 2035

Will quantum computers break SSL?

A large enough quantum computer could break the RSA and elliptic-curve (ECC) math that SSL/TLS uses today. Nobody knows when such a machine will exist. Published estimates vary widely, and no public system can do it as of October 2026.

The risk is not the same for every part of a TLS connection. Shor’s algorithm, a quantum method for factoring and discrete logarithms, threatens the public-key parts. Symmetric ciphers such as AES are far less affected.

Part of TLS	Used for	Quantum risk	Fix
Key exchange (ECDHE)	Agreeing on session keys	High – traffic recorded today could be decrypted later	Hybrid ML-KEM key exchange (available now)
Certificate signatures (RSA, ECDSA)	Proving the server’s identity	Forgery once a quantum computer exists – not retroactive	Post-quantum certificates (in development)
Bulk encryption (AES, ChaCha20)	Encrypting the data stream	Low with 256-bit keys	No change needed

The key exchange gets fixed first because of “harvest now, decrypt later”: an attacker can record encrypted traffic today and decrypt it once quantum hardware arrives. A forged signature, by contrast, only matters at the moment someone uses it. For today’s real-world limits of SSL, see how secure SSL is.

Post quantum SSL today: key exchange vs certificates

Do I need a post-quantum certificate now?

No. As of October 2026, browsers do not accept post-quantum certificates for public websites, and the protection available today comes from the key exchange, not the certificate. Your current RSA or ECDSA certificate works with hybrid post-quantum key exchange.

Hybrid key exchange combines a classic algorithm (X25519) with ML-KEM. The connection stays secure as long as either one holds. Your server software negotiates it with the browser during the TLS 1.3 handshake. The certificate does not change. For protocol details, see TLS 1.2 vs TLS 1.3.

Why certificates take longer

Post-quantum signatures are much larger than today’s ECDSA signatures. A TLS handshake carries several signatures and certificates, so simply swapping algorithms would slow down every connection.

In February 2026, Google described its path for Chrome: Merkle Tree Certificates (MTCs), where a CA signs one tree head that covers many certificates, and the browser checks a small inclusion proof. Google targets a separate Chrome quantum-resistant root store, alongside the existing one, in 2027. Other browsers and the CA/Browser Forum have not set final rules yet.

What happens to the certificates you already have

Nothing changes for them. A certificate you install today stays valid until it expires and works with hybrid key exchange from day one. Public certificate lifetimes are getting shorter, so every certificate issued now will expire long before the 2030 and 2035 dates in NIST’s draft guidance. When browsers start trusting post-quantum certificates, you move to them at a routine renewal or reissue, not through an emergency replacement.

Tip: Be cautious with any “quantum-safe SSL certificate” offered for public websites today. Until browsers trust post-quantum certificates, such a product cannot change what visitors’ browsers accept.

What should businesses do today?

Inventory your certificates and keys, automate renewals, and keep your TLS software current. These steps pay off now and make the post-quantum switch a configuration change rather than a project.

1. Build an inventory. List every certificate, where it is installed, its algorithm and who owns it.
2. Automate renewal. Under CA/Browser Forum ballot SC-081, the maximum public certificate lifetime drops to 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. See certificate lifetimes for details.
3. Update TLS stacks. Enable TLS 1.3 and plan upgrades to library versions with ML-KEM support.
4. Find long-lived secrets. Data that must stay confidential for many years benefits most from hybrid key exchange now.
5. Ask your vendors. Load balancers, CDNs and appliances terminate TLS too. Ask for their post-quantum timelines.

Inventory and automation are the core of SSL certificate management. If you already use ACME, the protocol behind automated certificate renewal, you can also use ACME with a paid certificate.