RSA and elliptic curve cryptography have carried the internet’s encrypted traffic for three decades. That era now has an expiration date. NIST finalized three post-quantum cryptography standards in August 2024, and by October 2026 those standards, ML-KEM, ML-DSA, and SLH-DSA, are no longer theoretical. Cloudflare reports that roughly 70 percent of browser-generated traffic reaching its network already negotiates a post-quantum hybrid key exchange, and the clock on replacing RSA-2048 and ECC P-256 is now a matter of federal deadlines rather than academic debate.
Picking the right algorithm is not a single decision. ML-KEM, ML-DSA, and SLH-DSA solve different problems, carry very different size and speed trade-offs, and are landing in production at different speeds. This comparison lines up the three finalized NIST standards (plus the still-draft FN-DSA) side by side: exact key and signature sizes, benchmark data from three independent sources, who has actually shipped what in 2025 and 2026, what migration will cost in bandwidth and compute, and which algorithm fits which real-world job. The goal is a decision you can act on, not another explainer that stops at “post-quantum is coming.”
What ML-KEM, ML-DSA, and SLH-DSA Actually Do
The three NIST post-quantum cryptography standards are not interchangeable, and that is the first thing most coverage of “post-quantum encryption” glosses over. ML-KEM, standardized as FIPS 203, is a key encapsulation mechanism. It does the same job classical Diffie-Hellman and elliptic curve Diffie-Hellman (ECDHE) do today: letting two parties agree on a shared secret over an untrusted channel, typically to kick off a TLS session. ML-DSA, standardized as FIPS 204 and built on the CRYSTALS-Dilithium lattice scheme, is a general-purpose digital signature algorithm meant to replace RSA signatures and ECDSA across certificates, code signing, and document signing.
SLH-DSA, standardized as FIPS 205 and derived from SPHINCS+, is also a signature scheme, but it takes a different mathematical bet. Where ML-DSA relies on the hardness of lattice problems, SLH-DSA relies only on the security of hash functions, an approach cryptographers consider more conservative because hash-based security has survived decades of scrutiny. NIST standardized SLH-DSA explicitly as a backup in case unexpected weaknesses are ever found in lattice-based schemes. A fourth algorithm, FN-DSA (draft FIPS 206, based on the Falcon signature scheme), is still working through NIST’s standardization process. According to wolfSSL’s own account of its implementation work, an Initial Public Draft of FIPS 206 had not yet been published as of the most recent 2026 reporting, so any FN-DSA figures below should be read as pre-standardization reference numbers rather than finalized specifications.
That three-way split matters because a lot of “post-quantum cryptography” coverage treats it as one undifferentiated upgrade. In practice, a TLS handshake needs ML-KEM, not ML-DSA. A certificate authority signing a certificate needs ML-DSA or SLH-DSA. A firmware vendor worried about long-term hash-function risk might deliberately choose the slower, larger SLH-DSA over the faster ML-DSA. None of these are drop-in replacements for each other, which is exactly why a side-by-side comparison, rather than three separate explainers, is the more useful format here.
It also helps to understand why NIST ended up with three separate standards instead of one. The agency ran its post-quantum cryptography competition for roughly eight years, evaluating dozens of candidate algorithms against both mathematical soundness and real-world deployability before finalizing ML-KEM, ML-DSA, and SLH-DSA in August 2024. Rather than pick a single winner, NIST deliberately standardized algorithms built on two different hard-math problems, lattice problems for ML-KEM and ML-DSA, and hash-function security for SLH-DSA, specifically so that a future weakness discovered in one mathematical family would not leave every deployed system exposed at once. That design choice is the reason this comparison has three main subjects instead of one, and it is also why choosing “the best” algorithm in isolation misses the point of how NIST intended them to be used together.
Key and Signature Sizes Compared
Size is where the three NIST algorithms diverge most sharply, and it is the single biggest practical driver of where each one gets deployed. ML-KEM keeps ciphertexts in the low kilobyte range across all three security levels, which is why it slots into TLS handshakes without much friction. ML-DSA signatures run several times larger than a classical ECDSA signature but stay small enough for routine use in certificates and protocol messages. SLH-DSA is the outlier: its hash-based construction produces signatures that run from roughly 7.8 kilobytes up to nearly 30 kilobytes, two to three orders of magnitude larger than the roughly 70-byte ECDSA P-256 signature it is meant to eventually replace in conservative deployments.
| Algorithm | FIPS standard | NIST security level | Public key (bytes) | Private key (bytes) | Signature / ciphertext (bytes) | Primary function |
|---|---|---|---|---|---|---|
| ML-KEM-512 | FIPS 203 | Level 1 | 800 | 1,632 | 768 (ciphertext) | Key exchange |
| ML-KEM-768 | FIPS 203 | Level 3 | 1,184 | 2,400 | 1,088 (ciphertext) | Key exchange |
| ML-KEM-1024 | FIPS 203 | Level 5 | 1,568 | 3,168 | 1,568 (ciphertext) | Key exchange |
| ML-DSA-44 | FIPS 204 | Level 2 | 1,312 | 2,560 | 2,420 (signature) | Digital signature |
| ML-DSA-65 | FIPS 204 | Level 3 | 1,952 | 4,032 | 3,309 (signature) | Digital signature |
| ML-DSA-87 | FIPS 204 | Level 5 | 2,592 | 4,896 | 4,627 (signature) | Digital signature |
| SLH-DSA-SHA2-128s | FIPS 205 | Level 1 | 32 | 64 | 7,856 (signature) | Hash-based signature |
| SLH-DSA-SHA2-128f | FIPS 205 | Level 1 | 32 | 64 | 17,088 (signature) | Hash-based signature, fast variant |
| SLH-DSA-SHA2-192s | FIPS 205 | Level 3 | 48 | 96 | 16,224 (signature) | Hash-based signature |
| SLH-DSA-SHA2-256s | FIPS 205 | Level 5 | 64 | 128 | 29,792 (signature) | Hash-based signature |
| FN-DSA-512 (Falcon, draft) | Draft FIPS 206 | Level 1 | 897 | Pending finalization | ~666 (signature, avg.) | Compact signature, not yet standardized |
| FN-DSA-1024 (Falcon, draft) | Draft FIPS 206 | Level 5 | 1,793 | Pending finalization | ~1,280 (signature, avg.) | Compact signature, not yet standardized |
| RSA-2048 (classical baseline) | Not PQC | ~112-bit | 256 | 256 | 256 (signature) | Classical key exchange / signature |
| ECC P-256 (classical baseline) | Not PQC | ~128-bit | 64 | 32 | ~70 (signature) | Classical key exchange / signature |
One figure worth flagging on its own: a direct comparison between Falcon-512 and ML-DSA-65, cited in current PQC literature, puts Falcon-512’s signature at 666 bytes against ML-DSA-65’s 3,309 bytes. That looks like a clear win for the draft FN-DSA scheme, but the two operate at different NIST security levels (Falcon-512 at Level 1, ML-DSA-65 at Level 3), so the comparison is not apples to apples. It is a useful reminder that raw byte counts only tell part of the story. Matching security level matters as much as matching algorithm family when you are actually choosing between options.
Performance Benchmarks: Speed and Energy Across Hardware
Byte sizes only tell you about bandwidth and storage. The harder question for most teams is how these algorithms behave on real silicon, and here the data gets more interesting than a simple “PQC is slower” headline would suggest. A 2026 energy-consumption study built on OpenSSL 3.5 found that ML-KEM and ML-DSA are broadly comparable to elliptic curve cryptography in both speed and energy draw across the architectures tested, which undercuts the assumption that lattice-based math is inherently expensive. The same cannot be said for SLH-DSA: the study reported that SLH-DSA signing energy on 32-bit devices can run up to 243 percent higher than on equivalent 64-bit hardware, a gap large enough to rule it out for battery-constrained 32-bit deployments in anything but low-frequency signing roles.
Constrained-hardware testing backs up the same pattern from a different angle. A 2026 evaluation on the ESP32-C6, a widely used low-power microcontroller, found that running ML-KEM and ML-DSA together for a complete post-quantum communication workflow is feasible without external memory, and that available RAM, not raw execution time, was the binding constraint. Separately, a benchmark run on the STM32F4 Cortex-M4, a common embedded target with roughly 100 kilobytes of working RAM, found ML-KEM-512 and ML-KEM-768 suitable for key exchange in that memory class, and found ML-DSA-44 feasible on the same constrained hardware. Every ML-KEM and ML-DSA variant the researchers tested came back feasible within its respective hardware category.
Put those two findings next to the classical baseline and the picture sharpens. Independent TLS benchmarking of RSA-2048 against ECDSA P-256 reported RSA validation times of 1.2 to 2.5 milliseconds versus 0.2 to 0.35 milliseconds for ECDSA, a four-to-twelvefold gap favoring elliptic curves on classical hardware. ML-KEM and ML-DSA land close enough to that ECC baseline that most TLS deployments will not notice the switch at the application layer. SLH-DSA is the exception that proves the rule: its energy and signing-time costs are real enough that NIST deliberately positioned it as a backup signature scheme rather than a default, reserving it for cases where hash-based conservatism is worth paying for in CPU cycles.
Real-World Deployments: Who Is Using What in 2026
Adoption data is where the three algorithms split furthest apart, because right now this is overwhelmingly a key-exchange migration, not a signature migration. Cloudflare’s own measurement, published on its blog, reports that approximately 70 percent of browser-generated traffic reaching its network uses hybrid post-quantum key agreement, almost entirely through the X25519MLKEM768 hybrid group combining classical X25519 with ML-KEM-768. On the origin side, the picture is much earlier: Cloudflare reports that only around 15 percent of origin servers it connects to support hybrid ML-KEM, up from roughly 0.5 percent in 2023. That gap, strong client-side adoption against weak server-side adoption, is the clearest signal available right now about where PQC migration actually stands.
Google Chrome has been rolling out the same X25519MLKEM768 hybrid mechanism progressively since 2024, and it is a large share of the traffic Cloudflare is measuring on the client side. Apple’s iMessage added a post-quantum key establishment layer called PQ3 in February 2024, built on the Kyber lattice scheme that became the basis for standardized ML-KEM, though Apple has not published primary documentation confirming the deployed code matches the final FIPS 203 specification byte-for-byte. Signal shipped its own post-quantum addition, PQXDH, in 2023, also built on CRYSTALS-Kyber, layered alongside its classical X3DH key agreement rather than replacing it outright.
On the signature side, deployment is thinner. Microsoft’s SymCrypt cryptographic library reportedly added ML-KEM and ML-DSA support across Azure, Microsoft 365, Windows 11, and Windows Server 2025 following a November 2025 update, though that claim rests on secondary reporting rather than Microsoft’s own primary documentation. Certificate authorities are still earlier in the process: Sectigo restructured its certificate hierarchy in 2025, moving new public server certificates onto dedicated RSA and ECC roots (R46 for RSA, E46 for ECC, with R36 and E36 intermediates), rolling EV certificates onto the new hierarchy in April 2025 and OV certificates in May 2025. That is a sign of active PKI housekeeping ahead of a post-quantum transition, but it is not yet evidence of ML-DSA or SLH-DSA certificates shipping in production. wolfSSL’s WolfCrypt library added native Falcon-512 and Falcon-1024 support specifically in anticipation of FN-DSA standardization, explicitly flagging its own API as provisional until FIPS 206 is finalized.
Migration Cost: Bandwidth, Compute, and Certificate Overhead
None of these algorithms carry a licensing fee the way a commercial product might, so the real “price” of migration shows up in bandwidth, certificate-chain size, and compute budget. That cost is uneven across the three standards, and it is the main reason organizations are sequencing their rollouts (key exchange first, signatures later) rather than flipping everything at once.
| Migration step | Classical baseline | Post-quantum replacement | Size increase | Reported compute / energy impact |
|---|---|---|---|---|
| TLS key exchange | ECDHE X25519 (32-byte key) | Hybrid X25519 + ML-KEM-768 | +1,088-byte ciphertext | Broadly comparable speed and energy to ECC (OpenSSL 3.5 study) |
| TLS certificate signature | RSA-2048 (256-byte signature) | ML-DSA-65 (3,309-byte signature) | ~13x larger per signature | No meaningful internet-scale latency increase reported from PQ-TLS deployments |
| Conservative / archival signature | ECDSA P-256 (~70-byte signature) | SLH-DSA-SHA2-128s (7,856-byte signature) | ~112x larger | Signing energy up to 243% higher on 32-bit vs. 64-bit hardware |
| Compact draft signature | RSA-2048 (256-byte signature) | FN-DSA-512 / Falcon (~666-byte signature) | ~2.6x larger | Smallest PQ signature tested, but pre-standardization |
| Constrained IoT device | Classical ECC stack | ML-KEM-512 + ML-DSA-44 on Cortex-M4 / ESP32-C6 | Varies by payload | Feasible without external memory. RAM is the binding constraint, not CPU time |
The headline takeaway from that table is that ML-KEM is close to a free upgrade in bandwidth terms, which is exactly why it has the highest real-world adoption of the three. ML-DSA’s signature growth is noticeable in certificate chains and handshake size but has not translated into measurable latency problems at internet scale, according to current PQ-TLS deployment studies. SLH-DSA is the expensive option by every metric in that table, which is a deliberate trade NIST built in: you pay in bytes and energy for the conservative security assumption that hash-based signatures do not depend on lattice-problem hardness holding up indefinitely.
NIST and CNSA 2.0 Migration Timelines
Two overlapping but distinct deadline regimes are driving urgency here, and conflating them is a common source of confusion. NIST’s own transition guidance targets RSA-2048 and ECC P-256 for deprecation starting in 2030 and full disallowance by 2035. Separately, the NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) sets its own schedule for systems that touch U.S. national security: CNSA 2.0 algorithms should be preferred starting in 2030, and applicable national-security systems must use CNSA 2.0 algorithms exclusively by 2033.
| Milestone | Governing body | Deadline | What it requires |
|---|---|---|---|
| RSA/ECC deprecation begins | NIST | 2030 | Phase out RSA-2048 and ECC P-256 in new systems and products |
| CNSA 2.0 algorithms preferred | NSA | 2030 | National security systems should default to post-quantum algorithms |
| Federal post-quantum key establishment | Federal transition guidance | December 31, 2030 | ML-KEM required in federal high-value and high-impact systems |
| Federal post-quantum signatures | Federal transition guidance | December 31, 2031 | ML-DSA or SLH-DSA required in the same class of federal systems |
| CNSA 2.0 exclusive use | NSA | 2033 | Applicable national-security systems must use only CNSA 2.0 algorithms |
| RSA/ECC full disallowance | NIST | 2035 | RSA-2048 and ECC P-256 no longer permitted at all |
For most organizations outside government and defense contracting, the NIST 2030-to-2035 window is the one that matters. Nine years sounds comfortable until you account for how long certificate authority ecosystems, embedded firmware fleets, and legacy client software actually take to turn over. The NIST National Cybersecurity Center of Excellence guidance is explicit that all three standards can be implemented today, and its advice is to start planning and deploying now rather than waiting for the deadline to get closer.
Which Algorithm Replaces What
Mapping each NIST standard to the classical mechanism it is meant to replace clears up most of the confusion around “which post-quantum algorithm do I need.” ML-KEM is the replacement for RSA key transport and for ECDH/ECDHE key agreement wherever a session needs a shared secret. It is not a signature scheme and cannot sign anything. ML-DSA is the default replacement for RSA signatures and ECDSA, intended for the bulk of certificate signing, code signing, and document signing that currently relies on classical public-key signatures. SLH-DSA sits one layer below ML-DSA as a deliberately different mathematical approach, meant for situations where an organization wants signature security that does not depend on lattice-problem assumptions at all, accepting the size and energy penalty in exchange for that independence.
FN-DSA, once finalized as FIPS 206, is expected to serve as a compact alternative to ML-DSA for situations where signature size matters more than anything else, such as constrained devices or protocols with strict message-size budgets. Until that draft is finalized, treating it as production-ready is premature no matter how attractive its 666-byte Falcon-512 signature looks next to ML-DSA-65’s 3,309 bytes. wolfSSL’s own messaging around its Falcon support underscores this: the library added the capability specifically to be ready once FIPS 206 lands, not because the standard is settled.
Pros and Cons of Each Algorithm
Each of the three finalized standards earns its place in a migration plan for different reasons, and each comes with a real limitation worth weighing before deployment.
- ML-KEM: Small ciphertexts, speed comparable to classical ECC, the most mature real-world deployment data of the three, and it is already the default hybrid choice for Cloudflare, Chrome, and major browser vendors. Its limitation is scope, it only solves key exchange, so every signature use case still needs ML-DSA or SLH-DSA alongside it.
- ML-DSA: General-purpose, fast enough for most TLS and PKI workloads, and backed by the largest ecosystem of early library support. Its limitation is signature size, which runs two to nineteen times larger than classical ECDSA depending on the parameter set, inflating certificate chains and handshake bytes.
- SLH-DSA: The most conservative security assumption of the three, resting only on hash-function hardness rather than a newer lattice problem. Its limitation is cost: signatures run up to roughly 112 times larger than ECDSA, and signing energy can run up to 243 percent higher on 32-bit hardware, making it a poor fit for high-frequency or battery-constrained signing.
- FN-DSA (draft): The smallest post-quantum signature size of the group by a wide margin, which makes it attractive for constrained environments. Its limitation is maturity: FIPS 206 has not cleared even an Initial Public Draft as of the most recent 2026 reporting, so production deployment today means committing to a moving target.
Use-Case Recommendations
The right algorithm choice depends heavily on what you are actually protecting and what hardware it runs on. Here is how the decision tends to play out across common scenarios.
- Public-facing web servers and APIs: Deploy hybrid ML-KEM (X25519MLKEM768) for TLS key exchange first, since it carries the lowest overhead and the most mature browser support. This is the single highest-leverage move available right now, matching what Cloudflare and Chrome have already rolled out at scale.
- Certificate authorities and PKI operators: Plan ML-DSA as the primary signature replacement for RSA and ECDSA certificates, while tracking certificate authority root restructuring (as Sectigo has already done with dedicated RSA and ECC roots) as the template for an eventual ML-DSA root rollout.
- Long-term document archival and legal signatures: Consider SLH-DSA despite its size penalty, specifically because documents that must remain verifiable decades from now benefit more from hash-based conservatism than from ML-DSA’s smaller footprint.
- Constrained IoT and embedded firmware: Pair ML-KEM-512 with ML-DSA-44, following the pattern validated on Cortex-M4 and ESP32-C6 hardware, and budget for RAM headroom rather than CPU headroom, since memory availability was the binding constraint in both cited 2026 hardware evaluations.
- Messaging and real-time communication: Follow the Signal and Apple iMessage pattern of layering a Kyber-derived post-quantum key agreement alongside existing classical key exchange rather than replacing it outright, preserving a fallback path while the ecosystem matures.
- National security and defense-adjacent systems: Align directly to the CNSA 2.0 timeline (preferred by 2030, exclusive by 2033) rather than the longer NIST 2035 window, since that schedule is the one that will actually be audited for these systems.
Common Pitfalls When Migrating to Post-Quantum Cryptography
Most of the mistakes teams make during a post-quantum rollout are not cryptographic at all, they are operational. The biggest one is treating “post-quantum migration” as a single checkbox rather than the three-track problem it actually is: key exchange, signatures, and long-term data confidentiality each move on their own schedule and carry their own risk profile. A team that enables hybrid ML-KEM on its load balancer and calls the project done has solved roughly a third of the problem, the part Cloudflare’s 70 percent browser-traffic figure already reflects industry-wide, while leaving certificate signing and archival data exactly as exposed as before.
A second common pitfall is underestimating the knock-on effect of larger signatures on systems that were never designed around byte budgets. Legacy firmware update mechanisms, embedded TLS stacks, and older load balancer configurations frequently hard-code assumptions about certificate chain size or handshake packet counts that were safe in an RSA-2048 or ECDSA world and break once a chain grows by the kind of multiple ML-DSA or SLH-DSA introduces. Testing against real hardware and real network paths, not just a local development certificate, catches this earlier than most teams expect to need it.
A third pitfall is choosing SLH-DSA by default because it sounds like the “safer” option on paper. Its hash-based construction is genuinely more conservative, but defaulting to a signature scheme that costs up to 112 times more bytes and up to 243 percent more signing energy on 32-bit hardware, without a specific reason to need that conservatism, is a self-inflicted performance problem. ML-DSA is the better default for the overwhelming majority of signature use cases. SLH-DSA is a deliberate choice for specific risk tolerances, not a safer-by-default upgrade path.
Finally, teams planning around FN-DSA too early tend to build assumptions into procurement contracts, vendor requirements, or internal roadmaps that a still-moving draft cannot support yet. wolfSSL’s own framing of its Falcon support as provisional is a useful signal here: even vendors actively building toward FN-DSA are not treating it as locked, and external teams building migration plans around it should not either until an Initial Public Draft of FIPS 206 is actually published.
Migration Guide: Moving From RSA and ECC to Post-Quantum
A practical migration does not start with ripping out RSA or ECC. It starts with an inventory, because the NIST National Cybersecurity Center of Excellence guidance and current PQC migration literature agree on one point above all others: organizations cannot migrate what they have not catalogued. Here is the sequence that current guidance converges on.
- Inventory every use of RSA and ECC across TLS certificates, VPN configurations, code-signing pipelines, firmware update mechanisms, and stored data that may need long-term confidentiality.
- Upgrade cryptographic libraries to versions with native PQC support. OpenSSL 3.5, released in April 2025, added ML-KEM, ML-DSA, and SLH-DSA support and enabled the hybrid X25519MLKEM768 TLS 1.3 key share by default.
- Enable hybrid key exchange on public-facing TLS endpoints first, since this is the lowest-risk, highest-adoption change and requires no certificate reissuance.
- Test ML-DSA certificate issuance in a non-production PKI environment before touching production certificate authorities, given how early CA-side ML-DSA deployment still is industry-wide.
- Reserve SLH-DSA for specific high-conservatism use cases rather than a blanket default, given its size and energy cost relative to ML-DSA.
- Build cryptographic agility into new systems so the next algorithm transition, including a possible future FN-DSA rollout, does not require another ground-up migration.
- Track both the NIST 2030/2035 timeline and, if applicable, the CNSA 2.0 2030/2033 timeline separately, since they apply to different system categories with different enforcement.
For teams testing hybrid key exchange directly, OpenSSL 3.5’s command-line tools expose the new groups directly:
openssl list -kem-algorithms
openssl s_client -connect example.com:443 -groups X25519MLKEM768
openssl genpkey -algorithm ML-DSA-65 -out mldsa65_private.pemThe first command confirms ML-KEM is available in the installed OpenSSL build, the second tests whether a target server will negotiate the hybrid X25519MLKEM768 group during a real TLS handshake, and the third generates a ML-DSA-65 key pair for testing signature workflows before touching anything in production.
Why Key Size Still Drives These Decisions
The size and speed trade-offs driving today’s ML-KEM, ML-DSA, and SLH-DSA decisions are a direct continuation of a debate that shaped the move from RSA to elliptic curve cryptography in the first place. Erik Wallace, a mathematics lecturer who has taught public-key cryptography fundamentals, summed up the classical version of this trade-off directly: “for RSA you would need three thousand 72 bits in order to be able to effectively establish a 128-bit key for AES,” referring to the roughly 3,072-bit RSA key needed to match a 128-bit symmetric security level, a point he makes in a lecture comparing RSA and elliptic-curve key sizes.
Cryptography educator Andrew Burkus makes the same point from the elliptic-curve side of the comparison in a separate lecture on why ECC can outperform RSA: “when you’re dealing with a 256 bit curve everything is tuned or 56 bits it’s really not that bad when you’re dealing with RSA everything is like 4096 bits,” contrasting a compact 256-bit elliptic curve against RSA keys that commonly run to 4,096 bits for higher-security deployments. That same logic, smaller keys buying comparable or better security, is exactly the argument NIST is now making for ML-KEM over classical RSA and ECDHE, even though the post-quantum ciphertexts and signatures involved are themselves larger than the elliptic-curve keys that motivated the original RSA-to-ECC shift.
Industry data backs up both the shift away from RSA and ECC and the complexity of managing the transition. Cloudflare’s own measurement puts hybrid ML-KEM adoption at roughly 70 percent of browser-generated traffic reaching its network, a figure published directly by Cloudflare rather than inferred. The OpenSSL Corporation has documented that OpenSSL 3.5 shipped ML-KEM, ML-DSA, and SLH-DSA support with hybrid key exchange on by default, removing one of the largest technical barriers to adoption. NIST’s own National Cybersecurity Center of Excellence materials state plainly that all three standards are implementable today and that organizations should not wait for the 2030 deadline to begin. And Sectigo’s 2025 certificate authority restructuring, moving to dedicated R46 (RSA) and E46 (ECC) roots, shows that even the classical side of the PKI ecosystem is actively preparing infrastructure for the transition rather than treating it as a distant concern.
The Road Ahead: FN-DSA and What Comes Next
FN-DSA is the algorithm to watch heading into 2027. Its draft Falcon-512 signature size of roughly 666 bytes would make it the smallest post-quantum signature among all four NIST candidates by a wide margin, small enough to matter for protocols and devices where every byte in a handshake counts. wolfSSL’s decision to ship native Falcon support ahead of finalization signals that at least part of the ecosystem expects FN-DSA to matter enough to be worth getting a head start on, even with the specification still in flux.
Until FIPS 206 clears a public draft and comment period, treating FN-DSA as anything more than an early-access preview carries real risk. Parameter sets, exact byte sizes, and even implementation details could still shift before finalization, the same way earlier NIST PQC candidates changed during their own standardization processes. The safer read for most organizations planning migrations today is to build on ML-KEM and ML-DSA now, keep SLH-DSA in reserve for conservative signature needs, and treat FN-DSA as a 2027-and-beyond consideration rather than something to deploy against production traffic in 2026.
Verdict: Which Should You Deploy First
The data points to a clear sequence rather than a single winner, because these three algorithms are not actually competing for the same job. ML-KEM is the easy first move: its overhead is small, its real-world performance tracks classical ECC closely enough that most users will never notice the switch, and it already protects an estimated 70 percent of browser traffic hitting Cloudflare’s network. Any organization that has not enabled hybrid ML-KEM key exchange on its public TLS endpoints is behind where the broader internet already stands in October 2026.
ML-DSA is the practical default for signatures. It is fast enough for routine PKI and TLS use, has the largest library and tooling ecosystem among the post-quantum signature options, and its size penalty, while real, has not produced the internet-scale latency problems some early critics predicted. SLH-DSA earns its place only in specific, deliberate scenarios: long-term archival signatures, regulatory contexts that explicitly call for algorithmic diversity, or any situation where paying a 100-times-larger signature and up to 243 percent more signing energy is worth insuring against a hypothetical future weakness in lattice-based math. FN-DSA remains the one to watch rather than the one to deploy, at least until FIPS 206 finalizes. For 2026, the sequence that matches both the data and the deployment reality on the ground is ML-KEM first, ML-DSA second, SLH-DSA where conservatism justifies the cost, and FN-DSA on the roadmap rather than in production.
Frequently Asked Questions
Is ML-KEM the same thing as Kyber?
ML-KEM is the NIST-standardized version of the CRYSTALS-Kyber algorithm, finalized as FIPS 203 in August 2024. Products that shipped earlier Kyber implementations, including Apple’s iMessage PQ3 and Signal’s PQXDH, may not exactly match the final standardized byte-for-byte specification unless they have since been updated.
Do I need both ML-KEM and ML-DSA, or just one?
Almost always both, because they solve different problems. ML-KEM handles key exchange and cannot sign anything. ML-DSA handles signatures and cannot establish a shared secret. A typical TLS deployment needs ML-KEM for the handshake and ML-DSA (or SLH-DSA) for the certificate signatures that authenticate that handshake.
Why is SLH-DSA so much larger than ML-DSA if they do the same job?
SLH-DSA trades size for a more conservative security assumption. It relies only on hash-function hardness, which has a longer track record of scrutiny than the newer lattice problems ML-DSA depends on. That conservatism comes at a real cost: signatures run up to roughly 112 times larger than classical ECDSA, and signing energy can run up to 243 percent higher on 32-bit hardware compared with 64-bit hardware.
When do I actually have to stop using RSA and ECC?
NIST’s guidance targets 2030 for the start of deprecation and 2035 for full disallowance of RSA-2048 and ECC P-256. Systems under the NSA’s CNSA 2.0 suite, mostly national-security and defense-related, face an earlier schedule: post-quantum algorithms preferred by 2030 and required exclusively by 2033.
Is FN-DSA ready to use in production in 2026?
No. FN-DSA, based on the Falcon signature scheme, is still a draft awaiting FIPS 206 finalization, and as of the most recent 2026 reporting had not yet cleared an Initial Public Draft. Libraries like wolfSSL’s WolfCrypt have added native Falcon support in anticipation of standardization, but explicitly flag it as provisional.
What percentage of internet traffic already uses post-quantum encryption?
Cloudflare reports that roughly 70 percent of browser-generated traffic reaching its network uses hybrid post-quantum key exchange (primarily X25519MLKEM768), while only around 15 percent of origin servers it connects to support it, up from about 0.5 percent in 2023. That gap reflects strong client-side browser adoption against much slower server-side rollout.
Can constrained IoT devices realistically run these algorithms?
Yes, based on current hardware testing. A 2026 evaluation found ML-KEM and ML-DSA both feasible on the ESP32-C6 microcontroller without external memory, and a separate benchmark found ML-KEM-512, ML-KEM-768, and ML-DSA-44 all feasible on STM32F4 Cortex-M4 hardware with roughly 100 kilobytes of RAM. Available memory, not CPU speed, was the limiting factor in both studies.
Should certificate authorities switch to ML-DSA right now?
Most are still preparing rather than switching outright. Sectigo’s 2025 restructuring onto dedicated RSA (R46) and ECC (E46) roots shows active preparation for a transition, but current reporting does not show broad production issuance of ML-DSA or SLH-DSA certificates yet. Testing ML-DSA issuance in a non-production environment now, while continuing to issue classical certificates in production, is the approach current migration guidance recommends.