ML-KEM vs ML-DSA: FIPS 203 vs 204 Explained [2026]

The same logic applies on the signature side, though adoption trails encryption. DigiCert’s own internal migration plan pairs x25519mlkem768 for confidentiality with ML-DSA-44 for authentication on its systems, while also supporting ML-DSA-65 and ML-DSA-87 for customers who want a wider margin. The common failure mode teams report during pilots isn’t a broken algorithm, it’s skipping the hybrid step and assuming pure post-quantum is “good enough,” which breaks compatibility with any client or verifier that hasn’t updated yet.

The IETF standardized the exact combiner behind this pattern, defining the X25519MLKEM768 codepoint (0x11EC) that Chrome, Firefox, and Safari all negotiate today, so implementers aren’t inventing their own key-combination logic from scratch. That standardization is a big part of why hybrid deployment has moved as fast as it has: teams aren’t debating how to combine the two secrets, they’re just turning on a well-specified, already-interoperable feature flag.

Use Cases: When to Reach for ML-KEM vs ML-DSA

The two algorithms rarely compete for the same job. Instead, most systems need both, one for confidentiality and one for authenticity. Here’s how to split the decision, roughly in order of how much production evidence already backs each choice.

TLS 1.3 web and API traffic: ML-KEM-768 in the X25519MLKEM768 hybrid group. This is the path with the most production mileage and the smallest performance hit.
VPN and IPsec tunnels: ML-KEM, following Cloudflare’s approach in its SASE and Cloudflare One products, which extended the same hybrid key agreement to IPsec at no extra cost.
Code signing and software supply chain integrity: ML-DSA-65, since verifying that a binary or update came from a trusted source is exactly the authenticity problem ML-DSA was built for.
Long-lived root certificate authorities and firmware signing: ML-DSA-87, or SLH-DSA where teams want an entirely different mathematical foundation as a hedge against a future lattice break.
Federal identity and PIV/CAC cards: a combination of both, per NIST’s June 2026 working draft, ML-DSA for card authentication signatures and ML-KEM for key establishment during login.
End-to-end encrypted messaging: ML-KEM for the session key exchange (as in Signal’s PQXDH and Apple’s PQ3), often paired with a signature scheme like ML-DSA to authenticate the initial handshake.

Lightweight and embedded devices deserve a note of their own. IoT sensors, smart cards, and other constrained hardware often can’t afford ML-KEM-768’s memory footprint, let alone ML-DSA-65’s larger signatures. That’s exactly why NIST kept the smaller Category 1 sets, ML-KEM-512 and ML-DSA-44, in the standard: they trade some security margin for a footprint that fits inside a microcontroller’s limited RAM, at the cost of dropping from roughly 192-bit to 128-bit equivalent strength.

Migration Guide: Deploying ML-KEM and ML-DSA in Production

Teams that have already gone through this transition converge on a similar order of operations, encryption first, signatures second, because the encryption side is backward-compatible by design and the signature side touches more brittle verification code.

Inventory every TLS endpoint, VPN gateway, code-signing pipeline, and certificate authority still running classical-only RSA, ECDSA, or ECDH.
Enable hybrid key exchange first. Turning on X25519MLKEM768 at TLS termination points is the lowest-risk change, since it’s opportunistic and falls back gracefully for older clients.
Upgrade crypto libraries to versions that implement FIPS 203 and FIPS 204 natively, such as OpenSSL 3.5+, wolfSSL, or liboqs-backed builds.
Validate against NIST’s published known-answer test vectors from the Cryptographic Algorithm Validation Program before touching production traffic.
Pilot ML-DSA-65 signing on one non-critical pipeline, such as an internal code-signing or staging certificate chain, before touching customer-facing certificates.
Dual-sign certificates during the transition (classical algorithm plus ML-DSA) so verifiers without post-quantum support don’t break outright.
Roll out to production gradually while monitoring CPU load and bandwidth, since larger keys and signatures add real bytes to every handshake and every certificate chain.
Track NIST’s long-range deprecation guidance, which flags 2035 as the target date to have replaced quantum-vulnerable public-key algorithms for the most sensitive data.

A minimal OpenSSL 3.5+ example for generating keys under both standards looks like this:

# Generate an ML-KEM-768 key pair for key exchange
openssl genpkey -algorithm ML-KEM-768 -out mlkem768.key

# Generate an ML-DSA-65 key pair and a self-signed cert for signing
openssl genpkey -algorithm ML-DSA-65 -out mldsa65.key
openssl req -new -x509 -key mldsa65.key -out mldsa65.crt -days 365

# Confirm the hybrid group is active on a live TLS 1.3 connection
openssl s_client -connect example.com:443 -groups X25519MLKEM768

Common Migration Mistakes to Avoid

Teams that have already run this migration keep tripping over the same handful of mistakes. The first is skipping hybrid mode entirely and shipping pure ML-KEM or pure ML-DSA because it feels simpler, only to discover that any client, library, or auditor still expecting a classical fallback breaks outright. The second is underestimating the size increase: a TLS handshake that grows by roughly 1 to 1.5 KB per connection sounds trivial until it’s multiplied across millions of daily connections on a high-traffic API, where it shows up as a real, measurable bandwidth line item.

The third mistake is treating ML-KEM and ML-DSA as interchangeable, using one where the other belongs, which usually surfaces when a team tries to reuse an ML-KEM key pair for signing or vice versa. They’re built for different jobs and aren’t drop-in substitutes. The fourth, and most common according to migration write-ups from wolfSSL and other TLS library maintainers, is pinning a specific parameter set too early. Locking production traffic to ML-KEM-512 for the smallest possible footprint can leave a system under-protected if that workload later needs Category 3 or 5 assurance, and re-keying at scale is far more disruptive than choosing the right size the first time.

Pros and Cons of ML-KEM

ML-KEM’s biggest advantage is how little it disrupts existing systems. Its ciphertexts stay compact relative to ML-DSA signatures, its operations run fast even on modest hardware, and browsers, CDNs, and cloud providers have already normalized it as a TLS default. The downside is scope: ML-KEM only solves confidentiality. Deploying it alone leaves authenticity, the “is this really who it claims to be” problem, completely unaddressed, which is why it always ships alongside a signature scheme in real systems.

Pros	Cons
Fast: outperforms classical X25519 in the Demir et al. benchmark	Solves confidentiality only, not authenticity
Already the default in Chrome, Firefox, Safari, and major CDNs	Ciphertext still larger than classical ECDH, adding handshake bytes
Compact relative to ML-DSA at the same security category	Requires hybrid deployment for conservative security postures
Free to deploy on Cloudflare and most managed TLS platforms	Three parameter sets require choosing the right security/size tradeoff

Pros and Cons of ML-DSA

ML-DSA’s strength is that it closes the authenticity gap ML-KEM leaves open, with a signature scheme NIST has vetted as thoroughly as any in the standard. Its weakness shows up in the numbers: signatures run three to four times larger than ML-KEM’s ciphertexts, and signing operations take roughly eight to twelve times longer than ML-KEM’s encapsulation step, per the Demir et al. benchmark. For high-volume signing workloads, like a certificate authority issuing millions of certs, that overhead compounds quickly.

Pros	Cons
Solves authenticity, the piece ML-KEM doesn’t cover	Signatures run roughly 3x larger than ML-KEM’s ciphertext at Category 3
NIST’s recommended general-purpose PQ signature algorithm	Signing takes far longer than ML-KEM encapsulation per current benchmarks
Three parameter sets scale from lightweight to long-lived root CA use	Browser and CA default adoption still trails ML-KEM significantly
Backed by SLH-DSA as a mathematically distinct fallback if needed	Larger keys and signatures increase certificate chain size on the wire

What NIST Is Saying About the Transition

“Quantum computing technology could become a force for solving many of society’s most intractable problems, and the new standards represent NIST’s commitment to ensuring it will not simultaneously disrupt our security.”
Laurie E. Locascio, Under Secretary of Commerce for Standards and Technology and NIST Director — NIST, August 2024

“Organizations should continue to migrate their encryption systems to the standards we finalized in 2024.”
Dustin Moody, NIST mathematician and PQC project head — NIST, March 2025

“We are announcing the selection of HQC because we want to have a backup standard that is based on a different math approach than ML-KEM.”
Dustin Moody, NIST mathematician and PQC project head — NIST, March 2025

“Transition your most important items to encrypt (and remember that the most important information you need to encrypt should be replaced no later than 2035)!”
NIST official guidance, via nist.gov

Taken together, the four statements above map the real trajectory: the standards are done, the encryption side is already migrating fast through browsers and CDNs, and NIST is now pushing organizations to treat 2035 as a hard backstop for the highest-value data rather than a distant deadline.

ML-KEM vs ML-DSA: The Verdict

This isn’t really a competition, and treating it like one misses the point. ML-KEM and ML-DSA are standardized to work together, not against each other. If forced to rank urgency, ML-KEM wins on deployment priority: it’s faster, smaller, already the default in every major browser and CDN, and the data confidentiality risk it addresses (harvest now, decrypt later) is active today. Cloudflare’s own numbers back this up: 43% hybrid adoption by September 2025 and climbing, achieved without a paid tier or opt-in flag.

ML-DSA carries more weight for anything involving trust decisions that persist over time: code signing, firmware, and certificate authorities. Its larger footprint and slower signing operations (roughly 1.2 milliseconds to sign at Category 3, versus 0.1 milliseconds to encapsulate with ML-KEM-768 in the same benchmark) make it a heavier lift, which is exactly why adoption trails ML-KEM by roughly a year across the industry. The practical guidance for most teams: turn on hybrid ML-KEM key exchange this quarter if it isn’t already active, since most modern TLS stacks support it with a configuration change, and pilot ML-DSA signing on a non-critical pipeline before NIST’s post-2030 deadlines turn it into a fire drill.

Don’t wait for a mandate to force the decision. The organizations already ahead, Cloudflare, Google, Signal, Apple, moved on ML-KEM well before any regulator required it, because the harvest-now-decrypt-later risk doesn’t care about compliance timelines. ML-DSA deserves the same urgency for anything that signs code or issues certificates, even if the rollout takes longer to get right.

Frequently Asked Questions

Is ML-KEM the same thing as Kyber?

Yes. ML-KEM is the standardized name NIST gave to the CRYSTALS-Kyber submission after finalizing FIPS 203 in August 2024. Any documentation still referencing “Kyber-768” is describing the same algorithm now called ML-KEM-768.

Is ML-DSA the same thing as Dilithium?

Yes, with the same renaming pattern. CRYSTALS-Dilithium became ML-DSA under FIPS 204. Dilithium3, the version Apple used at PQ3’s 2024 launch, corresponds to ML-DSA-65.

Do I need both ML-KEM and ML-DSA, or just one?

Most production systems need both. ML-KEM secures the key exchange for a TLS session or messaging handshake, while ML-DSA authenticates the certificate or identity behind that session. Signal’s PQXDH and Apple’s PQ3 both combine a KEM for confidentiality with a signature scheme for authenticity.

Why does ML-DSA have bigger signatures than ML-KEM’s ciphertexts?

The rejection-sampling step at the core of ML-DSA’s Fiat-Shamir-with-aborts construction requires transmitting more data to preserve zero-knowledge properties and prevent key leakage. At Category 3, ML-DSA-65 produces a 3,293-byte signature versus ML-KEM-768’s 1,088-byte ciphertext, roughly a 3x gap, per the Demir et al. 2025 benchmark.

Should I run pure post-quantum, or hybrid with classical algorithms?

Hybrid, for now. Every large-scale deployment covered here, Chrome, Firefox, Cloudflare, AWS, and Apple, pairs ML-KEM or ML-DSA with a classical algorithm like X25519 or Curve25519. That keeps the connection secure even if a future flaw is found in the newer lattice-based math.

What happened to FALCON as a post-quantum signature option?

FALCON, now called FN-DSA, remains under development as a compact alternative to ML-DSA, offering smaller signatures through NTRU-lattice math. It hasn’t reached the same finalized, widely deployed status as ML-DSA and carries known implementation challenges around floating-point arithmetic and side-channel resistance.

Are ML-KEM and ML-DSA free to use?

Yes, both are open, royalty-free NIST standards. Costs only appear indirectly, through cloud KMS request pricing, dedicated HSM hardware for FIPS-validated deployments, or the extra bandwidth larger keys and signatures require.

When do RSA and ECDSA actually need to be gone?

NIST’s transition guidance points to 2035 as the target for retiring quantum-vulnerable public-key algorithms on the most sensitive systems, with earlier interim milestones already active for federal agencies. Organizations handling long-lived sensitive data should treat that as the outer bound, not the starting point.

Should I choose ML-KEM-768 or ML-KEM-1024 for my system?

ML-KEM-768 is the right default for almost everything. It’s the parameter set Chrome, Firefox, and Cloudflare have already standardized on, it maps to NIST Category 3, and it keeps handshake overhead reasonable. Reach for ML-KEM-1024 only for workloads with an explicit requirement for Category 5 assurance, such as classified government systems or data that must stay confidential for multiple decades.

Does quantum computing already threaten today’s encrypted traffic?

Not directly, since no quantum computer today can break RSA or ECC at practical key sizes. The real threat is harvest-now-decrypt-later: adversaries capturing encrypted traffic today for decryption once quantum hardware catches up. That’s why NIST frames the deadline around how long data needs to stay secret, not around a specific quantum-computer release date.

The pattern in that table matters more than any single line item. Cloudflare made the deliberate choice to give away post-quantum key agreement for free “forever,” reasoning that a security upgrade this important shouldn’t sit behind a paywall. AWS folded ML-KEM into existing KMS pricing tiers rather than inventing a new line item, though it’s worth noting ML-KEM operations bill at the “other asymmetric” rate of $0.15 per 10,000 requests, five times the $0.03 symmetric rate, because the larger keys cost more HSM compute to process. The real spend shows up if a compliance mandate forces on-premises hardware, where a PQC-capable HSM appliance can run tens of thousands of dollars more than a classical-only equivalent like the YubiHSM 2.

Certificate authorities present the murkiest pricing picture of the group. Both DigiCert and Sectigo support ML-DSA today, but neither publishes a flat per-certificate rate the way they do for classical RSA or ECDSA certs. Sectigo’s April 2026 Private PQC launch explicitly frames its no-cost tier as a way to let teams “test, evaluate, and understand the real-world impact of PQC without production risk,” which suggests the CAs themselves are still figuring out how to price certificates that cost more bandwidth and validation overhead to issue and serve.

Real-World Deployments: Who’s Using ML-KEM and ML-DSA Right Now

Neither algorithm is theoretical anymore. Six concrete rollouts show how differently the two are being adopted.

Cloudflare deployed hybrid ML-KEM key agreement across its edge network and reported that roughly 43% of human-generated connections were already protected by it as of mid-September 2025, a figure that continued climbing through 2026 (see our earlier coverage of the post-quantum adoption curve). Cloudflare’s engineering team called the rollout “included free of charge, forever.”
Google Chrome shipped X25519MLKEM768 as the standardized default hybrid key-exchange group starting with Chrome 131, released November 6, 2024, replacing the earlier pre-standard Kyber draft group entirely.
Mozilla Firefox turned on the same X25519MLKEM768 group by default for desktop HTTPS starting with Firefox 132, released around October 2024, with HTTP/3 support following in Firefox 135.
Signal became the first mainstream messaging app to ship a post-quantum key exchange, announcing PQXDH on September 19, 2023. It layers Kyber-1024 (now ML-KEM-1024) on top of the existing X3DH handshake.
Apple followed with PQ3 for iMessage, announced February 21, 2024, and rolled out with iOS 17.4, iPadOS 17.4, macOS 14.4, and watchOS 10.4. PQ3 pairs Curve25519 with Kyber-1024 for key establishment and uses Dilithium3, the pre-standardization name for ML-DSA-65, to sign the initial key exchange.
AWS extended ML-KEM support into KMS, ACM, and Secrets Manager endpoints for hybrid post-quantum TLS across all AWS regions, a rollout the company documented through 2026.

Notice the imbalance: every example above involves ML-KEM. ML-DSA’s production story is thinner so far, limited mostly to Apple’s signature step inside PQ3 and early private-certificate pilots at DigiCert and Sectigo. NIST’s own June 2026 working draft for updating federal PIV identity card standards explicitly plans to add both ML-DSA for card authentication and ML-KEM for key establishment, but as of this writing that document remains an initial working draft, not a finalized requirement. Industry guidance around that draft describes a phased rollout for federal ID cards: dual classical-plus-ML-DSA-65 certificates now, ML-DSA becoming primary sometime around 2026 to 2028, and classical algorithms dropping out entirely after 2030, a timeline that mirrors what’s already playing out on the TLS side with browsers.

Hybrid Mode: Why Almost Nobody Deploys ML-KEM or ML-DSA Alone

Every production deployment covered above runs a hybrid construction, not a pure post-quantum one. Chrome, Firefox, Cloudflare, and AWS all pair ML-KEM-768 with classical X25519, concatenating both shared secrets and folding the result through a key derivation function. The logic is conservative by design: lattice cryptography is newer and less battle-tested than elliptic curves, which have survived over two decades of public cryptanalysis. A hybrid connection stays secure as long as at least one of the two component algorithms holds, so a future break in ML-KEM wouldn’t retroactively expose traffic protected by X25519, and vice versa.

Use Cases: When to Reach for ML-KEM vs ML-DSA

TLS 1.3 web and API traffic: ML-KEM-768 in the X25519MLKEM768 hybrid group. This is the path with the most production mileage and the smallest performance hit.
VPN and IPsec tunnels: ML-KEM, following Cloudflare’s approach in its SASE and Cloudflare One products, which extended the same hybrid key agreement to IPsec at no extra cost.
Code signing and software supply chain integrity: ML-DSA-65, since verifying that a binary or update came from a trusted source is exactly the authenticity problem ML-DSA was built for.
Long-lived root certificate authorities and firmware signing: ML-DSA-87, or SLH-DSA where teams want an entirely different mathematical foundation as a hedge against a future lattice break.
Federal identity and PIV/CAC cards: a combination of both, per NIST’s June 2026 working draft, ML-DSA for card authentication signatures and ML-KEM for key establishment during login.
End-to-end encrypted messaging: ML-KEM for the session key exchange (as in Signal’s PQXDH and Apple’s PQ3), often paired with a signature scheme like ML-DSA to authenticate the initial handshake.

Migration Guide: Deploying ML-KEM and ML-DSA in Production

Inventory every TLS endpoint, VPN gateway, code-signing pipeline, and certificate authority still running classical-only RSA, ECDSA, or ECDH.
Enable hybrid key exchange first. Turning on X25519MLKEM768 at TLS termination points is the lowest-risk change, since it’s opportunistic and falls back gracefully for older clients.
Upgrade crypto libraries to versions that implement FIPS 203 and FIPS 204 natively, such as OpenSSL 3.5+, wolfSSL, or liboqs-backed builds.
Validate against NIST’s published known-answer test vectors from the Cryptographic Algorithm Validation Program before touching production traffic.
Pilot ML-DSA-65 signing on one non-critical pipeline, such as an internal code-signing or staging certificate chain, before touching customer-facing certificates.
Dual-sign certificates during the transition (classical algorithm plus ML-DSA) so verifiers without post-quantum support don’t break outright.
Roll out to production gradually while monitoring CPU load and bandwidth, since larger keys and signatures add real bytes to every handshake and every certificate chain.
Track NIST’s long-range deprecation guidance, which flags 2035 as the target date to have replaced quantum-vulnerable public-key algorithms for the most sensitive data.

A minimal OpenSSL 3.5+ example for generating keys under both standards looks like this:

# Generate an ML-KEM-768 key pair for key exchange
openssl genpkey -algorithm ML-KEM-768 -out mlkem768.key

# Generate an ML-DSA-65 key pair and a self-signed cert for signing
openssl genpkey -algorithm ML-DSA-65 -out mldsa65.key
openssl req -new -x509 -key mldsa65.key -out mldsa65.crt -days 365

# Confirm the hybrid group is active on a live TLS 1.3 connection
openssl s_client -connect example.com:443 -groups X25519MLKEM768

Common Migration Mistakes to Avoid

Pros and Cons of ML-KEM

Pros	Cons
Fast: outperforms classical X25519 in the Demir et al. benchmark	Solves confidentiality only, not authenticity
Already the default in Chrome, Firefox, Safari, and major CDNs	Ciphertext still larger than classical ECDH, adding handshake bytes
Compact relative to ML-DSA at the same security category	Requires hybrid deployment for conservative security postures
Free to deploy on Cloudflare and most managed TLS platforms	Three parameter sets require choosing the right security/size tradeoff

Pros and Cons of ML-DSA

Pros	Cons
Solves authenticity, the piece ML-KEM doesn’t cover	Signatures run roughly 3x larger than ML-KEM’s ciphertext at Category 3
NIST’s recommended general-purpose PQ signature algorithm	Signing takes far longer than ML-KEM encapsulation per current benchmarks
Three parameter sets scale from lightweight to long-lived root CA use	Browser and CA default adoption still trails ML-KEM significantly
Backed by SLH-DSA as a mathematically distinct fallback if needed	Larger keys and signatures increase certificate chain size on the wire

What NIST Is Saying About the Transition

“Quantum computing technology could become a force for solving many of society’s most intractable problems, and the new standards represent NIST’s commitment to ensuring it will not simultaneously disrupt our security.”
Laurie E. Locascio, Under Secretary of Commerce for Standards and Technology and NIST Director — NIST, August 2024

“Organizations should continue to migrate their encryption systems to the standards we finalized in 2024.”
Dustin Moody, NIST mathematician and PQC project head — NIST, March 2025

“We are announcing the selection of HQC because we want to have a backup standard that is based on a different math approach than ML-KEM.”
Dustin Moody, NIST mathematician and PQC project head — NIST, March 2025

“Transition your most important items to encrypt (and remember that the most important information you need to encrypt should be replaced no later than 2035)!”
NIST official guidance, via nist.gov

ML-KEM vs ML-DSA: The Verdict

Frequently Asked Questions

Is ML-KEM the same thing as Kyber?

Is ML-DSA the same thing as Dilithium?

Yes, with the same renaming pattern. CRYSTALS-Dilithium became ML-DSA under FIPS 204. Dilithium3, the version Apple used at PQ3’s 2024 launch, corresponds to ML-DSA-65.

Do I need both ML-KEM and ML-DSA, or just one?

Why does ML-DSA have bigger signatures than ML-KEM’s ciphertexts?

Should I run pure post-quantum, or hybrid with classical algorithms?

What happened to FALCON as a post-quantum signature option?

Are ML-KEM and ML-DSA free to use?

When do RSA and ECDSA actually need to be gone?

Should I choose ML-KEM-768 or ML-KEM-1024 for my system?

Does quantum computing already threaten today’s encrypted traffic?

Two NIST algorithms now sit at the center of every serious post-quantum migration plan. ML-KEM handles the key exchange that protects a TLS handshake. ML-DSA handles the signature that proves a certificate, a firmware update, or a piece of code actually came from who it claims. Both launched as finalized federal standards in August 2024, and by August 2026 they’ve moved from academic curiosities into production code at Cloudflare, Google, Signal, and Apple.

The confusion is understandable. The names sound alike, the underlying math (module lattices) comes from the same family, and vendors often bundle both into one “post-quantum ready” checkbox. But ML-KEM and ML-DSA solve different problems, ship in different byte sizes, and belong in different parts of a stack. This comparison breaks down the specs, the real benchmark numbers, what migration actually costs, and where each algorithm fits, plus the mistakes teams are already making in year two of rollout.

Neither algorithm showed up overnight. Both trace back to submissions in NIST’s original 2016 call for post-quantum proposals, survived three public elimination rounds against dozens of competitors, and were named among the first four winners back in July 2022. The two extra years between that announcement and the August 2024 final standards went into hardening the specifications, closing implementation gaps, and running the algorithms through public review one more time. That history matters for anyone deciding whether to trust these standards in production: this wasn’t a rushed response to a headline, it was the output of the same vetting process that produced AES and SHA-2.

What Is Post-Quantum Cryptography, and Why Two Separate Algorithms?

Post-quantum cryptography exists because of a threat called “harvest now, decrypt later.” An adversary with no working quantum computer today can still record encrypted internet traffic now and decrypt it in a decade, once a cryptographically relevant quantum computer exists. For data that needs to stay secret for years, like medical records, state secrets, or long-lived corporate IP, that threat is already live even though the quantum computer isn’t.

The National Institute of Standards and Technology ran an eight-year public competition to pick replacements for RSA and elliptic-curve cryptography, both of which fall to Shor’s algorithm on a sufficiently powerful quantum machine. On August 13, 2024, NIST finalized the first three results: FIPS 203 (ML-KEM), built from the CRYSTALS-Kyber submission, FIPS 204 (ML-DSA), built from CRYSTALS-Dilithium, and FIPS 205 (SLH-DSA), a conservative hash-based backup signature scheme derived from SPHINCS+.

NIST split the work into two standards instead of one because encryption and signatures fail differently and get used differently. A key exchange protects a session that might be recorded today and cracked years later. A signature protects a claim of authenticity made at a single point in time, like “this software update is genuine.” Bundling both jobs into one algorithm would have meant compromising on size, speed, or security margins for one use case to satisfy the other. NIST also added a second KEM, HQC, as a backup in March 2025, specifically because it rests on a different mathematical foundation (code-based, not lattice-based) than ML-KEM, in case a future attack weakens lattice assumptions.

Nobody has built a cryptographically relevant quantum computer yet, and estimates for when one might arrive still range widely across the research community, from the early 2030s to well past 2040 depending on which lab’s roadmap you trust. NIST’s guidance sidesteps the debate entirely: instead of betting on a single forecast, it tells organizations to migrate based on how long their data needs to stay secret, not on when a quantum computer might show up. A password reset token that expires in an hour doesn’t need ML-KEM protection. A state secret, a patient record, or a signing key for a decade-long infrastructure rollout does.

ML-KEM Explained: NIST’s Key Encapsulation Standard

ML-KEM, short for Module-Lattice-Based Key-Encapsulation Mechanism, does one job: it lets two parties who have never met establish a shared secret key over a channel that an attacker can read. It replaces RSA key transport and Diffie-Hellman-style key agreement, including the elliptic-curve variants used in most modern TLS deployments, such as Ed25519 pairings.

The mechanics differ from classical Diffie-Hellman. ML-KEM has three operations: key generation produces a public and private key pair, encapsulation uses the public key to produce both a ciphertext and a shared secret, and decapsulation uses the private key and that ciphertext to recover the same secret. The security rests on the Module Learning With Errors (Module-LWE) problem, a lattice problem believed to resist both classical and quantum attacks.

The Three ML-KEM Parameter Sets

FIPS 203 defines three parameter sets, tuned for different security margins. ML-KEM-512 targets NIST Category 1 (roughly equivalent to AES-128). ML-KEM-768 targets Category 3 (roughly AES-192) and is the parameter set browsers, CDNs, and cloud providers have converged on as the default. ML-KEM-1024 targets Category 5 (roughly AES-256) for workloads that need the widest security margin, at the cost of larger keys and ciphertexts. NIST’s own guidance in IR 8547 treats ML-KEM as, in its words, “the only approved post-quantum key-establishment scheme based on public key cryptography” for federal systems during the transition period.

ML-DSA Explained: NIST’s Digital Signature Standard

ML-DSA, short for Module-Lattice-Based Digital Signature Algorithm, solves a different problem: proving a message, certificate, or binary came from the holder of a specific private key and hasn’t been altered. It replaces RSA and ECDSA signatures, including the Ed25519 signatures many teams adopted over the last few years for their speed and small key size.

ML-DSA uses a construction called Fiat-Shamir with aborts, which turns an interactive identification protocol into a non-interactive signature through rejection sampling. That sampling step is deliberate: it ensures a signature leaks nothing about the private key, closing off a class of statistical attacks that plagued earlier lattice-signature attempts. The security reduces to two related hard problems, Module-LWE and Module Short Integer Solution (Module-SIS).

The Three ML-DSA Parameter Sets

FIPS 204 also ships three parameter sets. ML-DSA-44 sits at NIST Category 2 (roughly 128-bit strength). ML-DSA-65 sits at Category 3 (roughly 192-bit) and has become the default choice for certificates and code signing, mirroring ML-KEM-768’s role on the encryption side. ML-DSA-87 sits at Category 5 for long-lived signatures, such as root certificate authorities that need to stay trustworthy for decades. Apple’s PQ3 protocol for iMessage, which launched with iOS 17.4 in February 2024, uses Dilithium3 (the pre-standardization name for what became ML-DSA-65) to sign its initial key exchange.

Where SLH-DSA Fits Alongside ML-KEM and ML-DSA

A third algorithm, SLH-DSA (FIPS 205), rounds out NIST’s first wave of standards, and it’s worth understanding even though this comparison centers on the other two. SLH-DSA descends from SPHINCS+ and builds its security purely on hash functions rather than lattice math, the same category of primitive behind SHA-256 and SHA3-256. That gives it a fundamentally different risk profile from ML-DSA: hash-based signatures have decades of cryptanalysis behind them and are considered extremely conservative, but SLH-DSA signatures run far larger, often tens of kilobytes versus ML-DSA-65’s 3,293 bytes, and signing is noticeably slower.

NIST doesn’t position SLH-DSA as a competitor to ML-DSA for everyday use. It’s a deliberate hedge, a backstop for the small number of use cases, like root certificate authorities or firmware that has to remain trustworthy for thirty-plus years, where teams want a signature scheme that doesn’t share ML-DSA’s lattice-based assumptions at all. Most organizations will never touch SLH-DSA directly, since it exists so that if a future cryptanalytic breakthrough weakens lattice problems, there’s already a standardized, independently-reasoned alternative sitting on the shelf, ready to swap in without waiting on another multi-year standardization cycle.

ML-KEM vs ML-DSA: Full Specs Comparison

The table below lines up both standards side by side, using the recommended Category 3 parameter set (ML-KEM-768 and ML-DSA-65) as the default comparison point, since that’s what most production deployments use today.

Attribute	ML-KEM	ML-DSA
FIPS standard	FIPS 203	FIPS 204
Predecessor algorithm	CRYSTALS-Kyber	CRYSTALS-Dilithium
Function	Key Encapsulation Mechanism (KEM)	Digital Signature Algorithm
What it protects	Confidentiality (shared secret)	Authenticity and integrity
Hard math problem	Module-LWE	Module-LWE + Module-SIS
Finalized	August 13, 2024	August 13, 2024
Parameter sets	ML-KEM-512 / 768 / 1024	ML-DSA-44 / 65 / 87
Default/recommended set	ML-KEM-768 (Category 3)	ML-DSA-65 (Category 3)
Public key size (default)	1,184 bytes	1,952 bytes
Secret key size (default)	2,400 bytes	4,032 bytes
Output size (default)	1,088 bytes (ciphertext)	3,293 bytes (signature)
Typical deployment	TLS handshake, VPN tunnels, cloud KMS	Code signing, cert signing, federal ID cards
Browser default group	X25519MLKEM768 (Chrome, Firefox, Safari)	Not yet default for TLS certificates

Two things jump out. First, ML-DSA’s keys and outputs run noticeably larger than ML-KEM’s at the same security category, roughly 1.6x on public keys and 3x on the signature versus ciphertext. That size gap matters more than it sounds, because ML-DSA signatures land in every TLS certificate chain and every code-signing manifest, multiplying their footprint across millions of files. Second, browsers have already standardized on the hybrid group X25519MLKEM768 for key exchange, while no browser treats ML-DSA as a default certificate algorithm yet. Encryption migrated first because it’s the easier lift.

Benchmark Data: How Fast Are ML-KEM and ML-DSA in Practice?

Independent benchmarks agree on the broad shape of the performance gap, even when exact numbers vary by CPU and implementation. A 2025 academic benchmark by Demir et al., cited in a 2026 post-quantum survey on arXiv, measured both algorithms across their standardized parameter sets on the same hardware.

Algorithm	KeyGen (ms)	Encaps / Sign (ms)	Decaps / Verify (ms)	Public Key	Ciphertext / Signature
ML-KEM-512	0.253	0.070	0.084	800 B	768 B
ML-KEM-768	0.354	0.095	0.118	1,184 B	1,088 B
ML-KEM-1024	0.483	0.138	0.159	1,568 B	1,568 B
ML-DSA-44	0.253	0.840	0.267	1,312 B	2,420 B
ML-DSA-65	0.392	1.205	0.398	1,952 B	3,293 B
ML-DSA-87	0.652	1.998	0.584	2,592 B	4,595 B

Source: Demir et al. 2025 benchmark, as cited in the 2026 arXiv post-quantum cryptography survey. Reported timings are per-operation on the study’s reference hardware and are best read as relative comparisons between algorithms, not absolute numbers for every deployment.

The pattern holds across every parameter set: signing with ML-DSA takes roughly eight to twelve times longer than encapsulating with ML-KEM at a comparable security level, and verification runs two to three times slower than decapsulation. That’s the expected cost of the rejection-sampling step baked into ML-DSA’s design. The same survey paper notes that ML-KEM-512 executes about three times faster than classical X25519 elliptic-curve Diffie-Hellman, which explains why encryption-side migration hasn’t caused the performance panic some early pilots feared.

A second data point comes from a 2025 Frontiers in Physics paper on authenticated post-quantum session setup, which found that a full session combining ML-KEM-1024 and ML-DSA-65, key exchange plus signature verification together, completes in roughly 0.5 to 0.7 milliseconds on commodity CPUs. A third source, a performance evaluation published via DergiPark, corroborates the same directional finding: ML-DSA’s signing and verification operations consume more CPU than ML-KEM’s encapsulation and decapsulation, a gap the authors attribute directly to the difference in cryptographic purpose between confidentiality and authenticity.

Pricing and the Real Cost of Migration

Both algorithms are open, royalty-free NIST standards, so there’s no license fee for using ML-KEM or ML-DSA themselves. The cost shows up in infrastructure: bigger keys and signatures mean more bandwidth and storage, and hardware security modules capable of running these algorithms in FIPS-validated firmware carry a real price tag.

Deployment path	Vendor	Cost	PQC included?
Managed cloud key (KMS)	AWS KMS	$1/month per key, plus $0.15 per 10,000 asymmetric requests (ML-KEM billed as “other asymmetric”)	Yes, no separate PQC surcharge
Dedicated cloud HSM	AWS CloudHSM	≈$1.60/hour per instance, about $1,152/month	Yes, via Luna PQC firmware
Edge/CDN TLS termination	Cloudflare	$0/month on the Free plan through custom Enterprise pricing	Yes, included free on every plan
Enterprise HSM appliance	Thales Luna Network HSM	No official public price; third-party estimates start around $75,000+	Yes, ML-KEM-768 and ML-DSA-65 in firmware
Mid-market HSM appliance	Utimaco CryptoServer PQC	Third-party listing starts around $25,000	Yes, via Quantum Protect firmware
Classical-only HSM (for contrast)	YubiHSM 2	$650 to $950 per device	No, no ML-KEM/ML-DSA support as of this writing
Private PQC certificates	DigiCert Trust Lifecycle Manager	Custom enterprise pricing, no public per-certificate rate	Yes, ML-DSA-44/65/87
PQC certificate testing	Sectigo Private PQC (launched April 2026)	No cost for the testing tier inside Sectigo Certificate Manager	Yes, ML-DSA-44/65/87
Open-source TLS stack	OpenSSL 3.5+	Free, open source	Yes, both algorithms supported natively

Real-World Deployments: Who’s Using ML-KEM and ML-DSA Right Now

Neither algorithm is theoretical anymore. Six concrete rollouts show how differently the two are being adopted.

Cloudflare deployed hybrid ML-KEM key agreement across its edge network and reported that roughly 43% of human-generated connections were already protected by it as of mid-September 2025, a figure that continued climbing through 2026 (see our earlier coverage of the post-quantum adoption curve). Cloudflare’s engineering team called the rollout “included free of charge, forever.”
Google Chrome shipped X25519MLKEM768 as the standardized default hybrid key-exchange group starting with Chrome 131, released November 6, 2024, replacing the earlier pre-standard Kyber draft group entirely.
Mozilla Firefox turned on the same X25519MLKEM768 group by default for desktop HTTPS starting with Firefox 132, released around October 2024, with HTTP/3 support following in Firefox 135.
Signal became the first mainstream messaging app to ship a post-quantum key exchange, announcing PQXDH on September 19, 2023. It layers Kyber-1024 (now ML-KEM-1024) on top of the existing X3DH handshake.
Apple followed with PQ3 for iMessage, announced February 21, 2024, and rolled out with iOS 17.4, iPadOS 17.4, macOS 14.4, and watchOS 10.4. PQ3 pairs Curve25519 with Kyber-1024 for key establishment and uses Dilithium3, the pre-standardization name for ML-DSA-65, to sign the initial key exchange.
AWS extended ML-KEM support into KMS, ACM, and Secrets Manager endpoints for hybrid post-quantum TLS across all AWS regions, a rollout the company documented through 2026.

Hybrid Mode: Why Almost Nobody Deploys ML-KEM or ML-DSA Alone

Use Cases: When to Reach for ML-KEM vs ML-DSA

TLS 1.3 web and API traffic: ML-KEM-768 in the X25519MLKEM768 hybrid group. This is the path with the most production mileage and the smallest performance hit.
VPN and IPsec tunnels: ML-KEM, following Cloudflare’s approach in its SASE and Cloudflare One products, which extended the same hybrid key agreement to IPsec at no extra cost.
Code signing and software supply chain integrity: ML-DSA-65, since verifying that a binary or update came from a trusted source is exactly the authenticity problem ML-DSA was built for.
Long-lived root certificate authorities and firmware signing: ML-DSA-87, or SLH-DSA where teams want an entirely different mathematical foundation as a hedge against a future lattice break.
Federal identity and PIV/CAC cards: a combination of both, per NIST’s June 2026 working draft, ML-DSA for card authentication signatures and ML-KEM for key establishment during login.
End-to-end encrypted messaging: ML-KEM for the session key exchange (as in Signal’s PQXDH and Apple’s PQ3), often paired with a signature scheme like ML-DSA to authenticate the initial handshake.

Migration Guide: Deploying ML-KEM and ML-DSA in Production

Inventory every TLS endpoint, VPN gateway, code-signing pipeline, and certificate authority still running classical-only RSA, ECDSA, or ECDH.
Enable hybrid key exchange first. Turning on X25519MLKEM768 at TLS termination points is the lowest-risk change, since it’s opportunistic and falls back gracefully for older clients.
Upgrade crypto libraries to versions that implement FIPS 203 and FIPS 204 natively, such as OpenSSL 3.5+, wolfSSL, or liboqs-backed builds.
Validate against NIST’s published known-answer test vectors from the Cryptographic Algorithm Validation Program before touching production traffic.
Pilot ML-DSA-65 signing on one non-critical pipeline, such as an internal code-signing or staging certificate chain, before touching customer-facing certificates.
Dual-sign certificates during the transition (classical algorithm plus ML-DSA) so verifiers without post-quantum support don’t break outright.
Roll out to production gradually while monitoring CPU load and bandwidth, since larger keys and signatures add real bytes to every handshake and every certificate chain.
Track NIST’s long-range deprecation guidance, which flags 2035 as the target date to have replaced quantum-vulnerable public-key algorithms for the most sensitive data.

A minimal OpenSSL 3.5+ example for generating keys under both standards looks like this:

# Generate an ML-KEM-768 key pair for key exchange
openssl genpkey -algorithm ML-KEM-768 -out mlkem768.key

# Generate an ML-DSA-65 key pair and a self-signed cert for signing
openssl genpkey -algorithm ML-DSA-65 -out mldsa65.key
openssl req -new -x509 -key mldsa65.key -out mldsa65.crt -days 365

# Confirm the hybrid group is active on a live TLS 1.3 connection
openssl s_client -connect example.com:443 -groups X25519MLKEM768

Common Migration Mistakes to Avoid

Pros and Cons of ML-KEM

Pros	Cons
Fast: outperforms classical X25519 in the Demir et al. benchmark	Solves confidentiality only, not authenticity
Already the default in Chrome, Firefox, Safari, and major CDNs	Ciphertext still larger than classical ECDH, adding handshake bytes
Compact relative to ML-DSA at the same security category	Requires hybrid deployment for conservative security postures
Free to deploy on Cloudflare and most managed TLS platforms	Three parameter sets require choosing the right security/size tradeoff

Pros and Cons of ML-DSA

Pros	Cons
Solves authenticity, the piece ML-KEM doesn’t cover	Signatures run roughly 3x larger than ML-KEM’s ciphertext at Category 3
NIST’s recommended general-purpose PQ signature algorithm	Signing takes far longer than ML-KEM encapsulation per current benchmarks
Three parameter sets scale from lightweight to long-lived root CA use	Browser and CA default adoption still trails ML-KEM significantly
Backed by SLH-DSA as a mathematically distinct fallback if needed	Larger keys and signatures increase certificate chain size on the wire

What NIST Is Saying About the Transition

“Quantum computing technology could become a force for solving many of society’s most intractable problems, and the new standards represent NIST’s commitment to ensuring it will not simultaneously disrupt our security.”
Laurie E. Locascio, Under Secretary of Commerce for Standards and Technology and NIST Director — NIST, August 2024

“Organizations should continue to migrate their encryption systems to the standards we finalized in 2024.”
Dustin Moody, NIST mathematician and PQC project head — NIST, March 2025

“We are announcing the selection of HQC because we want to have a backup standard that is based on a different math approach than ML-KEM.”
Dustin Moody, NIST mathematician and PQC project head — NIST, March 2025

“Transition your most important items to encrypt (and remember that the most important information you need to encrypt should be replaced no later than 2035)!”
NIST official guidance, via nist.gov

ML-KEM vs ML-DSA: The Verdict

Frequently Asked Questions

Is ML-KEM the same thing as Kyber?

Is ML-DSA the same thing as Dilithium?

Yes, with the same renaming pattern. CRYSTALS-Dilithium became ML-DSA under FIPS 204. Dilithium3, the version Apple used at PQ3’s 2024 launch, corresponds to ML-DSA-65.

ML-KEM vs ML-DSA: 1,088 vs 3,293 Bytes [2026]

Use Cases: When to Reach for ML-KEM vs ML-DSA

Migration Guide: Deploying ML-KEM and ML-DSA in Production

Common Migration Mistakes to Avoid

Pros and Cons of ML-KEM

Pros and Cons of ML-DSA

What NIST Is Saying About the Transition

ML-KEM vs ML-DSA: The Verdict

Frequently Asked Questions

Is ML-KEM the same thing as Kyber?

Is ML-DSA the same thing as Dilithium?

Do I need both ML-KEM and ML-DSA, or just one?

Why does ML-DSA have bigger signatures than ML-KEM’s ciphertexts?

Should I run pure post-quantum, or hybrid with classical algorithms?

What happened to FALCON as a post-quantum signature option?

Are ML-KEM and ML-DSA free to use?

When do RSA and ECDSA actually need to be gone?

Should I choose ML-KEM-768 or ML-KEM-1024 for my system?

Does quantum computing already threaten today’s encrypted traffic?

Related Coverage

Real-World Deployments: Who’s Using ML-KEM and ML-DSA Right Now

Hybrid Mode: Why Almost Nobody Deploys ML-KEM or ML-DSA Alone

Use Cases: When to Reach for ML-KEM vs ML-DSA

Migration Guide: Deploying ML-KEM and ML-DSA in Production

Common Migration Mistakes to Avoid

Pros and Cons of ML-KEM

Pros and Cons of ML-DSA

What NIST Is Saying About the Transition

ML-KEM vs ML-DSA: The Verdict

Frequently Asked Questions

Is ML-KEM the same thing as Kyber?

Is ML-DSA the same thing as Dilithium?

Do I need both ML-KEM and ML-DSA, or just one?

Why does ML-DSA have bigger signatures than ML-KEM’s ciphertexts?

Should I run pure post-quantum, or hybrid with classical algorithms?

What happened to FALCON as a post-quantum signature option?

Are ML-KEM and ML-DSA free to use?

When do RSA and ECDSA actually need to be gone?

Should I choose ML-KEM-768 or ML-KEM-1024 for my system?

Does quantum computing already threaten today’s encrypted traffic?

Related Coverage

What Is Post-Quantum Cryptography, and Why Two Separate Algorithms?

ML-KEM Explained: NIST’s Key Encapsulation Standard

The Three ML-KEM Parameter Sets

ML-DSA Explained: NIST’s Digital Signature Standard

The Three ML-DSA Parameter Sets

Where SLH-DSA Fits Alongside ML-KEM and ML-DSA

ML-KEM vs ML-DSA: Full Specs Comparison

Benchmark Data: How Fast Are ML-KEM and ML-DSA in Practice?

Pricing and the Real Cost of Migration

Real-World Deployments: Who’s Using ML-KEM and ML-DSA Right Now

Hybrid Mode: Why Almost Nobody Deploys ML-KEM or ML-DSA Alone

Use Cases: When to Reach for ML-KEM vs ML-DSA

Migration Guide: Deploying ML-KEM and ML-DSA in Production

Common Migration Mistakes to Avoid

Pros and Cons of ML-KEM

Pros and Cons of ML-DSA

What NIST Is Saying About the Transition

ML-KEM vs ML-DSA: The Verdict

Frequently Asked Questions

Is ML-KEM the same thing as Kyber?

Is ML-DSA the same thing as Dilithium?

Do I need both ML-KEM and ML-DSA, or just one?

Why does ML-DSA have bigger signatures than ML-KEM’s ciphertexts?

Should I run pure post-quantum, or hybrid with classical algorithms?

What happened to FALCON as a post-quantum signature option?

Are ML-KEM and ML-DSA free to use?

When do RSA and ECDSA actually need to be gone?

Should I choose ML-KEM-768 or ML-KEM-1024 for my system?

Does quantum computing already threaten today’s encrypted traffic?

Related Coverage

Latest news