The Future of Encryption: Post-Quantum TLS and What Comes Next

What's already happened

In August 2024, NIST finalized the first three post-quantum cryptography standards after roughly eight years of public evaluation:

• FIPS 203 — ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, based on the CRYSTALS-Kyber submission): the key-exchange algorithm relevant to TLS handshakes.
• FIPS 204 — ML-DSA (Module-Lattice-Based Digital Signature Algorithm, based on CRYSTALS-Dilithium): a signature scheme, relevant to certificates.
• FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, based on SPHINCS+): a backup signature scheme built on different (hash-based) math, in case lattice-based cryptography is ever found to have a weakness.

Of these, ML-KEM is the one that's already visible in ordinary web traffic. Chrome has defaulted to a hybrid key exchange — X25519 combined with ML-KEM (formerly Kyber) — since 2024, and Cloudflare's edge network supports the same hybrid negotiation. "Hybrid" is the key word: the connection runs classical elliptic-curve key exchange and post-quantum key exchange side by side, so it's no less safe than TLS is today even if the post-quantum half turns out to have an undiscovered flaw. Our State of HTTPS page tracks the current adoption share of hybrid key exchange across measured TLS 1.3 handshakes.

Certificate authorities and cloud providers are also further along than most site operators realize. AWS added ML-KEM support to KMS, Certificate Manager, and Secrets Manager in 2026 — see our news coverage of AWS's ML-KEM rollout — and several other major CDNs and cloud platforms have equivalent hybrid support either shipped or on a published roadmap. None of this requires certificate holders to do anything differently yet; it happens at the TLS negotiation layer, transparently, the same way TLS 1.3's improvements did.

Why any of this matters before quantum computers exist

The usual objection is reasonable: if a quantum computer capable of breaking today's encryption doesn't exist yet, why change anything now? The answer is a threat model called "harvest now, decrypt later." An adversary who can record encrypted traffic today can simply store it and wait — decrypting it retroactively once (or if) the right quantum hardware exists. For traffic that needs to stay confidential for years or decades — medical records, government communications, some financial and legal data — that risk is live today, not in the future, because the recording happens today. We cover this same principle from the classical side in our article on perfect forward secrecy: forward secrecy protects each session's key from a compromise of the server's long-term key, but it does nothing against an adversary who breaks the key-exchange math itself. Post-quantum key exchange is the response to that second, different threat.

What we actually know about quantum computing timelines

This is where we're careful to separate fact from forecast. As of this writing, no publicly known quantum computer can run Shor's algorithm at a scale that threatens RSA-2048 or 256-bit elliptic-curve keys — doing so is estimated to require millions of physical qubits with error correction, several orders of magnitude beyond current hardware. Estimates for when a "cryptographically relevant quantum computer" (CRQC) might exist vary widely across credible sources, from the early 2030s in some vendor roadmaps to considerably later in more conservative government assessments, and some researchers question whether current architectures scale that far at all. We're not going to pick a number here and present it as a fact — anyone who states a confident single year for this is going beyond what the current public evidence supports.

What standards bodies have done instead is act on the harvest-now-decrypt-later risk rather than wait for certainty. NIST, the NSA's CNSA 2.0 guidance, and equivalent bodies elsewhere have all published migration timelines targeting the early-to-mid 2030s for retiring classical-only algorithms in sensitive systems — that's a policy decision made under uncertainty, not a claim about exactly when quantum computers will arrive.

Where we're speculating: what this could mean going forward

Everything below this point is our own reasoning about likely second-order effects, offered because it's a question people ask us, not because we can verify it against a primary source the way the sections above can be verified. Treat it as informed discussion, not guidance to act on today.

Websites and TLS infrastructure

We'd expect hybrid key exchange to become the default everywhere over the next few years the same way TLS 1.3 did — quietly, at the server-software and CDN level, without most site operators changing a configuration line. The more interesting long-term question is certificate size: ML-DSA signatures and public keys are meaningfully larger than today's ECDSA equivalents, which pushes up TLS handshake size. For most web traffic that's a rounding error, but it could matter more for constrained connections — satellite links, some mobile networks, embedded devices with small buffers — in ways that may push some ecosystems toward SLH-DSA's more compact use cases or toward more aggressive certificate compression (TLS already has an extension for this).

Web apps

We'd expect the practical impact on typical web-app development to be small and mostly invisible — this is a transport-layer and certificate-layer change, not something most application code touches directly. Where we think it's more likely to surface is in anything that pins a specific key exchange or signature algorithm, hardcodes cipher suite lists, or embeds long-lived cryptographic assumptions (some legacy enterprise SSO and document-signing integrations do this). Those integrations are the ones we'd expect to need actual code changes, not a typical REST API or SPA.

Mobile apps

Mobile is where we think the transition could be slower and messier than on the web, for a structural reason rather than a cryptographic one: browsers update every few weeks, but mobile operating systems and the TLS libraries bundled inside individual apps update far less often, and older devices stop receiving OS updates entirely well before users stop using them. We already see this lag with ordinary TLS version and cipher deprecations — see our related coverage in mobile browser certificate trust and certificate pinning. We'd expect apps that pin specific certificates or public keys to need the most deliberate attention during any future post-quantum transition, since a pin built around an assumption that no longer holds is exactly the kind of thing that causes an app to lock users out rather than fail safely.

Quantum computers and encryption, generally

It's worth separating two different things people often collapse into one worry. Symmetric encryption (AES) and hashing (SHA-2/SHA-3) are only modestly weakened by the best currently known quantum algorithms (Grover's algorithm), and the fix is small — doubling key length restores the original security margin, and this is already accounted for in modern recommendations (AES-256 rather than AES-128 for long-term-sensitive data). The at-risk category is specifically public-key cryptography used for key exchange and signatures — RSA, Diffie-Hellman, and elliptic-curve cryptography — because Shor's algorithm solves the specific math problems those rely on efficiently on a sufficiently large quantum computer. Post-quantum cryptography is a replacement for that second category, not a general "quantum-proofing" of encryption as a whole.

What site operators can reasonably do today

None of this calls for urgency, and we'd caution against vendors who suggest otherwise as a sales tactic. Concretely:

• Keep TLS libraries and web server software current — hybrid post-quantum support arrives through routine updates (OpenSSL 3.2+ and recent versions of Nginx, Apache, and every major CDN already support or are adding it), not a special migration project.
• If you operate infrastructure that needs to protect data for a decade or more, it's reasonable to ask your CA and cloud provider what their post-quantum roadmap looks like now, even if you take no action yet.
• Watch the CA/Browser Forum and NIST's own announcements rather than any single vendor's marketing — see our Useful Links page for both.
• Avoid hardcoding specific cipher suites or key-exchange algorithms in configuration if you can instead defer to your software's maintained default list — that default is exactly what's being updated for you.

This page combines verified current standards status with our own clearly-labeled analysis, per our Editorial Standards. Corrections and updates to the factual sections are logged on our Corrections page.