FIPS 206 · FN-DSA · Falcon
FN-DSA is not final. Your signature migration should not wait for it.
Three of NIST’s four post-quantum algorithms have been finalized since August 2024. The fourth — FN-DSA, the compact one everybody wants for certificate chains — is still a draft, and the most common planning mistake right now is assuming otherwise. Here is what actually changes when FIPS 206 lands, what to inventory before then, and what to put to your CA.
Where things stand
The four standards, and the one that isn’t
| Standard | Name | Formerly | Purpose | Status |
|---|---|---|---|---|
| FIPS 203 | ML-KEM | CRYSTALS-Kyber | Key encapsulation | Final, 13 Aug 2024 |
| FIPS 204 | ML-DSA | CRYSTALS-Dilithium | Digital signatures | Final, 13 Aug 2024 |
| FIPS 205 | SLH-DSA | SPHINCS+ | Digital signatures (hash-based) | Final, 13 Aug 2024 |
| FIPS 206 | FN-DSA | Falcon | Digital signatures (compact) | Draft submitted 28 Aug 2025 |
| TBD | HQC | HQC | Backup key encapsulation | Selected Mar 2025 |
NIST submitted the FN-DSA draft for approval on 28 August 2025. An initial public draft and its comment period come before a final standard, and a final FIPS 206 is widely expected in late 2026 or early 2027. Treat any vendor claim of “FN-DSA support” today as pre-standard.
01 — At finalization
What actually changes when FIPS 206 lands
Less than most roadmaps assume. Finalization is a procurement and validation event, not a technical one for most organizations.
- Object identifiers and encodings freeze. Pre-standard Falcon deployments use interim OIDs and parameter encodings. Anything you built against a draft has to be re-issued, not just re-flagged. This is the same churn that hit early ML-DSA and SLH-DSA adopters between draft and final.
- FIPS 140-3 validation becomes possible. Modules cannot be validated against a standard that does not exist. Certificates start appearing months after finalization, not on the day, and that lag is usually the real gate on regulated deployment.
- CA and browser policy work begins. The CA/Browser Forum has to decide whether and where FN-DSA is permitted in publicly trusted hierarchies. That discussion follows the standard; it does not run ahead of it.
- Nothing changes for CNSA 2.0. NSA has said FN-DSA will not be added. For National Security Systems the answer is ML-DSA-87 and ML-KEM-1024, at those parameter sets only, and finalization of FIPS 206 does not move that.
02 — The case for it
The whole argument for FN-DSA is size
Post-quantum signatures are large. A TLS handshake carries several of them plus the public keys to verify them, and the resulting chain can push past the point where a handshake fits in the initial congestion window. That is the problem FN-DSA is for.
Signature size, bytes — drawn to scale
FN-DSA-512 signatures are roughly 3.6× smaller than ML-DSA-44’s. That gap compounds across every certificate in a chain, which is the case for using it at the root and intermediate tiers. It is also the only argument for it — and it is not free.
| Parameter set | Signature | Public key | NIST category |
|---|---|---|---|
| ECDSA P-256 | 64 | 33 | classical |
| RSA-2048 | 256 | 256 | classical |
| FN-DSA-512 | 666 | 897 | 1 |
| FN-DSA-1024 | 1,280 | 1,793 | 5 |
| ML-DSA-44 | 2,420 | 1,312 | 2 |
| ML-DSA-65 | 3,309 | 1,952 | 3 |
| ML-DSA-87 | 4,627 | 2,592 | 5 |
| SLH-DSA-128s | 7,856 | 32 | 1 |
The cost is on the signing side. FN-DSA signs using Gaussian sampling over floating-point arithmetic, and implementing that in constant time without leaking key material is materially harder than for the module-lattice schemes. That difficulty is the reason FIPS 206 is years behind the others.
Verification is unaffected — it is fast and straightforward. So the shape of the fit is specific: sign rarely, under controlled conditions, in hardware you trust; verify constantly, everywhere. That is a root or intermediate CA certificate. It is not high-volume online signing, and it is not a general replacement for ML-DSA.
03 — The actual clock
Signature urgency is about lifetime, not harvest-now-decrypt-later
Most post-quantum urgency arguments are about confidentiality: an adversary records encrypted traffic today and decrypts it once a cryptanalytically relevant quantum computer exists. That reasoning is sound, and it is why key establishment migration is the first priority.
It does not apply to signatures. Recording a signature today gives an attacker nothing; forgery requires the quantum computer to exist at the moment of the attack. So the question for signatures is not what was captured, it is what is still in force.
That reframes the inventory. A twenty-five year root CA certificate, a device firmware verification key burned into silicon, a code signing chain that has to validate a decade from now — those have to survive past any credible CRQC date, so they need a post-quantum answer now. A ninety-day TLS leaf certificate does not.
And the dates that will actually force action are procurement dates, not physics. CNSA 2.0 sets a January 2027 acquisition gate for National Security Systems, with exclusive use by 2033. NIST’s transition guidance deprecates 112-bit classical algorithms after 2030 and disallows them after 2035. Those are on calendars now.
04 — Do this now
What to inventory before FIPS 206 finalizes
None of this depends on FN-DSA. It is the work you would do anyway, and it is what determines whether finalization is a configuration change or a project.
- Every signing key, with its validity horizon. Sort by how long the artifact it signs must remain verifiable, not by how important the system feels. The long-lived roots are the ones with a deadline.
- Where signature size is already load-bearing.Constrained links, embedded devices, protocols with fixed-size fields, anything where the handshake is latency-sensitive. This is the shortlist of places FN-DSA would earn its complexity — and if the list is empty, you can stop tracking FIPS 206 entirely.
- Hardcoded algorithm assumptions. Fixed-length signature buffers, database columns sized for ECDSA, schemas that assume a 64-byte signature, parsers with hard limits. These surface late and break loudly.
- Your HSM and key management estate. Which modules have FIPS 140-3 validated ML-DSA today, which have a firmware path, and which are hardware you will have to replace. Lead times here are measured in quarters.
- Certificate issuance and rotation automation. Post-quantum migration means re-issuing more certificates more often. If rotation is manual anywhere, that is the bottleneck, and fixing it pays off regardless of which algorithm wins.
- Supplier and contractual exposure. Which of your vendors sign things you verify, and which of your customers verify things you sign. Their timelines become yours.
05 — Vendor conversations
What to ask your CA
These are written to be answerable with a date or a document. Anything that comes back as a posture statement is a non-answer.
Which post-quantum algorithms and parameter sets can you issue today?
You are listening for specific parameter sets. “ML-DSA” is not an answer; ML-DSA-44, -65 or -87 is.Are those implementations FIPS 140-3 validated, and under which certificate number?
Validated is a different claim from compliant or conformant. Ask for the number.What is your position on FN-DSA once FIPS 206 is final?
A credible answer distinguishes root and intermediate tiers from leaf issuance, and does not promise production support before finalization.Do you support hybrid or composite certificates, and until when?
Hybrids are the practical migration path for most estates. Get their sunset thinking too, not just the start date.What is your plan for the root, and what is the transition mechanism?
New post-quantum roots take years to reach ubiquitous trust stores. Cross-signing plans matter more than issuance capability.What breaks in our estate at your chain sizes?
Ask for measured handshake sizes for the chains they would actually issue you, not published algorithm figures.If we issue a post-quantum certificate today, what is the re-issue path when the profile changes?
Cost and mechanics of re-issuance, in writing. This is where the draft-to-final churn lands.
06 — Failure modes
What not to do
- Do not sequence your migration behind FN-DSA. ML-DSA is final, validated and deployable. Holding a signature programme for a draft standard buys a size optimization at the cost of years.
- Do not deploy pre-standard Falcon to production.The identifiers and encodings are not settled. You will re-issue everything, and you will do it on someone else’s schedule.
- Do not assume the highest parameter set is the right one. CNSA 2.0 requires category 5 for National Security Systems. General enterprise guidance sits at category 3. Defaulting to the largest everywhere inflates every handshake for no benefit.
- Do not treat this as a cryptography project. The work that takes the longest is inventory, automation and hardware lead time. The algorithm selection is the easy part and it is already mostly decided.
Get told when FIPS 206 moves
One email when the initial public draft is published, and one when the standard is final. Nothing else.
No tracking pixels in the emails. Unsubscribe in one click.
Questions
Common questions
Is FN-DSA finalized?
No. NIST submitted the FN-DSA draft standard for approval on 28 August 2025, and it has not been published as a final FIPS. An initial public draft and its comment period come first. A final FIPS 206 is widely expected in late 2026 or early 2027. ML-KEM, ML-DSA and SLH-DSA were finalized on 13 August 2024 and are the ones you can deploy today.
Should we wait for FN-DSA before migrating?
No. ML-DSA is the finalized general-purpose post-quantum signature standard, and it is what compliance regimes point at today. FN-DSA is a narrower optimization for cases where signature and public key size dominate. Waiting for it delays your entire signature migration to buy a size saving that only matters in specific places.
Is FN-DSA part of CNSA 2.0?
No, and NSA has said it will not be added. CNSA 2.0 requires ML-KEM-1024 and ML-DSA-87 exclusively, plus LMS or XMSS for firmware and software signing. If you sell into US National Security Systems, FN-DSA is not a compliance path and never will be.
Why did FN-DSA take so long?
Falcon's signing procedure relies on Gaussian sampling over floating-point arithmetic. Implementing it in constant time, without leaking key material through side channels, is materially harder than for the module-lattice schemes. Verification is not affected, which is why the algorithm is attractive on the verifying side and awkward on the signing side.
What is FN-DSA actually good for?
Root and intermediate CA certificates, and other places where an artifact is signed rarely under controlled conditions but verified constantly and carried over constrained links. Its signatures are roughly 3.6 times smaller than ML-DSA-44's, which compounds across a certificate chain. It is a poor fit for high-volume online signing.
Does harvest-now-decrypt-later apply to signatures?
No. Recording a signature today does not let an attacker forge one later. Signature migration urgency is driven by artifact lifetime instead: a root CA certificate, a firmware signing key or a long-dated code signing chain has to outlive the arrival of a cryptanalytically relevant quantum computer, so anything with a twenty-year horizon needs a post-quantum answer now.
pqcreadiness.ai is for sale
The domain is owned outright and can transfer to a serious buyer. Tell me who you are and what you have in mind, and you’ll get a straight answer on price and timing.
Or email pgaraca@gmail.com.
Buy it now on Sedo, where payment is held in escrow until the transfer completes.