FN-DSA and the Future of Compact Post-Quantum Signatures

Quick answer: FN-DSA, based on FALCON and destined to become FIPS 206, produces the smallest signatures and public keys of any NIST post-quantum signature standard, roughly 4 to 6 times smaller than ML-DSA at comparable security levels. That compactness makes it attractive for bandwidth-constrained environments and certificate hierarchies where small root and intermediate signatures benefit every certificate beneath them. It is not yet final: NIST submitted the draft for approval in August 2025, with the finished FIPS 206 expected in late 2026 or early 2027. Until then, FN-DSA belongs in testing and evaluation, not production.

ML-DSA gets most of the production attention because it is finalized and has clear platform support. FN-DSA gets comparatively little, mostly because “still a draft” ends most conversations before they start. That undersells it. FN-DSA solves a real problem, signature size, that ML-DSA’s roughly 3.3-kilobyte signatures make expensive in constrained environments, and understanding its trade-offs now means being ready to deploy it correctly once FIPS 206 finalizes rather than starting the evaluation from zero.

Key Takeaways

• FN-DSA, based on FALCON, produces signatures roughly 4 to 6 times smaller than ML-DSA at comparable security levels, the smallest among NIST’s post-quantum signature standards.
• NIST submitted the FN-DSA draft for approval on August 28, 2025. The final FIPS 206 standard is widely expected in late 2026 or early 2027, and specification details can still change until then.
• FN-DSA’s core implementation challenge is floating-point Gaussian sampling during signing, which is genuinely difficult to implement safely in constant time and is the main reason its standardization has taken longer than ML-DSA’s.
• Major certificate authorities have stated they will not ship FN-DSA in production until FIPS 206 is finalized, a reasonable posture given the implementation risk and the still-open specification.
• ML-DSA remains the buildable, production-ready lattice signature standard today; FN-DSA is something to plan and test for now, not deploy.

What FN-DSA Actually Is

FN-DSA is NIST’s standardized name for FALCON, one of the original signature schemes selected in NIST’s 2022 round of finalists alongside CRYSTALS-Dilithium (now ML-DSA) and SPHINCS+ (now SLH-DSA). Like ML-DSA, it is a lattice-based scheme, but it rests on a different lattice structure, NTRU lattices rather than the module lattices behind ML-DSA, and uses a fundamentally different signing approach: a hash-and-sign construction using Fast Fourier Transform-based sampling, rather than the Fiat-Shamir-with-aborts approach ML-DSA uses.

That different construction is exactly what produces FN-DSA’s defining advantage: signatures around 666 to 690 bytes at FN-DSA-512, compared to roughly 2,420 bytes for ML-DSA-44 at a comparable security level, a 4 to 6 times reduction. Public keys shrink similarly. For context on how ML-DSA’s larger signatures compare across parameter sets, see our FIPS 203, 204, and 205 standards guide.

Likely Use Cases for Compact Signatures

FN-DSA’s size advantage is not a generic benefit; it matters specifically where signature size has an outsized operational cost.

• Root and intermediate CA certificates: a smaller root or intermediate signature reduces the size of every certificate chain built beneath it, compounding the benefit across an entire PKI hierarchy rather than a single certificate.
• Bandwidth-constrained networks: IoT deployments, satellite links, and low-power wide-area networks where every additional byte in a handshake has a measurable cost in latency or power consumption.
• High-frequency signing with strict payload limits: protocols where message size is capped by design and a larger ML-DSA signature would not fit without restructuring the protocol itself.

Implementation Considerations: The Floating-Point Problem

FN-DSA’s compactness comes at a real implementation cost. Signing relies on Gaussian sampling performed with floating-point arithmetic, and doing that safely, in constant time, without leaking timing information an attacker could exploit, is a substantially harder engineering problem than the integer-only arithmetic ML-DSA uses. This is not a minor footnote: it is the primary reason FN-DSA’s standardization has taken longer than ML-DSA’s and SLH-DSA’s, both of which avoid floating-point signing entirely.

In practice, this means FN-DSA signing should run inside a certified, audited cryptographic module, such as an HSM, rather than a general-purpose floating-point implementation that has not been specifically hardened against timing side channels. Verification, which does not involve floating-point signing operations, carries substantially less of this risk.

Standardization Status: Draft, Not Final

NIST submitted the FN-DSA draft for approval on August 28, 2025, and has been preparing an Initial Public Draft for review. Based on how FIPS 203, 204, and 205 progressed through their own review periods, a roughly year-long review is typical, which places final publication in late 2026 or early 2027. Until that final publication, parameter encodings, object identifiers, and other specification details remain subject to change.

This status is the reason major certificate authorities have publicly stated they will not ship FN-DSA support in production ahead of finalization. That caution is well founded: shipping against a moving draft risks needing to reissue or reformat certificates once the final specification locks, an entirely avoidable cost for an algorithm that is not yet required by any regulatory deadline.

What We’d Actually Recommend

Use ML-DSA for production signing today; it is finalized, buildable, and required by CNSA 2.0 and most current regulatory guidance. Track FN-DSA’s path toward FIPS 206 finalization and begin lab-environment testing once an Initial Public Draft is available, specifically evaluating your HSM vendor’s floating-point signing implementation rather than a general-purpose software library. If your PKI includes root or intermediate certificates in a bandwidth-constrained deployment context, flag FN-DSA as a candidate worth revisiting once it standardizes, but do not build a production migration timeline around it until FIPS 206 is final.

How Encryption Consulting Can Help

When FN-DSA does finalize, CodeSign Secure is where that evaluation lands operationally: it already supports the NIST signature algorithm portfolio with HSM-backed, policy-enforced signing, and is built to add a newly standardized algorithm like FN-DSA without a platform migration once FIPS 206 locks. Where the compact-signature benefit applies to certificate chains specifically, CertSecure Manager‘s policy-driven architecture carries the same forward compatibility.

Our PQC Advisory Services track standards-track algorithms like FN-DSA through their standardization process and build them into your migration roadmap at the right time, evaluation and lab testing now, production consideration only after FIPS 206 finalizes.

Worth Planning For, Not Yet Worth Deploying

FN-DSA’s compact signatures solve a real problem for bandwidth-constrained deployments and PKI hierarchies, and its NTRU-lattice, hash-and-sign construction is a genuinely different engineering approach from ML-DSA, not just a smaller version of the same idea. Its floating-point signing requirement is a real implementation risk, one serious enough that major CAs are waiting for finalization before shipping it. That caution is the right posture for most organizations too: track FN-DSA toward FIPS 206, evaluate it in a lab once the draft is available, and hold off on production deployment until the standard, and the HSM support behind it, are both final.

Frequently Asked Questions

Is FN-DSA the same as FALCON?

Yes. FN-DSA is NIST’s standardized name for the algorithm originally submitted and selected as FALCON, in the same way ML-DSA is the standardized name for CRYSTALS-Dilithium.

How much smaller are FN-DSA signatures than ML-DSA’s?

Roughly 4 to 6 times smaller at comparable security levels. FN-DSA-512 produces signatures around 666 to 690 bytes, compared to roughly 2,420 bytes for ML-DSA-44.

Why has FN-DSA taken longer to standardize than ML-DSA?

Its signing process relies on floating-point Gaussian sampling, which is significantly harder to implement safely and in constant time than the integer-only arithmetic ML-DSA and SLH-DSA use. That implementation complexity has driven a longer, more cautious standardization timeline.

Can we use FN-DSA in production today?

Not recommended. FIPS 206 remains a draft, with a final standard expected in late 2026 or early 2027. Specification details can still change, and major certificate authorities have said they will not ship FN-DSA in production until the standard finalizes.

Does FN-DSA replace ML-DSA?

No. They are expected to coexist, with ML-DSA as the general-purpose default and FN-DSA reserved for use cases where its compact signature size specifically matters, similar to how SLH-DSA coexists with ML-DSA as a narrow-use alternative.