up:: The New Standards MOC

FIPS 206 (FN-DSA)

FIPS 206 is the forthcoming NIST standard that will specify FN-DSA, a post-quantum digital signature scheme derived from FALCON, whose defining trait is very small signatures, and whose defining hazard is that it’s genuinely hard to implement safely. It sits alongside the two finalized signature standards (ML-DSA, the general-purpose default, and SLH-DSA, the conservative hash-based hedge) and answers a narrower question than either: what do you sign with when bandwidth or storage is tight enough that signature size is the thing that decides the design? FN-DSA is the standardized form of the scheme known during the NIST competition as FALCON, and as of mid-2026 it’s selected and in development, not yet published.

The short version:

• FN-DSA does digital signatures, proving a message, certificate, or piece of software came from the expected signer and wasn’t altered. It’s not for key establishment. (That’s ML-KEM.)
• Its whole reason to exist is compact signatures. A FALCON-512 signature is 666 bytes against 2,420 for the smallest ML-DSA and 7,856 for the smallest SLH-DSA, so it wins wherever bytes on the wire or in storage are the binding constraint.
• It’s lattice-based, but built on NTRU lattices with a hash-and-sign design and fast-Fourier trapdoor sampling, a different construction from ML-DSA’s module lattices.
• It’s still in development. FIPS 203, 204, and 205 published in August 2024; FALCON was selected for standardization as FIPS 206 and that process is still underway, so today FN-DSA is a design-for-later target, not a deploy-today standard.
• The catch is the implementation. FN-DSA relies on floating-point arithmetic and a Gaussian sampler that’s difficult to make constant-time, so a careless build can leak the private key even when the math is correct.

Think of a digital signature as a tamper-evident seal that proves who sealed a document and that nobody edited it. ML-DSA makes a sturdy, roomy seal that’s easy to stamp correctly. FN-DSA makes a much smaller seal that fits where the roomy one won’t, but the machine that presses it runs on a finicky, high-precision mechanism, and if the shop floor cuts a corner setting it up, the mechanism quietly gives away the master die. The compactness is real and valuable. So is the precision the workshop has to bring to earn it.

What problem does FN-DSA solve?

FN-DSA’s job is digital signing and verification: proving that data, software, a certificate, or a signed record came from the expected signer and wasn’t modified afterward, in a way meant to hold against a quantum-capable adversary. It gives the three properties every signature scheme provides, authenticity, integrity, and non-repudiation, using a construction with no known quantum shortcut. A signer produces a signature with a private key, and anyone holding the matching public key can verify it against the message.

What sets FN-DSA apart from its two siblings is the artifact it produces. It’s built to make that signature small, which matters in exactly the places where signatures pile up or travel over thin pipes: certificate chains, signed tokens, signed metadata, and protocol messages. It does not do key establishment. Agreeing on a shared secret over an open network is the KEM side of the transition, handled by ML-KEM. Treating “post-quantum” as a single switch is a common error: confidentiality and authentication are separate problems with separate standards, and FN-DSA only addresses the second.

What cryptographic family is FN-DSA?

FN-DSA belongs to lattice-based cryptography, the same broad family as ML-DSA, but it’s built on a different structure and a different signing paradigm. Where ML-DSA uses module lattices with a Fiat-Shamir-with-aborts design, FN-DSA is built on NTRU lattices and uses the older hash-and-sign approach: the message is hashed to a point, and the signer uses a lattice trapdoor to find a short vector near that point. The engine that finds those short vectors is a fast-Fourier trapdoor sampler, and it draws each signature from a discrete Gaussian distribution so the released signatures leak essentially nothing about the private key.

That construction is the source of both the reward and the risk. Sampling short lattice vectors this way produces unusually compact signatures, which is FN-DSA’s headline advantage. It also requires high-precision arithmetic and careful randomness, which is where the implementation danger lives. NIST’s official recommendation captures the resulting positioning cleanly: the agency named ML-DSA the primary signature algorithm to implement, with FALCON standardized as a second option for the roles where its compactness earns the extra engineering care.

Source: NIST IR 8413, Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process, csrc.nist.gov/pubs/ir/8413/upd1/final.

Why are FN-DSA’s signatures so small?

FN-DSA produces the smallest post-quantum signatures of any standardized or standardization-track NIST signature scheme, and that compactness is the entire point of keeping it in the portfolio. The fast-Fourier sampler over NTRU lattices lets a FALCON-512 signature come in at 666 bytes, which is a fraction of the smallest ML-DSA signature and roughly a twelfth of the smallest SLH-DSA signature. Its public keys are also modest, 897 bytes for FALCON-512, smaller than any ML-DSA public key.

That matters because signature migration is not one-dimensional. Some environments care most about compute, some about implementation simplicity, and some about the raw bytes that every signature adds to a certificate, a token, a log line, or a packet. In that last category the byte count is a first-order design constraint, and FN-DSA is the standards-track option that shrinks it the most. The tradeoff, covered below, is that those small signatures are the hardest of the three to produce safely.

Source: FALCON specification, key and signature size figures, falcon-sign.info.

What is FN-DSA’s status, and is FIPS 206 finalized?

FN-DSA is not finalized. In August 2024 NIST published its first three post-quantum standards, FIPS 203, 204, and 205, which specify algorithms derived from CRYSTALS-KYBER, CRYSTALS-Dilithium, and SPHINCS+. FALCON was selected for standardization at the same time and assigned to FIPS 206, but that standardization process is still underway, so as of mid-2026 there’s a selected algorithm and a reserved standard number, without a published standard.

Source: NIST Post-Quantum Cryptography project, status of Falcon standardization, csrc.nist.gov/projects/post-quantum-cryptography.

The practical consequences of that draft status are concrete and worth stating plainly:

1. No approved-algorithm standing yet. Until FIPS 206 publishes, FN-DSA is a planning and prototyping target. Federal deployments that need a standardized post-quantum signature today rely on ML-DSA or SLH-DSA, the two finalized options.
2. Figures and conventions can still shift. The sizes and security-level mapping below come from the FALCON specification, and the finalized FN-DSA may refine encoding details or conventions. Treat pre-standard FALCON code as useful for benchmarking, and re-verify against the FIPS 206 text once it lands.
3. No firm publication date is announced. NIST describes the process as underway without committing to a date on its project page. [OPERATOR VERIFY: check csrc.nist.gov for a FIPS 206 publication date before citing one; none was announced as of 2026-07-09.]

The right posture is to track FN-DSA seriously, design for it where signature size will clearly drive the architecture, and hold production dependence until the standard is final.

What does FN-DSA replace?

FN-DSA replaces classical digital signature roles, the same territory as ML-DSA, not key exchange. Where the job is proving authenticity and integrity, it can take over from:

1. ECDSA and many RSA signature deployments.
2. Size-sensitive certificate and signed-artifact roles.
3. Selected PKI, identity, code-signing, and signed-token functions where compactness pays off.

It does not replace ECDH, DH, or RSA key transport. Those establish shared secrets, which is the KEM side of the migration and belongs to ML-KEM. And it’s best understood as a targeted replacement rather than a blanket one: for mainstream, high-volume certificate migration, ML-DSA is the easier first choice, and FN-DSA is the option a team selects deliberately for the roles where its small signatures create real operational value.

How big are FN-DSA’s keys and signatures?

The headline is that FN-DSA carries the smallest signatures in the standardized signature landscape while keeping modest public keys. The table below places the FALCON figures (the basis for FN-DSA, pending the finalized FIPS 206 text) beside the finalized ML-DSA and SLH-DSA sizes at comparable security levels, so the tradeoff is visible in one view. Sizes are in bytes.

Scheme (parameter set)	Family	NIST category	Public key	Signature
FN-DSA / FALCON-512	NTRU lattice	1	897	666
FN-DSA / FALCON-1024	NTRU lattice	5	1,793	1,280
ML-DSA-44	Module lattice	2	1,312	2,420
ML-DSA-87	Module lattice	5	2,592	4,627
SLH-DSA-128s	Hash-based	1	32	7,856
SLH-DSA-256s	Hash-based	5	64	29,792

Read the signature column top to bottom and the niche explains itself. At a category-1/2 tier, FN-DSA’s 666-byte signature is about a quarter of ML-DSA’s and under a tenth of SLH-DSA’s. At category 5 the gap holds: 1,280 bytes against 4,627 and 29,792. The one place SLH-DSA wins is public-key size, where its hash-based construction gives it a 32-byte or 64-byte key, though its enormous signatures more than erase that in most transport and storage math.

Sources: FALCON key and signature sizes, falcon-sign.info; ML-DSA sizes, NIST FIPS 204, Table 2; SLH-DSA sizes, NIST FIPS 205, Table 2.

Why is FN-DSA hard to implement safely?

FN-DSA is the trickiest of the three signature standards to implement securely, and the reason is baked into how it signs. The FALCON specification states that the use of floating-point arithmetic is unavoidable in the scheme, and that its Gaussian sampler is a critical component whose secure implementation is difficult. A constant-time implementation of that sampler takes careful attention to prevent timing attacks, because inadvertent timing or power variations during sampling can leak information about the secret key.

Source: FALCON specification, floating-point and Gaussian-sampler implementation notes, falcon-sign.info.

Two comparisons make the hazard concrete:

1. The floating-point line is the exact opposite of ML-DSA’s. FIPS 204 explicitly forbids floating-point arithmetic in ML-DSA implementations, because rounding errors can produce incorrect results. FN-DSA’s design requires the high-precision floating-point that ML-DSA bans, and reproducing that arithmetic identically across different hardware, while keeping it constant-time, is a real engineering burden.
2. The sampler is a side-channel surface layered on top of a correctness surface. A build can pass functional test vectors and still leak. If the Gaussian sampler’s running time or power draw depends on the secret values it’s handling, an attacker who can measure that behavior can recover key material over many signatures. Getting the sampler genuinely constant-time is the crux, and it’s why FN-DSA rewards a mature, side-channel-reviewed implementation and punishes a naive one.

The recurring mistake is to read the small signature sizes as a sign that FN-DSA is the easy, lightweight option. The better description is the compact option with the most demanding implementation profile. Its footprint is small; the care its build requires is not.

When would a team choose FN-DSA over ML-DSA or SLH-DSA?

The choice among the three standardized signature paths comes down to what the role optimizes for, and FN-DSA wins a specific slice of that space:

1. Choose FN-DSA when signature size is the first-order constraint (thin-bandwidth links, certificate-heavy chains, size-sensitive tokens or signed metadata) and the signing and verifying infrastructure is mature enough to absorb the implementation scrutiny its sampler demands.
2. Choose ML-DSA for the broad, general-purpose default. It’s finalized, its implementation is more forgiving, and its balance of speed and manageable size makes it the right first move for most certificate and code-signing migration.
3. Choose SLH-DSA when conservative, non-lattice trust assumptions matter more than compact artifacts, typically for long-lived roots of trust and firmware signing, and you can afford its very large signatures.

For most estates the honest answer is that ML-DSA is the default and FN-DSA is a targeted second option, worth the added care only where its compactness clearly earns it. And since FIPS 206 is still in development, even a team that wants FN-DSA is designing toward it today rather than deploying it for compliance. Keeping that option open across a signing architecture is the point of crypto-agility.

Common misconceptions

1. “FN-DSA is just a smaller, better ML-DSA.” It has smaller signatures, and it has a harder implementation profile and a not-yet-final standard. It’s a targeted alternative for size-critical roles, and ML-DSA remains the general-purpose default.
2. “Small signatures mean easy deployment.” The opposite tends to hold here. FN-DSA’s compactness comes from a floating-point sampler that’s among the hardest cryptographic components to implement in constant time, so it demands more engineering maturity than either sibling.
3. “FIPS 206 is a finalized standard I can deploy for compliance.” As of mid-2026 it’s selected and in development. The finalized standardized signatures are ML-DSA (FIPS 204) and SLH-DSA (FIPS 205); FN-DSA work today is planning and prototyping.
4. “FALCON and FN-DSA are two different algorithms.” FALCON is the competition-era name; FN-DSA is the standardization-track designation for the scheme that will be specified in FIPS 206. When it matters, distinguish pre-standard FALCON code from the eventual finalized FN-DSA conventions.
5. “It’s lattice-based like ML-DSA, so it’s the same math.” Both are lattice-based, and they use different structures. FN-DSA builds on NTRU lattices with hash-and-sign and Gaussian sampling, where ML-DSA uses module lattices with Fiat-Shamir-with-aborts, and that difference in construction is what gives them their different size and implementation profiles.

Questions people ask

Is FIPS 206 finalized yet? No. FALCON was selected for standardization as FIPS 206, and that process is still underway as of mid-2026, while FIPS 203, 204, and 205 published in August 2024. Until FIPS 206 is released, FN-DSA is a planning and prototyping target rather than an approved standard. [OPERATOR VERIFY: confirm current FIPS 206 status at csrc.nist.gov before publishing a date.]

How much smaller are FN-DSA signatures than ML-DSA’s? Substantially. A FALCON-512 signature is 666 bytes against 2,420 for ML-DSA-44, and a FALCON-1024 signature is 1,280 bytes against 4,627 for ML-DSA-87. The public keys are smaller too, 897 bytes for FALCON-512 versus 1,312 for ML-DSA-44.

Why is FN-DSA considered hard to implement? Its signing uses floating-point arithmetic that the FALCON specification calls unavoidable, plus a Gaussian sampler whose secure, constant-time implementation is difficult. If that sampler’s timing or power draw depends on secret values, it can leak the private key over many signatures, so FN-DSA needs a mature, side-channel-reviewed implementation.

What does FN-DSA replace? Classical digital signatures, primarily ECDSA and many RSA signature uses, especially in size-sensitive certificate, token, code-signing, and identity roles. It does not replace key-exchange algorithms like ECDH or RSA key transport; that’s ML-KEM’s job.

Should I use FN-DSA or ML-DSA? For most general-purpose signing, ML-DSA is the better first choice: it’s finalized and more forgiving to implement. Reach for FN-DSA when signature size is a genuine architectural constraint and your signing stack can support the extra implementation care.

Is FN-DSA the same as FALCON? FALCON is the algorithm’s competition name, and FN-DSA is the name for its standardization-track form that will be specified in FIPS 206. The sizes above come from the FALCON specification, and the finalized standard may adjust encoding conventions.

Can I deploy FN-DSA for FIPS 140-3 validation today? Not for FN-DSA itself. Until FIPS 206 publishes, FN-DSA can’t satisfy FIPS 140-3 approved-algorithm requirements, so validated post-quantum signing relies on ML-DSA or SLH-DSA for now.

---

Everything here is the map, given freely. When your team needs to decide whether FN-DSA’s compact signatures are worth its implementation profile in your own architecture, and where ML-DSA or SLH-DSA serves better, that’s what an alignment briefing is for.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.