Two algorithms sit on NIST’s shortlist for post-quantum digital signatures, and only one of them actually has a finished standard. ML-DSA, the lattice scheme derived from CRYSTALS-Dilithium, became FIPS 204 on August 13, 2024. FN-DSA, built on the Falcon signature scheme, is still sitting in draft as FIPS 206, more than two years later. That gap matters for anyone planning a signature migration in 2026, because it changes which algorithm you can actually deploy under a finished federal standard today, and which one you’re still betting on.
This piece compares FN-DSA (Falcon) and ML-DSA (Dilithium) on signature size, key size, signing and verification speed, implementation difficulty, and real deployment status as of August 31, 2026. Both are lattice-based, both survived NIST’s multi-year selection process, and both will eventually anchor quantum-resistant signing across TLS certificates, code signing, and blockchain transactions. But they trade off compactness against implementation risk in ways that should shape which one you pick, and when.
If you’re arriving at this comparison because a compliance deadline, a security audit, or a vendor’s PQC roadmap forced the question, the short version is this: one of these algorithms you can deploy under a finished standard today, and one you can’t. Everything else in this article, the byte counts, the benchmarks, the implementation tradeoffs, is context for that one fact.
What ML-DSA and FN-DSA actually are
ML-DSA stands for Module-Lattice-Based Digital Signature Algorithm. NIST finalized it as FIPS 204 on August 13, 2024, building directly on the CRYSTALS-Dilithium submission that won NIST’s PQC signature competition. It relies on the hardness of the Module Learning With Errors (MLWE) problem combined with the Module Short Integer Solution (SIS) problem, according to a 2026 comparative study of post-quantum signature schemes published on arXiv. For a primer on how signing and verification work at a mechanical level, see our explainer on digital signatures and why hashes matter. The design goal was conservative: integer-only lattice arithmetic, no floating point, no exotic sampling routines, so implementers have fewer ways to get it wrong.
FN-DSA stands for FFT (Fast-Fourier Transform) over NTRU-Lattice-Based Digital Signature Algorithm, its formal name once the Falcon submission gets folded into a NIST standard. NIST selected Falcon for standardization back in 2022, alongside Dilithium and SPHINCS+, but as of August 2026 the algorithm is still described on NIST’s own project page as “in development.” An August 2025 NIST status update on FIPS 206 said the initial public draft was “basically written, awaiting approval,” and an IETF working draft on FN-DSA for JOSE and COSE serialization now puts the final publication window at late 2026 or early 2027, a full three years behind ML-DSA.
Cloudflare researcher and cryptography professor Nadia Heninger summed up where that leaves the field in a Cloudflare engineering post: “The most viable general purpose post-quantum signature scheme standardized today is the lattice-based ML-DSA (FIPS 204), which started its life as Dilithium.” (Cloudflare blog) That’s not a knock on Falcon’s math, it’s a statement about what teams can actually ship under a completed federal standard right now.
Why lattice-based signatures resist quantum attacks
Both algorithms lean on the same broad family of math problems: lattice problems. A lattice, in this context, is a regularly spaced grid of points extending across many dimensions, sometimes hundreds of them. Given a messy, non-obvious basis for describing that grid, finding the shortest vector in it, or figuring out which points belong to it, turns out to be extremely hard for both classical and quantum computers. RSA and ECDSA rely on a different pair of hard problems, integer factorization and the discrete logarithm problem, both of which Shor’s algorithm can solve efficiently on a large enough quantum computer, a gap we covered in detail in our ECC vs RSA signing speed comparison. Lattice problems have no known efficient quantum algorithm, which is why NIST selected lattice-based constructions for its primary post-quantum signature and key-exchange standards.
ML-DSA and FN-DSA differ in which specific lattice structure they use. ML-DSA works over module lattices, built from structured polynomial rings that make the underlying arithmetic straightforward to compute with integer operations. FN-DSA works over NTRU lattices, a different structured family that Falcon’s designers paired with Fast Fourier Sampling to keep signatures small. Both approaches are believed to offer comparable theoretical security against quantum attackers. The practical difference isn’t in how resistant the math is, it’s in how easy that math is to implement correctly, and how much output the algorithm produces per signature.
How NIST ended up with two different lattice signatures
NIST’s post-quantum cryptography competition ran in public rounds starting in 2016, narrowing dozens of submissions down through Round 2 and Round 3 before announcing its first selections in July 2022. Dilithium, Falcon, and SPHINCS+ (the hash-based scheme that became SLH-DSA) were all named as signature finalists in that same July 2022 announcement, alongside CRYSTALS-Kyber, which became the key-encapsulation standard ML-KEM (see our ML-KEM vs ML-DSA size comparison for how the key-exchange and signature standards differ). NIST deliberately picked more than one signature algorithm rather than crowning a single winner, a decision it explained as hedging against the possibility that any one mathematical approach could later be broken.
What NIST didn’t do was finalize all of them on the same schedule. ML-KEM, ML-DSA, and SLH-DSA all reached final FIPS status in August 2024, published as FIPS 203, 204, and 205 respectively. Falcon was the odd one out. Its floating-point arithmetic requirements needed more scrutiny before NIST was comfortable locking a final specification, which pushed FN-DSA’s draft process well past its three sibling standards. That’s not a signal Falcon is less trusted mathematically, NIST selected it in the same 2022 announcement as the others, it’s a signal that turning Falcon’s design into a specification implementers can’t get wrong took longer.
Standards timeline: FIPS 204 vs FIPS 206
The standards gap is the single biggest practical difference between these two algorithms, and it’s worth laying out precisely. NIST published FIPS 204 as a final standard on August 13, 2024, confirmed on the CSRC publication page and in the final FIPS 204 PDF itself. That gave vendors, library maintainers, and government agencies a locked specification to build against, including exact byte sizes for keys and signatures across all three security parameter sets.
FIPS 206 has no such finish line yet. NIST submitted the draft for internal Department of Commerce clearance around August 28, 2025, according to a 2026 encryption-standards tracker, and a NIST pqc-forum mailing list post from November 2025 shows NIST staff telling implementers they don’t have a firm date for the initial public draft, only that clearance was still pending. Wikipedia’s PQC standardization tracker states plainly that “as of mid-2026, FIPS 206 (FN-DSA, based on FALCON) remained a draft standard.” Once the initial public draft does land, NIST’s own standards process typically runs a public comment period of roughly a year before finalization, which is why most 2026 trackers put the real final publication in the late 2026 to early 2027 window, not sooner.
That timing gap already shaped how the industry is building. Libraries like Open Quantum Safe (liboqs) ship both algorithms today, but they label Falcon support as tracking the round-3 competition specification rather than a finished FIPS document, meaning implementations will need to migrate again once FIPS 206 locks its final parameters and encodings.
| Milestone | ML-DSA (FIPS 204) | FN-DSA (FIPS 206) |
|---|---|---|
| Based on | CRYSTALS-Dilithium | Falcon |
| NIST selection announced | July 2022 | July 2022 |
| Initial public draft | Published 2023 | Not yet public as of Aug. 2026 |
| Final standard published | August 13, 2024 | Not final; expected late 2026-early 2027 |
| Status as of Aug. 31, 2026 | Final, in production use | Draft, “in development” per NIST |
| CNSA 2.0 mandate | ML-DSA-87 required for NSS by 2033 | Not mandatory under CNSA 2.0 |
| Underlying hard problem | Module-LWE + Module-SIS | NTRU lattice + Fast Fourier sampling |
| Arithmetic type | Integer-only (NTT) | Floating point + Gaussian sampling |
Signature and key sizes compared
This is where Falcon’s design pays off. Because FN-DSA compresses signatures using Fast Fourier sampling over NTRU lattices, its signatures and public keys run roughly a quarter the size of ML-DSA’s at a comparable security level. The official Falcon specification site lists Falcon-512 (roughly AES-128-equivalent security) at an 897-byte public key and a 666-byte signature, and Falcon-1024 (roughly AES-256-equivalent) at a 1,793-byte public key and a 1,280-byte signature. Those exact figures are echoed by the Open Quantum Safe library’s algorithm listing and by Falcon’s own implementation documentation.
ML-DSA’s final FIPS 204 table, published by NIST, sets ML-DSA-44 (category 2, roughly SHA-256-collision-equivalent) at a 1,312-byte public key, a 2,560-byte private key, and a 2,420-byte signature. ML-DSA-65 (category 3, roughly AES-192-equivalent, and the parameter set most guidance treats as the enterprise default) comes in at 1,952 bytes public, 4,032 bytes private, 3,309 bytes signature. ML-DSA-87 (category 5, roughly AES-256-equivalent, and the parameter set CNSA 2.0 requires for national security systems) runs 2,592 bytes public, 4,896 bytes private, 4,627 bytes signature.
| Parameter set | Security category | Public key | Private key | Signature |
|---|---|---|---|---|
| Falcon-512 (FN-DSA) | ~Level 1 (AES-128) | 897 bytes | 1,281 bytes | 666 bytes |
| Falcon-1024 (FN-DSA) | ~Level 5 (AES-256) | 1,793 bytes | 2,305 bytes | 1,280 bytes |
| ML-DSA-44 | Level 2 | 1,312 bytes | 2,560 bytes | 2,420 bytes |
| ML-DSA-65 | Level 3 (enterprise default) | 1,952 bytes | 4,032 bytes | 3,309 bytes |
| ML-DSA-87 | Level 5 (CNSA 2.0 mandatory) | 2,592 bytes | 4,896 bytes | 4,627 bytes |
Line the two up at comparable security: Falcon-512’s 666-byte signature is roughly a quarter the size of ML-DSA-44’s 2,420 bytes, and Falcon-1024’s 1,280-byte signature is well under a third of ML-DSA-87’s 4,627 bytes. For protocols where every byte on the wire costs money or latency, such as constrained IoT links, certificate chains bundled into TLS handshakes, or blockchain transactions with hard size limits, that gap is the whole argument for Falcon.
Signing and verification speed
Benchmarks vary by hardware and implementation, but three independent sources agree on the shape of the tradeoff. Falcon’s own benchmark table on falcon-sign.info reports Falcon-512 signing at roughly 5,948 signatures per second and verification at roughly 27,933 verifications per second on its reference test hardware, with Falcon-1024 landing around 2,913 signs/sec and 13,650 verifications/sec, since the larger parameter set does more lattice arithmetic per operation.
ML-DSA’s performance profile runs the opposite direction: Dilithium’s design, which ML-DSA inherited, was explicitly tuned to make verification cheap and predictable, since a verifying party is typically checking far more signatures than any single signer produces. A 2026 write-up on ML-DSA deployment at scale for CDN and API-gateway workloads reports ML-DSA-65 verification reaching hundreds of thousands of operations per second per core in optimized C implementations on server-class hardware, which is why NIST guidance treats ML-DSA-65 as the practical default for high-throughput TLS and token-validation workloads.
The catch with Falcon’s raw speed numbers is that they come from careful, often floating-point-heavy reference implementations. Falcon’s Gaussian sampling step is notoriously sensitive to timing side channels if implemented incorrectly, and building a constant-time version that doesn’t leak key material through execution time is a harder engineering problem than for ML-DSA’s integer-only NTT operations. That’s the tradeoff underneath every Falcon benchmark: fast, but only if you get the implementation exactly right.
| Metric | Falcon-512 | Falcon-1024 | ML-DSA-65 |
|---|---|---|---|
| Key generation | 8.64 ms | 27.45 ms | Sub-millisecond on modern x86-64 |
| Signing throughput | ~5,948 sig/s | ~2,913 sig/s | Tens of thousands of ops/sec |
| Verification throughput | ~27,933 ver/s | ~13,650 ver/s | Hundreds of thousands of ops/sec/core |
| Arithmetic | Floating point + FFT | Floating point + FFT | Integer-only NTT |
Note that these figures come from different reference platforms and shouldn’t be read as a head-to-head lab test on identical hardware. What’s consistent across every source, including Open Quantum Safe’s liboqs benchmarks and the falcon-sign.info reference numbers, is the directional pattern: Falcon signs fast and produces small output, ML-DSA verifies fast and implements safely.
Hardware acceleration follows the same maturity gap as everything else in this comparison. PQClean, the reference implementation project widely used as a baseline for portable, tested post-quantum code, lists Falcon among its “to-be standards” implementations, alongside more mature, finalized entries like ML-DSA. Vectorized ML-DSA code using AVX2 on x86 and NEON on ARM is common across performance-oriented libraries such as liboqs, since the algorithm’s integer NTT operations vectorize cleanly and predictably. Falcon has optimized AVX2 paths too, particularly for its FFT-based signing step, but pairing that speed with strict constant-time behavior across different microarchitectures remains a harder, less standardized problem, which is part of why library maintainers keep flagging Falcon support as provisional rather than production-hardened.
Implementation difficulty: why NIST picked ML-DSA as the default
The arXiv comparative study on post-quantum signature schemes lays out the core distinction plainly: “Falcon is a more compact lattice-based signature scheme that leverages NTRU lattices and advanced techniques such as Fast Fourier Sampling.” (arXiv) Fast Fourier Sampling requires floating-point arithmetic and discrete Gaussian sampling, both of which are difficult to implement in constant time across different CPU architectures. Get the rounding behavior even slightly wrong on one platform versus another, and you risk a side-channel leak that can recover the private key.
ML-DSA sidesteps that entire class of problem. Its module-lattice structure runs on integer Number Theoretic Transform operations, the same general category of math used in many existing cryptographic libraries, with no floating point and no Gaussian sampling dependency. The same arXiv study notes that “Dilithium is another lattice-based algorithm that also relies on the hardness of the MLWE problem, in combination with the Module Short Integer Solution (SIS) problem,” a more conservative and better-studied set of hard problems than Falcon’s NTRU-based construction. (arXiv)
That’s the practical reason NIST guidance treats ML-DSA as the general-purpose default and Falcon as a specialized option for bandwidth-constrained scenarios where teams have the cryptographic engineering resources to implement it safely. It’s not that Falcon is less secure in theory, it’s that a buggy constant-time implementation is a much easier way to lose in practice than a mathematically broken lattice problem.
Real-world adoption and deployments in 2026
Five concrete examples show how the standards gap between the two algorithms is playing out in production systems as of August 2026.
Open Quantum Safe (liboqs). The most widely used open-source PQC library ships both ML-DSA-44/65/87 against the final FIPS 204 parameter sets and Falcon-512/1024 against the round-3 competition specification. The project’s own algorithm documentation flags that Falcon support will need a migration once FIPS 206 finalizes its exact encodings, since NIST’s public drafting process has historically adjusted parameter details between initial draft and final publication.
CNSA 2.0 government systems. U.S. National Security Agency guidance under the Commercial National Security Algorithm Suite 2.0 requires ML-DSA-87 for signature use across national security systems, with a migration deadline running through the early 2030s for most equipment classes. FN-DSA is not mandated in the CNSA 2.0 profile at all, a direct consequence of it not yet being a finished FIPS standard when the suite was defined.
Algorand blockchain. Algorand’s quantum-resistant transaction roadmap specifically evaluates Falcon for its compact signatures, citing the roughly 1,280-byte Falcon-1024 signature and 1,793-byte public key as a better fit for on-chain transaction size limits than ML-DSA’s multi-kilobyte equivalents would allow. A blockchain that has to fit signatures into a fixed block size budget feels every extra kilobyte in a way a general-purpose web server does not.
IETF protocol drafts. The IETF’s draft-ietf-cose-falcon specification defines how to serialize FN-DSA signatures for JOSE and COSE object-signing formats, explicitly built against the expectation that FIPS 206 lands in late 2026 or early 2027. That means the protocol-layer plumbing for Falcon is being standardized at the IETF ahead of the underlying algorithm being final at NIST, an unusual sequencing that reflects how much interest exists in Falcon’s small signatures despite the incomplete FIPS status.
Enterprise PQC migration guides. Multiple 2025-2026 enterprise migration playbooks recommend starting PQC signature rollouts with ML-DSA for document signing, code signing, and authentication tokens now, and evaluating Falcon later for bandwidth-sensitive use cases such as IoT once FIPS 206 is finalized. That two-phase pattern shows up repeatedly across vendor guidance: adopt the finished standard first, treat the draft standard as a future optimization rather than a day-one requirement.
How signature size affects TLS handshakes and certificate chains
Signature size isn’t an abstract number, it directly changes how much data a TLS handshake has to move before a connection opens. A classical ECDSA certificate chain carries signatures around 64 to 72 bytes each. Swap in ML-DSA-65 at 3,309 bytes per signature, and a typical three-certificate chain (leaf, intermediate, root) can add tens of kilobytes to the handshake once every signature and public key in the chain is counted. That’s a meaningful jump for mobile connections, satellite links, or any environment where the first round trip already strains available bandwidth.
Falcon’s appeal in this exact scenario is direct: a Falcon-512 signature at 666 bytes adds a fraction of the overhead ML-DSA does, which is part of why constrained-bandwidth protocol designers keep circling back to it despite the incomplete standard. The tradeoff cuts the other way for high-volume verifying servers, where ML-DSA’s cheaper, integer-only verification step matters more than the extra bytes on the wire, since a CDN edge node might verify millions of signatures an hour and can absorb the size cost far more easily than a constrained client can absorb a slow, floating-point-heavy verification.
Where SLH-DSA fits as a third option
ML-DSA and FN-DSA aren’t the only NIST-standardized post-quantum signatures. SLH-DSA, standardized as FIPS 205 alongside ML-DSA in August 2024, takes a completely different approach: it’s built on hash functions rather than lattices, trading much larger signatures (multiple kilobytes to tens of kilobytes depending on parameters) for a conservative security assumption that doesn’t depend on lattice problems staying hard at all. NIST’s own guidance treats SLH-DSA as a deliberate hedge, a fallback path if some future advance in lattice cryptanalysis ever weakens confidence in both ML-DSA and FN-DSA at once. We covered SLH-DSA’s tradeoffs against ML-DSA in more depth in our ML-DSA vs SLH-DSA signature-size comparison.
That context matters for how you should read the ML-DSA versus FN-DSA comparison: neither is meant to be the only signature algorithm an organization ever uses. NIST’s multi-algorithm strategy assumes most deployments standardize on ML-DSA for everyday use, reach for Falcon once it’s final where signature size is the binding constraint, and keep SLH-DSA available as a structurally different backup for the highest-assurance use cases. Betting an entire PKI on a single mathematical assumption, lattice or otherwise, is exactly what NIST’s selection process was designed to avoid.
Hybrid and composite signatures: bridging the standards gap
Most organizations aren’t switching straight from RSA or ECDSA to a pure post-quantum signature. They’re running both at once, for a transition period, through what the IETF’s LAMPS working group calls composite signatures. The active draft-ietf-lamps-pq-composite-sigs specification defines combinations of ML-DSA with RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448, packaged so a certificate carries a single subject public key and a single signature value that verifiers can treat as one atomic algorithm, even though it’s cryptographically two signatures bundled together. A companion draft, draft-ietf-lamps-cms-composite-sigs, does the same for Cryptographic Message Syntax, and a TLS-specific draft (draft-reddy-tls-composite-mldsa) specifies how to negotiate composite ML-DSA signatures inside a TLS 1.3 handshake.
That composite work is squarely built around ML-DSA, not Falcon. Early drafts briefly included Falcon-based composite algorithm identifiers, but a later LAMPS release note confirms those references were removed, describing them as a typo (“Falon”) rather than a maintained Falcon composite path. A hybrid post-quantum certificate explainer tracking the draft’s progress noted that LAMPS reached working-group last call on the ML-DSA composite signature draft in March 2026, targeting RFC publication in the fourth quarter of 2026, which puts standardized composite ML-DSA certificates on track to ship around the same time FIPS 206 itself is expected to finalize. In practice, that means the transitional bridge between classical and post-quantum PKI is being built with ML-DSA on one side and RSA or ECDSA on the other, with Falcon left out of the composite picture until its own standard is done.
Pricing and licensing: what deployment actually costs
Neither algorithm carries a license fee. Both ML-DSA and Falcon were developed as open NIST competition submissions and are royalty-free to implement, following NIST’s standard practice for FIPS-designated algorithms. The real cost difference between the two shows up in engineering time and infrastructure overhead, not in licensing.
| Cost category | ML-DSA | FN-DSA (Falcon) |
|---|---|---|
| Algorithm licensing | Free (open NIST standard) | Free (open NIST standard, pending final FIPS) |
| Library maturity cost | Low — production-ready in liboqs, OpenSSL PQC branches | Medium — tracks round-3 spec, will need a migration once FIPS 206 finalizes |
| Bandwidth/storage cost per signature | Higher (2.4-4.6 KB per signature) | Lower (0.65-1.3 KB per signature) |
| Constant-time implementation effort | Lower, integer arithmetic only | Higher, floating point + Gaussian sampling needs specialist review |
| Compliance readiness (CNSA 2.0 / federal) | Ready now (FIPS 204 final) | Not yet eligible (FIPS 206 draft) |
Pros and cons
Stripped of the standards-timeline argument, the two algorithms make different bets on what matters most in a signature scheme. ML-DSA bets on implementation safety and verification speed at the cost of larger output. Falcon bets on compactness at the cost of a harder, more failure-prone implementation path. Neither bet is wrong, they’re just optimized for different deployment shapes.
ML-DSA (FIPS 204 / Dilithium)
- Pro: Final, published NIST standard since August 2024, usable in federal procurement today
- Pro: Integer-only arithmetic, meaning constant-time implementations are far easier to get right
- Pro: Fast verification, well-suited to high-throughput TLS and token-validation workloads
- Pro: Mandatory under CNSA 2.0 for national security systems (ML-DSA-87)
- Con: Signatures and keys run 2-4x larger than Falcon at comparable security levels
- Con: Larger signatures add real bandwidth and storage overhead in constrained protocols
FN-DSA (Falcon / draft FIPS 206)
- Pro: Signatures and public keys roughly a quarter the size of ML-DSA at comparable security
- Pro: Fast signing throughput in optimized reference implementations
- Pro: Strong fit for bandwidth-constrained protocols: IoT, blockchain, certificate-chain-heavy TLS
- Con: Not yet a final NIST standard as of August 2026; still in draft, three years behind ML-DSA
- Con: Requires floating-point Gaussian sampling, a much harder constant-time engineering problem
- Con: Not eligible for CNSA 2.0 or most federal compliance mandates until FIPS 206 finalizes
Use-case recommendations
The right algorithm depends less on abstract security preferences and more on what your system actually optimizes for: verification throughput, signature size, or regulatory compliance. The six scenarios below cover most of the situations engineering teams are weighing in 2026.
- Federal or CNSA 2.0-regulated systems: use ML-DSA-87. It’s the only lattice signature standard mandatory under CNSA 2.0, and Falcon isn’t eligible until FIPS 206 finalizes.
- General enterprise TLS, code signing, and document signing today: use ML-DSA-65. It’s the parameter set most 2025-2026 migration guides treat as the practical default, with mature library support in liboqs and OpenSSL’s PQC branches.
- High-throughput API gateways and token verification: use ML-DSA. Its fast, integer-only verification path handles large verification volumes more predictably than Falcon’s floating-point verification step.
- Bandwidth-constrained IoT and embedded devices: plan for Falcon once FIPS 206 finalizes, or use it now against the round-3 specification if you control both endpoints and can accept a future migration.
- Blockchain and other size-capped transaction formats: evaluate Falcon-1024’s roughly 1,280-byte signatures, as Algorand’s PQC roadmap has, since ML-DSA’s multi-kilobyte signatures can blow past on-chain size budgets.
- Protocol designers building ahead of FIPS 206: follow the IETF’s draft-ietf-cose-falcon approach, building serialization support now while treating the underlying algorithm as pre-final and subject to encoding changes.
Migration guide: moving from RSA or ECDSA to a lattice signature
Most teams migrating away from RSA or ECDSA signatures in 2026 are choosing between ML-DSA today and a future Falcon option, not deciding between two equally finished standards. Here’s a practical sequence.
- Inventory every place your system uses RSA or ECDSA signatures: TLS certificates, code-signing keys, JWT/token signing, document signing, and any blockchain or firmware signing paths.
- Classify each use case by size sensitivity. If signature bytes on the wire or on-chain matter, flag it as a future Falcon candidate. If not, it’s a straightforward ML-DSA migration.
- For anything mandatory or federally regulated, default to ML-DSA-87 to satisfy CNSA 2.0 requirements; for general enterprise use, default to ML-DSA-65.
- Pick a library with production ML-DSA support, such as Open Quantum Safe’s liboqs or an OpenSSL PQC branch, rather than hand-rolling lattice arithmetic.
- Run a hybrid signing period where both the legacy RSA/ECDSA signature and the new ML-DSA signature are present, so older verifiers don’t break during rollout.
- Update certificate and token size assumptions in downstream systems. ML-DSA-65 signatures at 3,309 bytes are roughly 50x larger than a 64-byte ECDSA signature, and that can break hardcoded buffer sizes or MTU assumptions.
- For size-constrained paths flagged in step 2, track FIPS 206’s status and plan a second migration to Falcon once it’s final, rather than adopting the round-3 spec into a system you can’t easily re-key.
- Test verification throughput under real load before cutover. ML-DSA’s larger signatures mean more bytes to verify per operation, even though the algorithm itself verifies fast.
- Document the migration for audit purposes, since CNSA 2.0 and similar mandates require organizations to show a defined PQC transition plan, not just eventual compliance.
The verdict: which one should you actually use in 2026
For nearly every team migrating signatures in 2026, ML-DSA is the answer, and the data makes the case cleanly. It’s a finished FIPS standard as of August 13, 2024, it’s mandatory for CNSA 2.0 national security systems, its integer-only arithmetic is dramatically easier to implement without side-channel bugs, and its verification speed (hundreds of thousands of operations per second per core in optimized deployments) comfortably handles enterprise TLS and token workloads. The cost is signature size: 2,420 to 4,627 bytes depending on parameter set, roughly 2 to 4 times larger than Falcon at comparable security.
Falcon’s case is narrower but real. A 666-byte Falcon-512 signature or a 1,280-byte Falcon-1024 signature is a meaningful win for anything where bytes on the wire or on-chain are expensive, which is exactly why Algorand’s quantum-resistant roadmap and IETF’s COSE serialization draft are both building around it ahead of the standard being final. But “ahead of the standard being final” is the catch. As of August 31, 2026, FIPS 206 remains a draft, NIST’s own project page still lists it as “in development,” and most trackers don’t expect a final publication until late 2026 or early 2027 at the earliest. Building production infrastructure on a pre-final spec means accepting a second migration once the encoding locks. For the broader picture of how fast the internet is moving to post-quantum defaults across both key exchange and signing, see our report on post-quantum cryptography adoption, and browse our full cryptography coverage for related standards updates.
The practical rule: deploy ML-DSA now for anything that needs to be compliant, auditable, or verified at scale today. Track FIPS 206 if your workload is genuinely bandwidth-constrained, and plan Falcon as a second-phase migration once NIST actually finishes the standard, not before.
Worth watching over the next two quarters: NIST’s own pqc-forum mailing list has shown staff repeatedly declining to commit to a firm initial-public-draft date for FIPS 206, even as late as November 2025, so treat “late 2026 or early 2027” as an informed estimate from trackers rather than a locked NIST commitment. The LAMPS composite ML-DSA work targeting an RFC in the fourth quarter of 2026 gives a useful proxy signal, since transitional PKI standards tend to solidify around the same window as the underlying algorithm they depend on. If that composite RFC slips, it’s a reasonable bet FIPS 206 slips with it.
Frequently asked questions
Is FN-DSA (Falcon) a finished NIST standard as of August 2026?
No. FIPS 206 is still in draft. NIST’s post-quantum cryptography standardization page describes it as “in development,” and the initial public draft had not been published as of mid-2026 according to Wikipedia’s PQC standardization tracker, with final publication expected in late 2026 or early 2027.
Is ML-DSA the same thing as Dilithium?
Yes. ML-DSA is the standardized name NIST gave to the algorithm derived from the CRYSTALS-Dilithium submission when it published FIPS 204 on August 13, 2024. “Dilithium” and “ML-DSA” refer to the same underlying construction.
Which is smaller, a Falcon signature or an ML-DSA signature?
Falcon is smaller. A Falcon-512 signature is 666 bytes versus 2,420 bytes for ML-DSA-44 at a comparable security level, and Falcon-1024 is 1,280 bytes versus 4,627 bytes for ML-DSA-87.
Why does NIST recommend ML-DSA over Falcon for most uses?
Because ML-DSA uses integer-only lattice arithmetic, which is much easier to implement safely in constant time. Falcon requires floating-point Gaussian sampling, which is more prone to timing side-channel bugs if implemented incorrectly.
Can I use Falcon in production today?
You can implement it against the round-3 competition specification through libraries like Open Quantum Safe, but you’re building against a spec that isn’t finalized. Once FIPS 206 publishes, encodings or parameters could shift, requiring a migration.
Does CNSA 2.0 require Falcon or ML-DSA?
CNSA 2.0 requires ML-DSA-87 for signature use in U.S. national security systems. Falcon/FN-DSA is not part of the CNSA 2.0 mandate, since it isn’t a finished standard.
What does FN-DSA stand for?
FFT (Fast-Fourier Transform) over NTRU-Lattice-Based Digital Signature Algorithm. It’s the name NIST assigned to the standardized version of Falcon.
Should blockchain projects use ML-DSA or Falcon?
It depends on transaction size limits. Algorand’s quantum-resistant transaction roadmap specifically evaluates Falcon for its compact signatures, since ML-DSA’s multi-kilobyte signatures can be harder to fit into on-chain size budgets.
How much bigger is an ML-DSA signature than a classical ECDSA signature?
Roughly 34 to 65 times bigger. A classical ECDSA signature runs about 64 to 72 bytes, while ML-DSA signatures range from 2,420 bytes (ML-DSA-44) to 4,627 bytes (ML-DSA-87). Falcon narrows that gap somewhat: a Falcon-512 signature at 666 bytes is about 9 to 10 times the size of an ECDSA signature.
Is SLH-DSA a better choice than either ML-DSA or FN-DSA?
Not for general use. SLH-DSA (FIPS 205) is hash-based rather than lattice-based, which makes it a useful backup if lattice cryptanalysis ever advances, but its signatures run far larger than either ML-DSA’s or Falcon’s. NIST guidance positions it as a conservative hedge, not an everyday default.
