What Is FIPS 206 / FN-DSA? A Plain-English Guide to FALCON Signatures
FIPS 206, also called FN-DSA or FALCON, is NIST's draft quantum-safe digital-signature standard. Learn how FALCON works, where it fits with ML-DSA and SLH-DSA, and whether your business needs it.
NIST's post-quantum cryptography program has produced three finalized signature standards and one draft. We have covered FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA). The fourth member is FIPS 206, also known as FN-DSA or by its original name, FALCON.
FALCON is the odd one out. It is based on a different lattice problem than ML-DSA, produces much smaller signatures, and is designed for high-assurance use cases where every byte and every millisecond matters. It is also still in draft, which matters for procurement and compliance planning.
Here is what FIPS 206 does, how it compares to the other NIST signature standards, and whether you need to care about it today.
The FALCON design in one paragraph
FALCON is a lattice-based digital-signature scheme built on NTRU lattices and the "hash-and-sign" paradigm. Its security comes from the hardness of finding short vectors in structured lattices — a different hard problem than the one used by ML-DSA. The payoff is efficiency: FALCON signatures are roughly 650 bytes and public keys are about 900 bytes, both dramatically smaller than ML-DSA.
The trade-off is complexity. FALCON's signing process uses floating-point arithmetic and careful rejection sampling to protect the secret key. That makes implementation harder to get right, which is why NIST kept it in draft longer than ML-DSA and SLH-DSA.
How FIPS 206 fits with FIPS 204 and 205
| Standard | Name | Signature size | Public key size | Best known for |
|---|---|---|---|---|
| FIPS 204 | ML-DSA | ~3,300 bytes | ~1,900 bytes | General-purpose replacement for RSA/ECDSA |
| FIPS 205 | SLH-DSA | ~7,800–49,000 bytes | ~60 bytes | Conservative, hash-based backup |
| FIPS 206 | FN-DSA / FALCON | ~650 bytes | ~900 bytes | Small signatures, high-assurance systems |
Think of the three as a portfolio:
- ML-DSA is the workhorse for TLS certificates, code signing, and everyday signatures.
- SLH-DSA is the conservative hedge if you do not trust lattice assumptions at all.
- FALCON is the efficiency play when bandwidth, storage, or latency constraints are tight and you still want lattice security.
Where FALCON shines
FALCON's tiny signature size makes it attractive anywhere signatures are transmitted or stored in large numbers:
- High-frequency protocols — IoT fleets, vehicle-to-everything (V2X), and constrained devices where every byte on the wire costs battery or spectrum.
- Blockchain and distributed ledgers — every transaction carries a signature; smaller signatures mean lower fees and faster validation.
- Smart cards and secure enclaves — limited storage and signing time favor compact signatures.
- Long-term document archives — millions of signed documents accumulate; smaller signatures reduce storage costs.
- High-assurance government and defense systems — the very places that drove FALCON's inclusion in the NIST competition.
Where ML-DSA still wins
For most enterprise IT use cases, ML-DSA remains the safer choice today:
- Mature tooling. ML-DSA shipped first, so libraries, HSMs, and certificate-authority integrations are further along.
- Simpler implementation. ML-DSA does not require the floating-point and rejection-sampling care that FALCON does, so the risk of subtle side-channel bugs is lower.
- No draft status. FIPS 204 is finalized; FIPS 206 is still a draft, which can block procurement in regulated environments.
The usual advice: unless you have a specific bandwidth or storage constraint, start with ML-DSA. Add FALCON later when it makes economic or operational sense.
Draft status and what it means
As of 2026, FIPS 206 is in draft form. NIST published it for public comment alongside the finalized FIPS 203, 204, and 205. The algorithm is unlikely to change in a fundamental way — FALCON has been studied for years — but the standard itself may still see tweaks to implementation guidance, parameter sets, or test vectors.
What that means practically:
- Do not bake FALCON into compliance-critical systems yet if your auditors require finalized standards.
- Do start prototyping if you have a use case where its size advantage matters.
- Do monitor NIST updates so you can adopt the final version quickly once it lands.
Should your business adopt FALCON now?
For most organizations, the answer in 2026 is no — or at least not yet. The right sequence is:
- Inventory your signatures and migrate the bulk of them to ML-DSA.
- Reserve SLH-DSA for your highest-value trust anchors.
- Pilot FALCON only where its compact signatures solve a real cost or performance problem.
If you are not sure whether FALCON is worth the complexity, it probably is not. ML-DSA is the right default for the next several years.
FAQ
Is FALCON a different kind of lattice than ML-DSA?
Yes. ML-DSA uses module lattices over polynomial rings (the CRYSTALS-Dilithium construction). FALCON uses NTRU lattices and a hash-and-sign structure. They are both lattice-based, but the underlying hard problems and implementation details differ.
Why is FALCON still a draft if the others are finalized?
NIST wanted additional time to study FALCON's implementation complexity, side-channel resistance, and floating-point requirements before finalizing it. The extra review does not mean FALCON is broken; it means NIST is being cautious.
Can I mix FALCON with ML-DSA and SLH-DSA?
Yes. A system can offer multiple signature algorithms and negotiate the strongest one both ends support. Hybrid or composite signatures — where a message is signed with both a classical and a post-quantum algorithm — are also possible and recommended during the transition.
Will FALCON replace ML-DSA?
No. They are complementary. ML-DSA is the general-purpose standard. FALCON is a specialized option for constrained or high-volume environments.
Bottom line
FIPS 206 / FN-DSA / FALCON is the smallest and fastest of the NIST post-quantum signature standards, but it is also the most complex to implement and the last to be finalized. It belongs on your radar if you are building constrained systems, high-frequency protocols, or blockchain infrastructure. For everyone else, ML-DSA is the right place to start.
The important thing is to have a signature-migration plan that does not depend on any single algorithm. A portfolio of ML-DSA, SLH-DSA, and eventually FALCON gives you speed, conservatism, and efficiency without putting all your trust in one mathematical assumption.
Want to see which parts of your infrastructure still rely on classical signatures? Run Secuur's free quantum-risk scan and get a prioritized migration checklist.