ML-KEM vs RSA: 1,184-Byte Keys, 52% Web Adoption [2026]

RSA has secured internet traffic since 1977. That run has an expiration date now. On August 13, 2024, NIST finalized FIPS 203, turning the lattice-based algorithm known as Kyber into ML-KEM, the government’s official replacement for RSA and elliptic-curve Diffie-Hellman key exchange. Two years later, the migration is no longer theoretical. Cloudflare reports that post-quantum encrypted traffic on its network jumped from 29% to 52% of all HTTPS connections during 2025, and AWS has rolled ML-KEM support into KMS, ACM, Secrets Manager, S3, and Transfer Family.

So which one should you actually run in 2026? This comparison lays out the real numbers: key sizes, handshake latency benchmarks from three independent sources, cloud pricing and availability, a step-by-step migration path, and a verdict based on where the data actually points, not on vendor marketing.

This isn’t a swap you make overnight, and it isn’t one you can ignore either. RSA and ECDH still protect the vast majority of internet traffic today, and neither is cryptographically broken. But the standardization work is done, the browsers and cloud platforms have already shipped support, and the compliance clock on federal systems is already running. Whether you manage a single API gateway or a fleet of thousands of TLS endpoints, the question has shifted from “should we plan for this” to “how fast do we move, and where do we start.”

What Is Post-Quantum Cryptography, and Why Does RSA Need Replacing?

RSA and elliptic-curve cryptography (ECC) both rely on math problems that are hard for classical computers but not for a sufficiently large quantum computer. RSA’s security rests on the difficulty of factoring large numbers; ECC rests on the discrete logarithm problem over elliptic curves. Peter Shor showed back in 1994 that a fault-tolerant quantum computer could solve both problems in polynomial time. No such machine exists yet at the scale needed to break RSA-2048, but the threat isn’t purely future-tense.

The practical risk is called “harvest now, decrypt later.” An adversary captures encrypted traffic today, stores it, and decrypts it once a capable quantum computer exists. For data that needs to stay confidential for a decade or more, medical records, government communications, financial infrastructure, that’s already a live problem, not a hypothetical one. This is the reason NIST moved on post-quantum cryptography years before quantum computers posed an immediate decryption threat.

NIST’s answer came in three finalized standards on August 13, 2024: FIPS 203 (ML-KEM) for key encapsulation, FIPS 204 (ML-DSA) for digital signatures, and FIPS 205 (SLH-DSA) as a conservative hash-based signature backup. A fourth KEM, HQC, was added on March 11, 2025 as a structurally different backup algorithm in case flaws are later found in lattice-based math. For key exchange specifically, the comparison that matters to nearly every engineering team right now is ML-KEM vs RSA and ECDH.

The Road to FIPS 203: A Six-Year Public Competition

ML-KEM didn’t appear out of nowhere. NIST opened a public call for post-quantum algorithms in December 2016, inviting cryptographers worldwide to submit candidates for key establishment and digital signatures. Eighty-two submissions came in during the first round. NIST and the broader cryptographic community spent years attacking those candidates in public, the same open, adversarial process that vetted AES and SHA-3 before it. Rounds narrowed the field in 2019 and 2020, and in July 2022 NIST announced its first selections: CRYSTALS-Kyber for key encapsulation, and CRYSTALS-Dilithium, FALCON, and SPHINCS+ for digital signatures.

That two-year gap between the 2022 selection and the 2024 final publication wasn’t idle time. NIST used it to formalize parameter choices, tighten security proofs, and standardize encodings, which is exactly why ML-KEM ended up not being a byte-for-byte match for the Kyber submission that won the competition. The renamed standards, ML-KEM, ML-DSA, and SLH-DSA, reflect that final hardening pass. Compared to how long RSA has been in service, this is still an early chapter, but it’s the most heavily scrutinized cryptographic rollout NIST has ever run.

Meet ML-KEM: NIST’s New Standard Under FIPS 203

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is a lattice-based algorithm derived from CRYSTALS-Kyber, the finalist NIST selected in 2022 after a six-year, multi-round public competition. Instead of factoring or discrete logs, ML-KEM’s security rests on the Learning With Errors (LWE) problem over structured lattices, a problem believed to resist both classical and quantum attacks. It ships in three parameter sets tuned to different security levels: ML-KEM-512 (roughly equivalent to AES-128), ML-KEM-768 (AES-192-equivalent, the default most deployments use), and ML-KEM-1024 (AES-256-equivalent).

From Kyber to ML-KEM: What Actually Changed

The rename wasn’t cosmetic. NIST tweaked encoding and parameter details during standardization, so ML-KEM as specified in FIPS 203 is not byte-for-byte compatible with the original Kyber submission, a detail that tripped up some early implementers who assumed a straight swap. FIPS 203 itself carries a planning note dated November 17, 2025 acknowledging an issue NIST intends to correct in a future revision, a normal part of standards maturation but worth tracking if you’re deploying at scale. In practical terms, that means teams should pull ML-KEM implementations from maintained libraries (OpenSSL 3.2+, liboqs) rather than hand-rolling from the original Kyber reference code.

Choosing a parameter set is straightforward for most teams. ML-KEM-768 is the default nearly everyone should reach for, it’s the group Chrome, Firefox, and Cloudflare negotiate by default when paired with X25519, and it matches the security margin of AES-192, comfortably above what current threat models require. ML-KEM-512 fits latency- or bandwidth-starved environments where every byte counts, while ML-KEM-1024 is reserved for systems with the strictest long-term confidentiality requirements, government classified networks and similar, where the extra 384 bytes per key barely register against the value of the data being protected.

How RSA and ECDH Key Exchange Work Today

RSA key exchange (technically RSA encryption of a pre-master secret, since RSA isn’t a true key-agreement protocol) and Diffie-Hellman variants over elliptic curves (ECDH, using curves like P-256 or X25519) have carried TLS traffic for over two decades. Their appeal is compactness: an X25519 key share is just 32 bytes, and a P-256 share is 65 bytes uncompressed. RSA-2048 keys run around 256 bytes for the raw modulus. These primitives are fast, small, and have survived nearly 30 years of public cryptanalysis with no practical break against correctly implemented, adequately sized keys.

That track record is exactly why replacing them is contentious in some circles. Nobody wants to trade a battle-tested primitive for something newer unless the threat is real. But NIST, the NSA’s CNSA 2.0 guidance, and every major cloud provider now treat the quantum threat as real enough to require action starting now, not in 2035 when the deadlines actually hit.

Scale is part of what makes this transition hard. RSA and ECDH are embedded in decades of shipped hardware, firmware, and protocol implementations, everything from browser TLS stacks to smart-card readers to industrial control systems that were never designed with algorithm agility in mind. Ripping that out wholesale isn’t realistic on any near-term timeline, which is precisely why the hybrid approach covered later in this piece, running classical and post-quantum key exchange side by side, has become the default migration strategy rather than a straight cutover.

ML-KEM vs RSA vs ECDH: Full Specs Comparison

The single biggest practical difference between these families is size. ML-KEM trades small keys for quantum resistance, and the gap is substantial. Here’s the full breakdown, with figures pulled directly from FIPS 203’s official parameter tables and standard TLS encoding practice for classical algorithms.

Algorithm	Type	Public Key	Ciphertext/Signature	Private Key	Quantum-Safe
ML-KEM-512	Lattice KEM	800 bytes	768 bytes	1,632 bytes	Yes
ML-KEM-768	Lattice KEM	1,184 bytes	1,088 bytes	2,400 bytes	Yes
ML-KEM-1024	Lattice KEM	1,568 bytes	1,568 bytes	3,168 bytes	Yes
RSA-2048	Factoring	~256 bytes	256 bytes	~256 bytes	No
RSA-3072	Factoring	~384 bytes	384 bytes	~384 bytes	No
RSA-4096	Factoring	~512 bytes	512 bytes	~512 bytes	No
ECDH P-256	Elliptic curve	65 bytes	n/a (shared secret)	32 bytes	No
ECDH P-384	Elliptic curve	97 bytes	n/a (shared secret)	48 bytes	No
X25519	Elliptic curve	32 bytes	n/a (shared secret)	32 bytes	No
ML-DSA-65 (signing)	Lattice signature	1,952 bytes	3,309 bytes	4,032 bytes	Yes

The takeaway: ML-KEM-768, the parameter set most deployments default to, carries a public key roughly 18x larger than an X25519 share and 4-5x larger than an RSA-2048 key. That size gap is the entire story behind the migration’s practical friction, and it’s why the benchmark numbers below matter more than the raw byte counts alone.

Put in real terms: a classical TLS 1.3 handshake using X25519 sends roughly 32 bytes of key-share data each direction, plus certificate and signature overhead. Swap in hybrid X25519+ML-KEM-768 and the client’s key share alone grows to around 1,216 bytes (the 32-byte X25519 share plus the 1,184-byte ML-KEM public key), with the server’s response adding another 1,120 bytes or so for its ciphertext and share. That’s roughly 2.3 KB of additional handshake payload split across both directions, which sounds significant in isolation but sits well under a single network packet on any connection running above dial-up speeds.

Benchmark Data: Handshake Latency and CPU Overhead

Bigger keys don’t automatically mean a slower connection. CPU time and network round-trip time matter more than raw byte counts, and three independent benchmark sources now back that up. A 2026 academic paper comparing classical, hybrid, and pure post-quantum key exchange measured median full TLS handshake latency (from ClientHello to Finished) across configurations on modern hardware, and the differences were small.

Configuration	Median Handshake Latency	Delta vs Classical	Source
X25519 (classical only)	5.547 ms	Baseline	Academic TLS key-exchange benchmark, 2026
X25519 + ML-KEM-512 (hybrid)	5.879 ms	+6.0%	Academic TLS key-exchange benchmark, 2026
X25519 + ML-KEM-768 (hybrid)	6.495 ms	+17.1%	Academic TLS key-exchange benchmark, 2026
CECPQ2 (X25519 + NTRU-HRSS), Android p99	4,057-4,478 ms (p99, high-latency mobile)	Varies by network	Cloudflare TLS experiment blog
ML-KEM-512 replacing RSA, handshake bytes	+155% data transmitted	2.55x bytes	“Towards the Quantum-Safe Web” benchmark paper
ML-KEM-1024 replacing P-521, handshake bytes	+150% data (2.5x total)	~4,700 KB total handshake	“Towards the Quantum-Safe Web” benchmark paper

Read those two categories separately. CPU-bound latency barely moves: hybrid X25519+ML-KEM-768 adds well under a millisecond versus classical-only X25519 on typical server and client hardware, with statistical effect sizes the researchers classify as negligible to small. Cloudflare reached a similar conclusion years earlier during its CECPQ2 experiment with NTRU-HRSS, noting that “fast algorithms with large keys may be more suitable for TLS than slow algorithms with small keys,” a finding that still holds for ML-KEM.

Why does the CPU cost stay so low despite the size increase? Lattice math is cheap on modern silicon. ML-KEM’s core operations, polynomial multiplication and sampling over a structured ring, run in the tens of microseconds on any x86-64 or ARM core built in the last several years, on par with or faster than the elliptic-curve scalar multiplication that X25519 relies on. The bottleneck was never the arithmetic. It’s the extra kilobyte or two of network payload, and that cost scales with your network conditions, not your server’s processor.

Bandwidth Is the Real Cost, Not CPU Time

Bandwidth overhead is where ML-KEM actually costs something measurable. Swapping RSA for ML-KEM-512 increases total handshake data by roughly 155%, and swapping X25519 for the same parameter set can push overhead past 227%, according to the quantum-safe web benchmarking paper. For most web traffic over broadband or modern mobile networks, an extra kilobyte or two per handshake is invisible. For satellite links, constrained IoT radios, or high-frequency connection setups at massive scale, it adds up. Cloudflare’s own bandwidth modeling found that crossing roughly 9-10 KB of extra handshake data can trigger an additional round trip and a slowdown exceeding 60% in worst-case network conditions, though that threshold is well above what a single ML-KEM-768 exchange adds on its own.

Pricing and Availability Across Cloud Providers

Here’s the good news for budgets: no major provider charges extra for turning on ML-KEM. It’s bundled into existing TLS termination and key-management pricing. The cost that matters is engineering time for testing, certificate chain updates, and library upgrades, not a line item on a cloud bill.

Provider/Product	ML-KEM Support	Pricing Model	Notes
AWS KMS	Hybrid PQ TLS, non-FIPS endpoints, all regions	Included, standard KMS API pricing applies	No added fee for PQ key exchange
AWS Certificate Manager (ACM)	Hybrid PQ TLS supported	Included, free for AWS-issued certs	Same cert issuance pricing as before
AWS Secrets Manager	Hybrid PQ TLS; Secrets Manager Agent v2.0+ prefers ML-KEM by default	Included, standard per-secret pricing	No PQ surcharge
Amazon S3	Post-quantum TLS key exchange on all regional and S3 Express endpoints	Included, standard S3 request/storage pricing	Rolled out broadly through late 2025
AWS Transfer Family	ML-KEM-based hybrid SSH key exchange via updated security policies	Included in existing Transfer Family pricing	Policies: TransferSecurityPolicy-2025-03 and FIPS variant
Cloudflare (all plans)	Hybrid PQ TLS on by default at the edge	Included on Free, Pro, Business, and Enterprise tiers	No opt-in fee; browser support required client-side
OpenSSL 3.2+	ML-KEM implementations available	Free, open source	Used as the base for many self-hosted deployments
Open Quantum Safe (liboqs)	Reference and provider implementations	Free, open source	Standard testing ground before production rollout

The pattern is consistent: PQC readiness is being absorbed into existing infrastructure rather than sold as a premium add-on. That’s a deliberate choice by NIST and the major cloud vendors, since a paid upgrade path would slow adoption exactly when regulators and security teams need it accelerated.

The real cost sits in engineering hours, not invoices. Budget for library upgrades across your service fleet, load testing under real traffic patterns, certificate chain updates for signature algorithms, and monitoring changes to distinguish classical, hybrid, and pure-PQC connections. For a team running a handful of services behind a managed load balancer or CDN, that’s a scoped project measured in weeks. For an organization with thousands of internal services, custom protocols, and legacy hardware, it’s a multi-year program, which is exactly why NIST built years of runway into its own migration timeline rather than demanding an immediate cutover.

Real-World Adoption: Who’s Already Running ML-KEM

This isn’t a lab exercise anymore. Production deployments are live across browsers, cloud infrastructure, and messaging apps.

• Cloudflare’s network defaults to hybrid post-quantum key exchange, and the share of HTTPS traffic using it rose from 29% to 52% during 2025 according to Cloudflare Radar’s year-end tracking.
• AWS KMS, ACM, and Secrets Manager added hybrid ML-KEM TLS support starting in April 2025, with AWS’s own migration guidance now listing ML-KEM as the preferred key-exchange method going forward.
• Amazon S3 extended post-quantum TLS key exchange to its regional and S3 Express One Zone endpoints in late 2025, covering one of the highest-traffic storage services on the internet.
• Chrome, Firefox, and Edge all ship hybrid PQ TLS support, which Cloudflare credits as the main driver behind the 2025 jump in encrypted PQ traffic share.
• OpenSSL 3.2+ shipped ML-KEM support, making it accessible to any self-hosted server or internal service that links against a current OpenSSL build.
• Signal deployed PQXDH, a Kyber-based post-quantum extension to its X3DH key agreement protocol, for message key establishment.
• Apple’s iMessage runs PQ3, its own post-quantum protocol design, between up-to-date devices as of early 2026.

Notice the pattern: infrastructure providers and browser vendors moved first, since they control both ends of high-volume connections and can push updates centrally. Enterprise internal systems, embedded devices, and long-tail legacy software are lagging well behind, which is exactly where the NIST migration timeline below is aimed.

Case Study: Cloudflare’s Multi-Year Rollout

Cloudflare’s path here started long before FIPS 203 existed. The company began experimenting with post-quantum key exchange as early as 2019, running live tests with candidate algorithms like NTRU-HRSS and SIKE under the CECPQ2 project, years before any of them were standardized. That early groundwork paid off once ML-KEM finalized: Cloudflare enabled hybrid post-quantum key agreement by default across its edge network, and adoption climbed steadily as Chrome, Firefox, and Edge added client-side support. The jump from 29% to 52% of HTTPS traffic during 2025 wasn’t a single flip of a switch, it was the compounding effect of years of infrastructure work meeting browser-side readiness at the same time.

Case Study: AWS’s Service-by-Service Migration

AWS took a different approach: rolling ML-KEM support out service by service rather than as one platform-wide change. KMS, ACM, and Secrets Manager got hybrid post-quantum TLS support in April 2025. Transfer Family followed in September 2025 with ML-KEM-based SSH key exchange. Amazon S3, one of the highest-traffic services in the company’s portfolio, added post-quantum TLS across its regional and S3 Express One Zone endpoints in November 2025. AWS Payments Cryptography picked it up the same month. That incremental, service-by-service cadence let AWS validate performance and compatibility at each step before expanding scope, a pattern worth copying for any organization managing a large, heterogeneous set of TLS endpoints rather than a single termination point.

The NIST Migration Timeline: 2026 Through 2035

Federal migration guidance lays out a multi-year runway rather than a single cutover date, and it’s a reasonable template for private-sector planning too. Initial PQC integration for federal civilian agencies is expected through 2026. High-value asset systems face compliance gates around 2030. Defense and high-impact systems are targeted for full migration by 2031. Final infrastructure cutover, meaning classical-only RSA and ECDH are expected to be deprecated across federal systems, lands around 2035.

A fourth standard, FIPS 206 (FN-DSA), is still in draft and aimed at compact lattice-based signatures for bandwidth-constrained environments like IoT and embedded devices. It’s expected to finalize sometime in the 2026-2027 window, which matters if you’re planning PQC for anything smaller than a general-purpose server.

How to Migrate from RSA to ML-KEM: A Step-by-Step Guide

Nobody should rip out RSA and drop in ML-KEM cold. The accepted path, used by AWS, Cloudflare, and every major PKI vendor, is hybrid mode: run classical and post-quantum key exchange together, so a break in either algorithm alone doesn’t compromise the session. Here’s the sequence most security teams are following in 2026.

1. Inventory your cryptographic assets. List every place RSA or ECDH handles key exchange: TLS termination points, VPNs, SSH, internal mTLS, and any custom protocol. You can’t migrate what you haven’t found.
2. Classify data by shelf life. Anything that must stay confidential past 2035, health records, government secrets, long-term financial data, goes to the front of the queue because of harvest-now-decrypt-later risk.
3. Upgrade your TLS library. Move to OpenSSL 3.2+ or a library with liboqs support, since neither older OpenSSL branches nor most legacy TLS stacks include ML-KEM natively.
4. Enable hybrid key exchange, not pure PQC. Configure X25519+ML-KEM-768 (the group most browsers now negotiate) rather than switching to ML-KEM alone, preserving classical fallback security.
5. Test handshake performance under your real traffic patterns. The benchmark numbers above are averages; constrained networks or high-connection-rate services should load-test before rollout.
6. Update certificate chains for ML-DSA signatures separately. Key exchange and signing are different problems; migrating ML-KEM doesn’t touch your certificate signature algorithm, which needs its own ML-DSA or SLH-DSA migration plan.
7. Track FIPS 206 for constrained devices. If you manage IoT or embedded hardware, hold off on a final signature scheme until FN-DSA finalizes rather than committing to an interim choice.
8. Roll out in waves, not all at once. Follow AWS’s model: pick one service or endpoint group, validate handshake performance and client compatibility under real load, then expand. A staged rollout catches integration issues before they hit every connection at once.
9. Document your fallback path. Hybrid mode means a classical algorithm is still doing real work as a safety net. Make sure your monitoring can distinguish pure-classical, hybrid, and pure-PQC handshakes so you can track migration progress and catch clients that silently fail to negotiate the new group.

For teams testing locally, the Open Quantum Safe project provides an OpenSSL provider that makes verifying a hybrid handshake straightforward:

openssl s_client -connect example.com:443 -groups X25519MLKEM768 -tls1_3

# Check the negotiated group in the handshake output.
# A successful hybrid negotiation shows:
#   Server Temp Key: X25519MLKEM768

Pros and Cons: ML-KEM vs RSA/ECDH

Neither side wins outright. The honest comparison depends on what you’re protecting and how long it needs to stay protected.

ML-KEM

• Pro: Resistant to known quantum algorithms, closing the harvest-now-decrypt-later gap.
• Pro: Finalized as a federal standard (FIPS 203), with a clear compliance path for regulated industries.
• Pro: CPU overhead is minor, generally under 20% versus classical-only handshakes and often within measurement noise.
• Con: Public keys and ciphertexts run 4-18x larger than RSA or X25519, adding real bandwidth overhead at scale.
• Con: Younger than RSA by decades; lattice cryptography has had less real-world cryptanalytic scrutiny, and FIPS 203 itself carries an open planning note for a future revision.
• Con: Early Kyber implementations were hit by the KyberSlash timing-attack family, a reminder that new algorithms carry new implementation risk even when the math holds up.
• Con: Larger keys mean more memory and storage overhead for systems handling huge volumes of concurrent sessions, a real capacity-planning consideration for high-throughput API gateways.

RSA/ECDH

• Pro: Nearly 30 years of public cryptanalysis with no practical break at current key sizes.
• Pro: Small key and signature sizes, minimal bandwidth impact, universal library and hardware support.
• Pro: Mature tooling, HSM support, and audit familiarity across nearly every compliance framework.
• Con: Provably breakable by a sufficiently large fault-tolerant quantum computer via Shor’s algorithm.
• Con: Data encrypted with RSA/ECDH today is already exposed to harvest-now-decrypt-later collection.
• Con: Federal deprecation timelines (2030-2035) mean RSA-only deployments face a hard compliance wall for regulated sectors.
• Con: Larger RSA key sizes (4096-bit and up), sometimes proposed as a stopgap, add real CPU cost without solving the underlying quantum vulnerability at all.

Best Use Cases: When to Choose Which

Most organizations don’t face a binary choice. Hybrid mode makes “which one” a false question for the majority of deployments, but priority and pace should still vary by scenario.

• Public-facing web and CDN traffic: Follow Cloudflare’s lead and enable hybrid X25519+ML-KEM by default; browser support is already broad enough that the overhead is worth it now.
• Regulated finance and payments infrastructure: Prioritize ML-KEM migration ahead of the 2030 compliance gate; AWS Payments Cryptography’s PQ TLS support is a template worth following.
• Long-lived sensitive data (health, government, legal archives): Treat this as urgent regardless of your general migration timeline, since harvest-now-decrypt-later risk is active today, not in 2035.
• Consumer messaging apps: Follow the Signal PQXDH or Apple PQ3 model, layering post-quantum key establishment on top of existing protocols rather than a full rebuild.
• Resource-constrained IoT and embedded devices: Hold off on a final signature scheme until FIPS 206 (FN-DSA) finalizes; bandwidth overhead from full ML-KEM/ML-DSA may be impractical on constrained radios today.
• Internal microservices and mTLS: Lower urgency than public-facing traffic, but a good low-risk environment to pilot OpenSSL 3.2+ and liboqs before a customer-facing rollout.
• VPN and remote-access infrastructure: Prioritize alongside public web traffic; VPN sessions often carry the same class of long-lived, sensitive data that makes harvest-now-decrypt-later a genuine concern, and major VPN vendors are already adding hybrid PQ key exchange to their protocol stacks.

One pattern holds across nearly every scenario above: the organizations moving first aren’t waiting for a mandate. They’re moving because the overhead is small, the tooling is free, and the data at risk today doesn’t wait for a 2030 compliance deadline to become exposed.

Security Risks: KyberSlash and Side-Channel Attacks

New algorithms carry new implementation risk, and ML-KEM’s early history proves the point. The KyberSlash timing-attack family, disclosed in 2023, affected certain Kyber implementations that performed variable-time division operations, potentially leaking secret key material to an attacker who could measure timing differences. FIPS 203 addresses constant-time requirements directly, and the maintained libraries teams should actually deploy, OpenSSL 3.2+ and liboqs, have been patched against the known variants.

The practical lesson isn’t “avoid ML-KEM.” It’s “don’t hand-roll it.” Pull implementations from actively maintained, widely audited libraries rather than reference code, and keep those libraries current. As of the sources available for this piece, no major CVE or production security incident has hit ML-KEM as deployed in Cloudflare’s, AWS’s, or the major browsers’ production infrastructure, but that track record is still measured in months, not decades, unlike RSA’s.

Hybrid mode isn’t just a compatibility bridge, it’s also a security hedge against exactly this kind of implementation risk. If a flaw is later found in ML-KEM’s lattice math or in a specific library’s implementation, a properly configured hybrid handshake still falls back on RSA or X25519’s decades of scrutiny to keep the session secure. That’s the practical argument for running hybrid well past the point where pure PQC becomes technically viable, defense in depth costs a few extra bytes per handshake, and it buys real insurance against a young algorithm’s unknown unknowns.

The Verdict: What Should You Actually Deploy in 2026?

Run hybrid key exchange, not a hard cutover in either direction. The data supports this cleanly: CPU overhead from adding ML-KEM-768 to an X25519 handshake sits around 17% in the most detailed 2026 benchmark available, an amount that disappears into network latency for the overwhelming majority of connections. Bandwidth overhead is the real cost, running 150-227% more handshake data depending on your classical baseline, which matters for constrained networks but is a rounding error for typical web and API traffic.

Cloudflare’s traffic data backs the “do it now” case: PQ-encrypted HTTPS traffic nearly doubled across 2025, evidence that the internet’s infrastructure providers have already concluded the overhead is worth paying. If you’re running public-facing TLS, enable hybrid ML-KEM this year. If you’re managing constrained or embedded systems, wait for FIPS 206 but start your inventory now. And regardless of your industry, treat any data with a confidentiality requirement past 2035 as already at risk under harvest-now-decrypt-later collection. RSA and ECDH aren’t broken today. But the standards, the deadlines, and the production traffic data all point the same direction.

Measured against the alternative, waiting, the case gets stronger every quarter. Each month of delay is another month of RSA- and ECDH-protected traffic that a future quantum computer could theoretically unwind, and another month further behind the browsers, CDNs, and cloud providers that have already made the switch the default. The migration doesn’t need to happen in a weekend. It needs to start.

Frequently Asked Questions

Is ML-KEM the same thing as Kyber?

Close, but not identical. ML-KEM is NIST’s standardized version of Kyber under FIPS 203, finalized August 13, 2024. NIST made encoding and parameter adjustments during standardization, so ML-KEM isn’t byte-for-byte compatible with the original Kyber submission from the NIST competition.

Does ML-KEM replace RSA for everything, including digital signatures?

No. ML-KEM (FIPS 203) is a key-encapsulation mechanism for key exchange only. Signatures are a separate migration covered by ML-DSA (FIPS 204) and SLH-DSA (FIPS 205). You need both migrations for full RSA replacement.

Will switching to ML-KEM slow down my website?

Barely, for most traffic. 2026 benchmark data shows hybrid X25519+ML-KEM-768 handshakes add roughly 17% CPU-bound latency versus classical-only, typically under a millisecond in absolute terms. The larger cost is bandwidth, not CPU, and it’s most noticeable on constrained or high-latency networks.

Do I need to migrate immediately, or can this wait?

It depends on data sensitivity. Federal migration guidance sets compliance gates around 2030 for high-value systems and full cutover around 2035, but data that must stay confidential beyond that window is already exposed to harvest-now-decrypt-later collection today, so prioritize accordingly rather than treating every system with the same urgency.

Which browsers and cloud providers already support ML-KEM?

Chrome, Firefox, and Edge all support hybrid post-quantum TLS. On the infrastructure side, Cloudflare runs it by default across its network, and AWS has added support across KMS, ACM, Secrets Manager, S3, and Transfer Family through 2025 and into 2026.

Is ML-KEM safe to use in production today?

Yes, when deployed through maintained libraries like OpenSSL 3.2+ or liboqs rather than hand-rolled implementations. Early Kyber implementations had timing-attack issues (KyberSlash), but current maintained libraries have patched against known variants, and major providers are already running it at production scale.

What is HQC, and why does NIST have a backup KEM?

HQC (Hamming Quasi-Cyclic) is a fifth post-quantum algorithm NIST announced on March 11, 2025 as an additional key-encapsulation option. It’s based on a structurally different mathematical problem than ML-KEM’s lattice approach, giving the standard a fallback if a future flaw is found in lattice-based cryptography.

Should small companies worry about post-quantum migration now?

If you’re on a major cloud provider or CDN, much of the migration is happening underneath you already through provider-level TLS termination. Direct action matters most if you manage your own TLS stack, issue your own certificates, or handle data with a multi-decade confidentiality requirement.

What’s the difference between ML-KEM and ML-DSA?

ML-KEM (FIPS 203) handles key exchange, establishing a shared secret between two parties. ML-DSA (FIPS 204) handles digital signatures, verifying that a message or certificate came from who it claims to. They solve different problems and are typically deployed together in a full post-quantum TLS stack, but migrating one doesn’t automatically migrate the other.

How much bigger are TLS handshakes with ML-KEM in practice?

A hybrid X25519+ML-KEM-768 handshake adds roughly 2.3 KB of combined key-share data across both directions compared to classical X25519 alone. That’s negligible on broadband or modern mobile connections, but it’s a meaningful consideration for constrained networks like satellite links or narrowband IoT radios, where every kilobyte affects both latency and power consumption.

Related Coverage

• ML-KEM vs ML-DSA: 1,088 vs 3,293 Bytes [2026]
• Argon2 vs bcrypt: $750K vs $40K to Crack a Password [2026]
• TLS 1.3 vs TLS 1.2: 70% Adoption, 1-RTT Handshake [2026]
• Quantum-Proof Bitcoin Wallet: 12 Steps, 45 Min [2026]
• Digital Signature vs E-Signature: 25x Faster to Sign [2026]
• Bitcoin Hacks Hit $130M as Red Team Finds 85 Bugs [2026]
• More cryptography coverage

Sources: NIST FIPS 203 (ML-KEM), NIST FIPS 204 (ML-DSA), NIST FIPS 205 (SLH-DSA), NIST’s August 2024 standards announcement, NIST Post-Quantum Cryptography Project, Cloudflare’s post-quantum TLS research, and the Open Quantum Safe project.