RSA vs ML-KEM: Post-Quantum Encryption Adds 30x Data [2026]

Every TLS handshake, every SSH login, and every signed software update on the internet today leans on math that a large enough quantum computer could break. That is not a hypothetical anymore. NIST finalized its first three post-quantum cryptography standards, FIPS 203, FIPS 204, and FIPS 205, on August 13, 2024, and cloud providers, browsers, and messaging apps have spent the past two years quietly swapping RSA and elliptic-curve key exchange for a new algorithm called ML-KEM. The question engineers are actually searching for in September 2026 is not whether to care about post-quantum cryptography. It is whether to switch now, what it costs in bandwidth and latency, and which parts of a stack need it first.

This comparison lines up classical public-key encryption (RSA-2048/4096 and ECC over P-256 or X25519) against ML-KEM, the NIST-standardized post-quantum key encapsulation mechanism derived from CRYSTALS-Kyber. We pull key sizes straight from FIPS 203, benchmark data from Cloudflare, Google Chrome’s engineering blog, and academic TLS studies, and real pricing from AWS and Google Cloud. No invented numbers, no guessed release dates. Where the public research does not yet answer a question cleanly, like exact Q-day timing, we say so instead of filling the gap with a made-up figure.

By the end of this piece you’ll have a full specs table, real benchmark numbers from three independent sources, actual cloud pricing, a step-by-step migration checklist, and a data-backed verdict on when to flip the switch. If you only need one number to start a conversation with your infrastructure team, it’s this: hybrid post-quantum key exchange costs about 4% in handshake latency and roughly 1-2KB of extra bandwidth per connection, measured in production by Cloudflare and Chrome. Everything else in this article explains where that number comes from and what to do with it.

Why Classical Encryption Suddenly Looks Fragile

RSA and elliptic-curve cryptography rely on two math problems that classical computers cannot solve efficiently: factoring large integers and computing discrete logarithms on an elliptic curve. Peter Shor’s 1994 algorithm proves that a fault-tolerant quantum computer with enough stable logical qubits could solve both in polynomial time, which would break RSA, Diffie-Hellman, and ECDSA outright. Nobody has built that machine yet. IBM, Google, and other labs have made real progress on qubit counts and error correction, but a cryptographically relevant quantum computer capable of factoring RSA-2048 has not been demonstrated as of this research.

The reason engineers are moving anyway is a threat model called harvest-now-decrypt-later. An adversary with the resources of a nation-state can record encrypted traffic today and sit on it until a quantum computer exists that can crack the key exchange, then decrypt years of stored data in one pass. For traffic that needs confidentiality for a decade or more, financial records, medical data, government communications, waiting for a confirmed quantum break is already too late. That is the actual driver behind quantum-resistant encryption adoption right now, not a countdown clock to a specific Q-day.

This is also why the framing of “RSA vs post-quantum encryption” as a single winner-take-all contest misses how the migration is actually unfolding. It isn’t a bake-off between two competing products. It’s a staged replacement of one specific building block, key exchange, while the rest of the security stack, firewalls, authentication, patching discipline, keeps running the way it always has. Getting quantum-resistant encryption into production doesn’t fix a weak password policy or an unpatched server, and teams that treat it as a silver bullet for their broader security posture are solving the wrong problem first.

Bitcoin’s ECDSA-secured wallets sit in a similar bind, and we cover that exposure separately in our look at the roughly 7 million BTC still sitting behind exposed public keys while BIP-360 remains just a proposal. The encryption side of the internet is moving faster than the signature side, and ML-KEM is the piece that’s already shipping in production.

What Changed: FIPS 203, 204, 205 and the ML-KEM Standard

NIST ran an eight-year public competition before landing on its post-quantum picks. On August 13, 2024, it published three final standards. FIPS 203 defines ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), the direct successor to CRYSTALS-Kyber, for key establishment. FIPS 204 defines ML-DSA (Module-Lattice-Based Digital Signature Algorithm), built on CRYSTALS-Dilithium. FIPS 205 defines SLH-DSA, a stateless hash-based signature scheme descended from SPHINCS+, meant as a structurally different backup in case lattice math ever turns out to have a weakness nobody has found yet.

ML-KEM is the one that matters for encryption comparisons, since RSA and ECC are also primarily used for key exchange in modern TLS rather than for encrypting bulk data directly. ML-KEM ships in three parameter sets, ML-KEM-512, ML-KEM-768, and ML-KEM-1024, roughly mapped to security levels comparable to AES-128, AES-192, and AES-256. ML-KEM-768 is the one showing up in almost every production deployment so far, since it lines up with the security level TLS 1.3 already assumes for X25519.

The math itself is different in kind from RSA and ECC. ML-KEM’s security rests on the Module Learning With Errors (MLWE) problem over polynomial lattices, a problem believed to resist both classical and quantum attacks. RSA’s security rests on integer factorization, and ECC’s rests on the elliptic-curve discrete logarithm problem. Both of the latter fall to Shor’s algorithm on a sufficiently capable quantum computer. Lattice problems, as far as current research shows, do not.

RSA/ECC vs ML-KEM: Full Specs Comparison

The most immediately visible difference between classical and quantum-resistant encryption is size. ML-KEM keys and ciphertexts run anywhere from 4x to 40x larger than their RSA or ECC equivalents, depending on which parameter set and which classical baseline you pick. Here is the full breakdown using the byte sizes standardized in FIPS 203 alongside typical RSA and ECC figures.

Algorithm	Type	Public key	Private key	Ciphertext / shared secret	Quantum-safe	Standard
RSA-2048	Classical (factoring)	256 bytes (modulus)	~1,192-1,216 bytes encoded	256 bytes	No	PKCS#1 / FIPS 186
RSA-4096	Classical (factoring)	512 bytes (modulus)	~2,400-2,500 bytes encoded	512 bytes	No	PKCS#1 / FIPS 186
ECC P-256 (ECDH)	Classical (elliptic curve)	65 bytes uncompressed / 33 compressed	32 bytes	32-byte shared secret	No	NIST SP 800-186
X25519	Classical (elliptic curve)	32 bytes	32 bytes	32-byte shared secret	No	RFC 7748
ML-KEM-512	Post-quantum (lattice)	800 bytes	1,632 bytes	768 bytes	Yes	FIPS 203
ML-KEM-768	Post-quantum (lattice)	1,184 bytes	2,400 bytes	1,088 bytes	Yes	FIPS 203
ML-KEM-1024	Post-quantum (lattice)	1,568 bytes	3,168 bytes	1,568 bytes	Yes	FIPS 203
Hybrid X25519+ML-KEM-768	Combined	~1,216 bytes	~2,432 bytes	~1,120 bytes	Yes (defense in depth)	Draft IETF / deployed by Cloudflare
Security basis	–	RSA: integer factorization. ECC/X25519: elliptic-curve discrete log. ML-KEM: Module Learning With Errors over lattices.
Broken by Shor’s algorithm	–	RSA and ECC: yes, in theory, on a fault-tolerant quantum computer. ML-KEM: no known quantum algorithm breaks it.
Typical use today	–	RSA/ECC: TLS key exchange, code signing, SSH. ML-KEM: hybrid TLS key exchange at Cloudflare, Signal’s PQXDH.

Two things stand out. First, ML-KEM ciphertexts and public keys are consistently the largest values in the table, which is the direct cause of the bandwidth overhead discussed later. Second, RSA private-key sizes are misleading if compared naively, since the encoded figure includes CRT parameters and ASN.1 structure rather than raw entropy. The raw security-relevant material in an RSA-2048 private key is much smaller than the on-disk PKCS#8 encoding suggests. For a parameter-size-focused comparison against other post-quantum key exchange candidates, our breakdown of ML-KEM against Classic McEliece covers how differently NIST’s backup KEM handles the same trade-off.

Digital Signatures Too: ML-DSA and SLH-DSA vs RSA/ECDSA

Encryption and signatures are separate problems, and treating them as one topic causes confusion. RSA and ECDSA sign a document by producing a compact value that anyone with the public key can verify. ML-DSA (FIPS 204) does the same job with signatures that run larger, typically in the 2.4KB to 4.6KB range depending on the security level, versus roughly 64-512 bytes for ECDSA or RSA signatures. SLH-DSA (FIPS 205) trades speed for structural diversity: its signatures run even larger, into the tens of kilobytes, because it is built entirely from hash functions rather than lattice math, giving it a different failure mode if lattice cryptography is ever broken.

This matters for the encryption-versus-post-quantum-encryption question because a real TLS handshake or code-signing pipeline usually needs both a key exchange and a signature scheme. Swapping only the key exchange to ML-KEM while leaving certificate signatures on RSA or ECDSA still leaves the authentication layer quantum-vulnerable, even if the confidentiality layer is protected. A quantum computer capable of forging an RSA or ECDSA signature could still impersonate a trusted server or push a malicious software update disguised as a legitimate one, regardless of how strong the underlying encryption is. Certificate authorities and public key infrastructure vendors are aware of this gap, but issuing ML-DSA certificates at internet scale involves a slower-moving chain of trust than swapping a TLS library’s key-exchange group, since it touches root certificates, intermediate CAs, and every client that needs to validate them. We’ve broken down the signature side in more depth in our SLH-DSA vs ML-DSA comparison, and for teams still deciding between classical signature schemes, the Ed25519 vs ECDSA breakdown covers the speed and nonce-safety trade-offs that matter before a post-quantum migration even starts.

Benchmark Data: How Much Overhead Post-Quantum Really Adds

Three independent sources give a consistent picture: post-quantum key exchange costs single-digit-percentage handshake latency and low-single-digit-kilobyte bandwidth, not the order-of-magnitude slowdown some early coverage implied.

• Cloudflare, “State of the post-quantum Internet in 2025”: deploying hybrid post-quantum key agreement produced roughly a 4% TLS handshake slowdown, with about 1.1KB of extra server-to-client data and 1.2KB of extra client-to-server data.
• Google Chrome/Chromium engineering blog: a Kyber key exchange transmits around 1KB per peer versus 32 bytes for X25519, more than 30 times larger. That extra data forces the TLS ClientHello to split into two network packets, and Chrome measured a 4% median latency increase across all desktop TLS handshakes after enabling it by default.
• Academic TLS handshake study (2026): median handshake latency ran 5.547ms for plain X25519, 5.879ms for X25519 plus ML-KEM-512, and 6.495ms for X25519 plus ML-KEM-768, an increase of roughly 17.1% for the higher security level relative to classical-only X25519.

Those numbers converge on the same conclusion from three different angles: production CDN traffic (Cloudflare), a major browser’s own telemetry (Chrome), and controlled academic measurement. The overhead is real but small, and it shows up mostly as extra bytes on the wire rather than extra CPU time, since ML-KEM’s actual encapsulation and decapsulation operations run fast on modern hardware. Cloudflare separately reported that avoiding an extra TLS round trip (a HelloRetryRequest, triggered when a server does not support the client’s preferred key-exchange group) cut p90 connection latency by more than 150 milliseconds in its scanned origin traffic, and that 99.2% of post-quantum-capable TLS 1.3 connections completed in a single round trip once servers advertised support correctly. That is a bigger lever than the raw ML-KEM computation cost.

One caveat worth flagging directly: none of these sources publish a single head-to-head CPU-cycle benchmark covering RSA-2048, X25519, and ML-KEM-768 in one controlled run using the same hardware and library version. The Open Quantum Safe project’s liboqs library supports benchmarking all three parameter sets of ML-KEM, but a specific, citable cycle-count table for that exact three-way comparison was not available in this research. Treat any number you see claiming ML-KEM is “10x faster” or “100x slower” than RSA with real skepticism unless it names the CPU, compiler, and library version.

Real-World Deployments Already Running ML-KEM

Post-quantum encryption stopped being theoretical well before the FIPS standards were even finalized. Vendors started shipping pre-standard hybrid schemes years ahead of NIST’s final publication, betting correctly that the underlying Kyber algorithm would survive standardization mostly intact. That bet paid off: the transition from draft naming to final FIPS 203 naming has been a rename and a parameter check for most deployments, not a redesign. Here are the confirmed, dated production rollouts.

• Cloudflare, September 29, 2023: announced hybrid post-quantum key agreement using X25519Kyber768Draft00 for connections to origin servers, rolling out first to free-tier traffic and reaching 100% of Enterprise traffic by March 2024, according to Cloudflare’s own announcement.
• Signal, September 19, 2023: shipped PQXDH, a protocol combining X25519 with CRYSTALS-Kyber for its Signal Protocol, protecting new conversations initiated after both participants updated their clients, per Signal’s technical announcement.
• Google Chrome, 2023-2024: enabled a hybrid post-quantum key-exchange group by default for a large share of desktop TLS connections, documented in the Chromium engineering blog, which also supplied the bandwidth figures above.
• Cloudflare, September 24, 2025: migrated from the draft Kyber hybrid to the standardized hybrid X25519 plus ML-KEM for TLS 1.3 traffic to its own servers and internal systems, moving from pre-standard to FIPS 203-aligned cryptography.
• Cloudflare DNSSEC: separately rolled post-quantum protection into DNS infrastructure. We covered the signature-size impact of that move in our DNSSEC post-quantum deep dive, where signature counts jumped roughly 38x under the new scheme.
• Open Quantum Safe project: maintains liboqs, the open-source library most vendors use to prototype ML-KEM support before shipping it, and it remains the reference implementation cited across nearly every deployment announcement above.

Notice what is missing from that list: no verified, dated, primary-source announcement for AWS KMS, Azure, Apple iMessage, or OpenSSH shipping ML-KEM by default in production, at least not one that turned up in this research with a specific date attached. That does not mean those platforms have done nothing. AWS’s s2n-tls library has carried experimental post-quantum support in various forms for years, and Apple’s iMessage PQ3 protocol has been publicly discussed since 2024. But a comparison article should not manufacture a launch date where the primary source does not clearly provide one, so we are naming the gap instead of guessing.

Migration Guide: Moving From Classical to Post-Quantum Encryption

Nobody rips out RSA and ECC in a weekend. Every deployment listed above ran a hybrid scheme first, combining classical and post-quantum algorithms so a break in either one alone does not compromise the connection. Here is the practical order of operations engineering teams are actually following.

1. Inventory your cryptography. Find every place RSA, ECDH, or ECDSA gets used: TLS termination points, VPN concentrators, code-signing pipelines, internal service-to-service auth, and anything writing long-lived encrypted data to disk.
2. Prioritize by data lifetime, not by convenience. Data that needs to stay confidential for 10+ years (health records, government files, trade secrets) is the harvest-now-decrypt-later target. Migrate its transport encryption first.
3. Update your TLS library. OpenSSL 3.2+, BoringSSL, and s2n-tls all carry some level of ML-KEM support. Confirm your version and check whether hybrid groups like X25519MLKEM768 are compiled in.
4. Enable hybrid mode, not pure post-quantum. Every production deployment covered above runs classical-plus-ML-KEM together. Pure ML-KEM-only deployments remain rare because it removes the decades of cryptanalysis backing RSA and ECC as a fallback.
5. Test for TLS middlebox breakage. The larger ClientHello from ML-KEM’s bigger public keys has been known to break older load balancers, firewalls, and proxies that assume a single-packet handshake. This is the single most common migration failure mode reported by early adopters.
6. Budget for the bandwidth, not the CPU. Based on the benchmark data above, plan for roughly 1-2KB of extra handshake traffic per connection and a low-single-digit percentage latency increase, not a compute capacity upgrade.
7. Handle signatures separately from key exchange. Migrating TLS key exchange to ML-KEM does not touch your certificate chain. Plan a distinct project for ML-DSA or SLH-DSA certificate issuance once your CA supports it.
8. Track compliance deadlines if you sell to government. US federal and defense contractors should watch the NSA’s CNSA 2.0 timeline, which per its draft CSfC guidance addendum calls for updated NIAP Protection Profiles covering CNSA 2.0 algorithms in 2026 and requires CNSA 2.0 support in new products and services starting January 1, 2027, absent a waiver.
9. Re-test performance under real load. Lab benchmarks understate the effect of larger packets on lossy or high-latency networks, where the extra kilobyte matters more than it does on a clean data-center link.

A quick OpenSSL 3.2+ command to check what hybrid groups your build actually supports before you plan anything:

openssl list -kem-algorithms
openssl s_client -groups X25519MLKEM768 -connect example.com:443

Configuring Hybrid Post-Quantum TLS in Practice

Most of the friction in a real migration is configuration, not code. If you’re running a modern web server or reverse proxy, enabling hybrid ML-KEM support is usually a one-line change rather than a rebuild, provided the underlying TLS library was compiled with post-quantum group support in the first place. Nginx built against OpenSSL 3.2 or newer, for example, picks up new key-exchange groups through the same directive that already lists X25519 and the P-curves.

# nginx.conf, inside an ssl-enabled server block
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;
ssl_protocols TLSv1.3;

Listing X25519MLKEM768 first tells clients that support it to negotiate the hybrid group, while clients on older browsers or libraries fall back to plain X25519 automatically. Nothing breaks for a client that has never heard of ML-KEM. That backward-compatible negotiation is exactly why Cloudflare and Chrome could roll this out gradually instead of coordinating a flag day across the entire internet.

Verifying that a server is actually offering the hybrid group is worth doing before declaring the migration finished, since a misconfigured proxy in front of your TLS terminator can silently strip the option. Checking via curl against a build linked to a post-quantum-aware OpenSSL confirms what group actually gets negotiated.

curl -v --curves X25519MLKEM768 https://your-domain.example
# Look for "SSL connection using TLSv1.3" and the negotiated group
# in the verbose handshake output

On the client side, language runtimes are catching up at different speeds. Go’s crypto/tls package added X25519MLKEM768 support as a default candidate in recent releases, and Rust’s rustls has carried experimental post-quantum groups behind a feature flag. Python’s cryptography library depends on the underlying OpenSSL build it links against, so upgrading the system OpenSSL package often does more than upgrading the Python package itself. None of this requires touching application-layer code that calls into the TLS library. The negotiation happens below the layer where most developers ever look, which is a large part of why the migration has moved as fast as it has without breaking application compatibility across the board.

Pricing: What Post-Quantum Encryption Actually Costs

Here is the part that surprises a lot of engineers: none of the major cloud key management providers charge extra for post-quantum algorithms. The cost of ML-KEM shows up as bandwidth and, in constrained environments, storage for larger keys, not as a separate line item on a cloud bill.

Service	Pricing (verified, standard tier)	Post-quantum surcharge
AWS KMS (per key)	$1.00 per key per month, prorated hourly	None identified
AWS KMS (API requests)	$0.03 per 10,000 requests (symmetric and RSA-2048 operations)	None identified
AWS CloudHSM	$1.60 per HSM-hour, no upfront fee	None identified
Google Cloud KMS (software key)	$0.06 per active key version per month	None identified
Google Cloud KMS (operations)	$0.03 per 10,000 key-use operations	None identified
Google Cloud HSM (key version)	$1.00/month (AES-256/RSA-2048); $2.50/month for the first 2,000 RSA-3072/4096 or EC key versions	None identified
Google Cloud HSM (dedicated instance)	Approximately $4.79 per instance-hour, single tenant	None identified

None of AWS, Google Cloud, or the broader research surfaced a published Azure Key Vault HSM-backed pricing figure specific enough to cite here, so we’ve left it out rather than estimate. The pattern that does hold across every verified provider: post-quantum key support rides on the exact same per-key and per-operation pricing as RSA or ECC keys. The real cost of migration is engineering time, plus the small bandwidth tax measured in the benchmark section above, not a new pricing tier waiting to be unlocked.

Use Cases: Where to Deploy Post-Quantum Encryption Now

Not every system needs ML-KEM in 2026. The right call depends on how sensitive the data is, how long it needs to stay confidential, and how much control you have over the client and server software involved. Here is a practical breakdown by scenario, roughly ordered from highest to lowest urgency.

• CDN and TLS termination at the edge: deploy hybrid X25519+ML-KEM now. Cloudflare has already proven this at internet scale with a measured 4% overhead, and most modern browsers negotiate it automatically when available.
• Long-lived encrypted archives (health records, legal discovery, government data): highest priority. This is exactly the harvest-now-decrypt-later target, and the data’s confidentiality window outlasts any realistic RSA/ECC safety margin.
• End-to-end encrypted messaging: follow Signal’s model. PQXDH shows a mature hybrid pattern already running in a widely audited protocol.
• Internal service-to-service mTLS on a private network: lower priority. The attack surface for harvest-now-decrypt-later is smaller when traffic never leaves a controlled network, though defense contractors should still track CNSA 2.0 deadlines.
• IoT and constrained embedded devices: proceed carefully. ML-KEM’s larger keys and ciphertexts cost more RAM and flash than X25519, which can matter on genuinely constrained microcontrollers. Test actual memory headroom before committing.
• Code signing and software supply chain: plan for ML-DSA or SLH-DSA migration on a separate timeline from key exchange, since certificate authorities and signing infrastructure need their own compatibility testing.
• Cryptocurrency wallets and blockchain signatures: watch this space rather than migrate today. As covered in our piece on Bitcoin’s quantum exposure, the relevant standard (BIP-360) is still a proposal, not a shipped protocol change.

Hybrid Mode: Why Nobody Is Doing a Clean Cutover

Every production deployment named in this article runs a hybrid combination of a classical algorithm and ML-KEM together, never ML-KEM alone. That is a deliberate engineering choice, not a transitional accident. Lattice-based cryptography is newer and has had far less real-world cryptanalysis than RSA or elliptic curves, which have survived roughly three and two decades of sustained attack respectively without a practical break. Running X25519 and ML-KEM-768 together means an attacker needs to break both simultaneously to compromise the session, so a hypothetical undiscovered flaw in lattice math does not immediately expose everything.

The naming convention reflects this directly: X25519MLKEM768 is a single TLS key-exchange group that internally runs both algorithms and combines their outputs into one shared secret. If either half stays secure, so does the connection. The IETF has standardized several of these combinations for TLS 1.3, and it’s the format essentially every deployment covered here, Cloudflare, Chrome, and Signal’s PQXDH, actually uses in production. A pure post-quantum-only deployment, while technically compliant with FIPS 203, is not what the field is actually running right now, and adopting one before hybrid mode is stable elsewhere would be an unusual choice for most teams.

Pros and Cons: Classical Encryption vs Post-Quantum Encryption

RSA/ECC (classical) advantages: small key and ciphertext sizes, decades of cryptanalysis and battle-testing, universal library and hardware support, no measurable bandwidth overhead, works on the most constrained embedded devices.

RSA/ECC disadvantages: both fall to Shor’s algorithm on a sufficiently capable quantum computer, offering zero protection against harvest-now-decrypt-later collection happening today, and RSA in particular is already showing its age in raw operation speed compared to elliptic curves.

ML-KEM (post-quantum) advantages: resistant to every known quantum algorithm, standardized and finalized by NIST as FIPS 203, already running in production at internet scale via Cloudflare and Chrome, fast encapsulation and decapsulation operations on modern CPUs, and backed by a growing ecosystem including liboqs and major TLS libraries.

ML-KEM disadvantages: public keys and ciphertexts run 4x to over 30x larger than classical equivalents depending on the comparison point, less cryptanalytic history than RSA or ECC (roughly a decade of serious public review versus multiple decades), can break middleboxes that assume small TLS handshakes, and costs more memory on constrained embedded hardware.

Weighed against each other, the disadvantages on both sides point toward the same conclusion the industry has already reached in practice: run both together. Classical algorithms cover the risk of an unexpected flaw in newer lattice math, and ML-KEM covers the risk that a quantum computer eventually arrives and factors RSA moduli or solves elliptic-curve discrete logs at scale. Betting the entire stack on either one alone means betting against a specific failure mode that hybrid deployment sidesteps almost for free.

The Quantum Threat Timeline: Compliance Deadlines vs Q-Day Hype

Separate the marketing from the paperwork here, because they move at very different speeds. Nobody in this research, not NIST, not an academic source, not a named quantum computing lab, has published a credible, specific date for when a cryptographically relevant quantum computer will exist. Any article, including this one, claiming a hard Q-day of 2030 or 2035 is guessing. IBM and Google continue publishing incremental qubit-count and error-correction progress, but neither has demonstrated a machine capable of factoring RSA-2048 as of this writing, and treating incremental hardware news as proof of an imminent break overstates what the public evidence shows.

What is concrete is regulatory pressure, not scientific certainty. The NSA’s CNSA 2.0 guidance, per its draft CSfC Post-Quantum Cryptography Guidance Addendum, calls for updated NIAP Protection Profiles covering CNSA 2.0 algorithms in 2026, and requires CNSA 2.0 algorithm support in new products and services starting January 1, 2027, unless a specific Capability Package, Protection Profile, or waiver says otherwise. That deadline applies to vendors selling into US national security systems, not to every company on the internet, but it functions as the industry’s de facto forcing function the same way PCI-DSS deadlines forced TLS 1.0 retirement years before most companies felt an urgent technical need to move.

The practical takeaway: treat post-quantum migration as a data-sensitivity and compliance question, not a race against a quantum computer that might not exist for years. If your data needs confidentiality past 2035 or you sell into regulated government contracts, the deadline that matters is already on the calendar, and it has nothing to do with when IBM’s next qubit-count press release drops.

It also helps to remember that standards bodies move slowly on purpose. NIST spent eight years running its post-quantum competition specifically to avoid rushing an algorithm into FIPS status only to find a weakness a year later. That same caution should apply to reading vendor marketing about quantum timelines. A press release announcing a new qubit milestone is not the same claim as a demonstrated break of RSA-2048, and conflating the two is how exaggerated “quantum apocalypse” headlines end up driving decisions that the underlying science doesn’t yet support.

Verdict: Which Should You Use in 2026

For anything you are building or re-architecting today, deploy hybrid X25519+ML-KEM-768 for TLS key exchange if your library stack supports it, which OpenSSL 3.2+, BoringSSL, and most major CDNs already do. The data backs this up cleanly: roughly 4% handshake latency overhead per Cloudflare’s own 2025 production telemetry and Chrome’s browser-wide measurement, against a threat, harvest-now-decrypt-later collection, that is already happening rather than hypothetical. That overhead is cheap insurance for a category of risk with no other mitigation.

Do not rip out RSA or ECC entirely. Every credible production deployment covered in this piece runs hybrid mode, keeping the classical algorithm as a safety net against any undiscovered weakness in lattice cryptography, which is roughly a decade old in serious public form versus multiple decades for RSA and ECC. Pure post-quantum-only deployment remains, at this point, ahead of where the broader ecosystem has actually landed.

Prioritize by data lifetime over hype. Long-lived encrypted archives and anything subject to CNSA 2.0 compliance should move first and fastest. Internal, short-lived, low-sensitivity traffic can wait for your TLS stack’s next routine upgrade cycle. And keep encryption and signatures on separate tracks: migrating key exchange to ML-KEM does nothing for certificate signing, which needs its own ML-DSA or SLH-DSA rollout on its own timeline. The technology is ready. The rollout, correctly, is staged.

Frequently Asked Questions

Is ML-KEM the same thing as Kyber?

Yes, functionally. ML-KEM is the NIST-standardized version of CRYSTALS-Kyber, finalized as FIPS 203 on August 13, 2024. Early deployments used pre-standard names like X25519Kyber768Draft00, while current deployments use the standardized X25519MLKEM768 naming after providers like Cloudflare migrated in 2025.

Does post-quantum encryption replace RSA and ECC completely?

Not in current practice. Every major production deployment covered in this article runs a hybrid combination of a classical algorithm (X25519 or ECDH) plus ML-KEM together, not ML-KEM alone, specifically to keep the decades of cryptanalysis backing classical algorithms as a safety net.

How much slower is quantum-resistant encryption than RSA or ECC?

Based on Cloudflare’s 2025 production data and Google Chrome’s browser telemetry, expect roughly a 4% TLS handshake latency increase. An academic 2026 study measured a comparable 17.1% increase for the higher ML-KEM-768 security level versus plain X25519 in a controlled test. The overhead comes mostly from larger packet sizes, not from slower cryptographic computation.

Do I need to worry about quantum computers breaking my encryption today?

No cryptographically relevant quantum computer capable of breaking RSA-2048 has been publicly demonstrated as of this research. The real near-term risk is harvest-now-decrypt-later, where encrypted traffic is recorded today for decryption once such a machine exists, which matters most for data that needs to stay confidential for a decade or longer.

What is the difference between ML-KEM and ML-DSA?

ML-KEM (FIPS 203) handles key encapsulation, the post-quantum replacement for RSA/ECDH key exchange. ML-DSA (FIPS 204) handles digital signatures, the post-quantum replacement for RSA/ECDSA signing. They solve different problems and typically get migrated on separate timelines.

Does switching to post-quantum encryption cost more on AWS or Google Cloud?

No separate pricing tier for post-quantum algorithms was identified on AWS KMS, AWS CloudHSM, or Google Cloud KMS as of this research. Post-quantum keys are billed under the same per-key and per-operation pricing as RSA or ECC keys. The real added cost is engineering time and the small bandwidth overhead measured in the benchmark section above.

Which companies have already deployed post-quantum encryption in production?

Confirmed, dated production deployments include Cloudflare (origin server connections starting September 29, 2023, migrated to standardized ML-KEM by September 24, 2025), Signal (PQXDH protocol, announced September 19, 2023), and Google Chrome (hybrid post-quantum key exchange enabled by default for desktop traffic starting in 2023-2024).

Should small companies migrate to post-quantum encryption now?

If you’re using a modern CDN, load balancer, or TLS library that already supports hybrid X25519+ML-KEM, it typically activates with a configuration change rather than a rebuild, so there’s little reason to wait. Custom-built systems handling long-lived sensitive data should prioritize the migration. Low-sensitivity, short-lived internal traffic can reasonably wait for your next scheduled TLS library upgrade.

Related Coverage

• ML-KEM vs HQC: NIST's Backup Adds 4x the Compute [2026]
• ML-KEM vs RSA: 1,184-Byte Keys, 52% Web Adoption [2026]
• ZK Proofs vs Homomorphic Encryption: 68x Speed Gap [2026]
• RSA vs Diffie-Hellman: TLS 1.3 Keeps Only One [2026]
• ML-KEM vs Classic McEliece: 300x Bigger Keys [2026]