![Post-Quantum Signatures: 9 Rivals vs 2 Final [2026]](https://shattered.io/wp-content/uploads/2026/11/post-quantum-signatures-nine-round-3-candidates-vs-ml-dsa-slh-dsa-2026-gen-1.webp)
NIST has two finished post-quantum signature standards, one more in development, and nine challengers still in the running. That is the state of post quantum cryptography signatures on November 10, 2026. ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) became final on August 13, 2024. FN-DSA, the Falcon-derived standard, has no public draft. On May 14, 2026, NIST named nine candidates for a third evaluation round of its additional-signature process. Meanwhile, the final NIST IR 8547 roadmap, published October 27, 2026, ties federal high-value systems to December 31, 2030 for key establishment and December 31, 2031 for digital signatures under Executive Order 14412.
Most coverage stops at the three finished standards. Developers who sign firmware, releases, certificates or documents need a wider map, because the signature side of the migration is the least settled part. Key exchange has one finished answer in ML-KEM. Signatures have two finished answers that trade size for conservatism, a third that is still unwritten, and a pipeline of newer designs that could shrink signatures further. For a head-to-head of the finished trio, see the existing breakdown of ML-KEM, ML-DSA and SLH-DSA. What follows covers the part that comparison leaves out: the pending standard, the nine round-3 rivals, and what to do while they settle.
One caveat shapes everything below. The research record behind this comparison carries no verified, cross-source benchmark numbers for the round-3 candidates, and no list prices exist for any of these algorithms. So the tables use confirmed dates, standard numbers, parameter-set names and status, and they describe performance trade-offs in words rather than inventing figures. Where a claim rests on a single report, the text says so.
Don't miss new tech stories on Google
Add Shattered once in the Google app and our stories show up in your news suggestions.
The Short Answer: Two Final, One Pending, Nine Candidates #
If you need a post-quantum signature in production today, you pick between ML-DSA and SLH-DSA. Nothing else is standardized. Current guidance for organizations that need a standardized post-quantum signature points to those two. ML-DSA is the general-purpose workhorse, derived from the CRYSTALS-Dilithium submission. SLH-DSA is the conservative backstop, derived from SPHINCS+, and it rests on hash functions alone instead of lattice assumptions.
FN-DSA is the planned third option. It descends from Falcon, which NIST selected during the third round of the original competition in 2022. FIPS 206 has not been released, no official draft has appeared, and no publication date is confirmed. One report cited by several vendors expects finalization in late 2026 or early 2027, but treat that as an expectation, not a schedule. Do not ship anything and call it FN-DSA compliant.
The nine round-3 candidates are FAEST, HAWK, MAYO, MQOM, QR-UOV, SDitH, SNOVA, SQIsign and UOV. They exist because ML-DSA and SLH-DSA share a weakness for some jobs: signatures and keys are large compared with what ECDSA and Ed25519 users are accustomed to. NIST’s stated aim is to augment FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), FIPS 186-5 and SP 800-208, not to replace them. Any winner arrives years after today’s deployments, which means your migration plan cannot wait for the contest to finish.
The practical split looks like this. Deploy ML-DSA where you need a default. Reach for SLH-DSA where you can tolerate larger and slower signatures in exchange for a smaller set of mathematical assumptions, such as long-lived firmware roots. Wait on FN-DSA and the round-3 field where compact signatures are a hard constraint, and build crypto-agility so you can swap later.
A quick decision filter helps. Ask whether the signature must verify in ten years, whether the signer can be updated, and whether the verifier runs on hardware you cannot patch. A yes on the first and a no on the last two pushes you toward SLH-DSA or a hybrid. A no on the first and a yes on the others means ML-DSA with a clean rotation path is almost always enough. Everything else is a refinement of those three questions.
Where NIST Stands on November 10, 2026 #
The big recent change is the finalization of NIST IR 8547, Transition to Post-Quantum Cryptography Standards, on October 27, 2026. Reports say it replaced the initial public draft from November 2024. The document is a roadmap, not a new algorithm. It does not revise FIPS 203, 204 or 205, and it does not name a new signature scheme. Its job is to turn the 2024 algorithm standards into dated migration steps. The authors listed on the NIST publication are Dustin Moody, Ray Perlner, Angela Robinson, Andrew Regenscheid and David Cooper.
For a side-by-side of what changed between draft and final, the earlier write-up on IR 8547 final versus draft goes line by line. The headline for signature users is the schedule. Quantum-vulnerable public-key algorithms, including RSA and elliptic-curve signatures, are to be deprecated after 2030 and disallowed under NIST standards and guidelines after 2035. Federal high-value assets and high-impact systems face the earlier Executive Order 14412 targets of December 31, 2030 for key establishment and December 31, 2031 for signatures.
Beyond that, NIST has kept side projects moving. In June 2026, NIST also published preliminary working drafts for adding post-quantum algorithms to the Personal Identity Verification standards, with ML-DSA among them.
What has not happened matters just as much. No newer version of FIPS 204 or 205 exists. HQC, the backup key-encapsulation scheme NIST picked in March 2025, is still not a final standard, and its target is 2027. FN-DSA is unpublished. A NIST news page dated November 5, 2026 listed standardization activity across several areas but carried no new signature standard. Anyone telling you a fourth signature standard is finished today is wrong.
A naming note saves confusion in code reviews and vendor questionnaires. Kyber, Dilithium, SPHINCS+ and Falcon are the submission names. The standardized names are ML-KEM, ML-DSA, SLH-DSA and, eventually, FN-DSA. Procurement documents that still say Dilithium are not wrong about the math, but auditors will expect the FIPS names.
Specs Table: ML-DSA vs SLH-DSA vs FN-DSA #
The table below compares the three NIST-track signature standards on attributes that the current record confirms. Byte sizes and timing figures are left out on purpose, since the verified sources for this comparison do not supply them. The FIPS documents themselves carry exact parameter tables, and you should read those before sizing storage or network budgets.
| Attribute | ML-DSA | SLH-DSA | FN-DSA |
|---|---|---|---|
| NIST document | FIPS 204 | FIPS 205 | FIPS 206 (planned, unpublished) |
| Formal title | Module-Lattice-Based Digital Signature Standard | Stateless Hash-Based Digital Signature Standard | No final title yet |
| Published | August 13, 2024 | August 13, 2024 | Not published |
| Submission name | CRYSTALS-Dilithium | SPHINCS+ | Falcon |
| Math family | Module lattices | Stateless hash-based | Lattice, Falcon lineage |
| Status on Nov. 10, 2026 | Final and active | Final and active | In development, no public draft |
| Role in NIST’s set | General-purpose signature | Hash-only alternative | Planned additional option |
| Deployable today | Yes | Yes | No |
| Parameter sets | Defined in FIPS 204 | Defined in FIPS 205, six more proposed in draft SP 800-230 | FN-DSA-512 and FN-DSA-1024 named in an IETF draft |
| Federal signature target | Dec. 31, 2031 (high-value and high-impact systems) | Dec. 31, 2031 (same scope) | Not applicable until published |
| Newest related item | PIV working drafts, June 2026 | SP 800-230 draft, April 13, 2026 | Fixed-point arithmetic proposal, reported Sept. 28, 2026 |
| Known usage limit | None stated in the record | Draft limited-use sets cap each key at 2^24 signatures | Final spec may differ from today’s Falcon code |
| Official price | None applies | None applies | None applies |
Two rows deserve a second look. The 2^24 cap applies only to the draft SP 800-230 parameter sets, which NIST designed for limited-signature cases such as software, firmware and certificate signing. The baseline FIPS 205 sets do not carry that restriction in the record. And the FN-DSA parameter names come from an IETF Internet-Draft for JOSE and COSE serialization dated November 1, 2026. That draft is not a NIST standard, so those names could change.
The Three Standards in Detail #
ML-DSA (FIPS 204): the default
ML-DSA is the finalized lattice-based signature standard, and NIST treats it as the general-purpose choice. It is active, not renamed, not retired, and no successor version has been announced. In June 2026 NIST published preliminary working drafts that fold post-quantum algorithms into the PIV standards for government identity credentials, which gives ML-DSA a concrete path into smart-card-style identity systems. Researchers have also described a threshold-signing protocol, reported on NIST-hosted pages under the name TALUS, that produces ordinary FIPS 204 signatures an unmodified verifier can check. Treat that as research, since only one source describes it.
For engineers, the appeal is boring in the best way. ML-DSA has a final standard, multiple library implementations and a federal deadline that makes buyers ask for it. The cost is size. Compared with ECDSA or Ed25519, both public keys and signatures grow substantially, which hits constrained protocols, certificate chains and anything that embeds signatures in tight packets. The existing comparison of ML-DSA and SLH-DSA puts the two finalized schemes next to each other on size and speed.
SLH-DSA (FIPS 205): the conservative backstop
SLH-DSA builds signatures from hash functions and nothing else. That makes its security argument easier to explain than lattice assumptions, and it is the reason NIST standardized it next to ML-DSA. The price is larger and slower signatures. NIST’s April 2026 draft SP 800-230 tries to soften that by proposing six extra parameter sets at security levels 1, 3 and 5. They aim at faster verification and smaller signatures for software, firmware and certificate signing, in exchange for a hard limit of 2^24 signatures per key.
That limit is a design signal. It tells you NIST sees a real market for hash-based signatures where a signer knows roughly how many signatures it will ever produce, such as a release-signing key used a few times a day. It is not a fit for a busy online signer. The NIST record does not confirm that SP 800-230 is final, so build against FIPS 205 and watch the draft.
FN-DSA (FIPS 206, planned): the compact option that is not ready
FN-DSA is the planned standardized name for Falcon. NIST selected Falcon in 2022, and the standard is still unfinished more than four years later. According to the QDay Countdown standards tracker, the latest reported design change, dated September 28, 2026, is a proposal to use fixed-point arithmetic for key generation and signing, with a single precisely specified signing procedure. That matters because Falcon’s floating-point operations have been a portability and side-channel worry for implementers. The deeper trade-offs are covered in the existing piece on FN-DSA versus ML-DSA.
Existing Falcon code should not be assumed compatible with the eventual FN-DSA text. One Rust crate, falcon-rs, is the sort of package people will be tempted to wire into products early. Resist that. Use Falcon only in experiments, and tag any such deployment so you can find and replace it once FIPS 206 lands.
The Nine Round-3 Candidates Explained #
NIST’s additional-signature process exists because the picks from the original competition left gaps. After a second round, NIST published IR 8610 on May 14, 2026 and moved nine schemes forward: FAEST, HAWK, MAYO, MQOM, QR-UOV, SDitH, SNOVA, SQIsign and UOV. Public trackers list the same nine, and NIST’s own page confirms the round-3 announcement date. Any eventual selection would augment, not replace, the standards already in place.
The family labels and trade-off notes in the next table are editorial analysis drawn from the public design of each scheme. They are not figures from IR 8610 and carry no measured sizes. Treat them as a reading guide to where each candidate sits, then check the submission documents for numbers.
| Candidate | Design family | Why it is interesting | Main watch-out |
|---|---|---|---|
| UOV | Multivariate (Unbalanced Oil and Vinegar) | Oldest design in the field, short signatures, fast verification | Large public keys |
| MAYO | Multivariate, UOV variant | Trades some signature size for a much smaller public key than plain UOV | Younger security analysis than UOV |
| QR-UOV | Multivariate, UOV variant | Uses a quotient-ring structure to shrink keys | Extra structure invites extra cryptanalysis |
| SNOVA | Multivariate, UOV variant | Small matrix-ring structure aimed at compact keys and signatures | Structured variants draw close cryptanalytic scrutiny |
| HAWK | Lattice, hash-and-sign | Falcon-like compactness with simpler arithmetic | Newer assumptions than module lattices |
| SQIsign | Isogeny-based | Very small keys and signatures | Signing has been the expensive operation |
| FAEST | Symmetric-key based (VOLE-in-the-head) | Security rests on AES-style primitives | Signatures larger than lattice and multivariate designs |
| SDitH | Code-based (MPC-in-the-head) | Relies on the syndrome decoding problem, unrelated to lattices | Larger signatures, heavier signing |
| MQOM | Multivariate quadratic (MPC-in-the-head) | Builds on a well-studied hard problem with a proof-style design | Larger signatures than direct multivariate schemes |
The candidates cluster into three bets. The multivariate group (UOV, MAYO, QR-UOV, SNOVA) bets on short signatures. The proof-style group (FAEST, SDitH, MQOM) bets on assumptions that look very different from lattices, which is exactly the hedge NIST said it wanted when it picked HQC as a backup for ML-KEM. HAWK and SQIsign bet on compactness from lattices and isogenies respectively.
For a developer, the most useful reading is about diversity. If a cryptanalytic result damages lattice schemes, ML-DSA and FN-DSA could take a hit together, since both live in the lattice family. SLH-DSA survives that scenario because it uses hashes. The round-3 field adds more escape routes. That is a reason to care about the contest even though none of the nine is deployable as a standard today.
Cryptanalysis history explains why NIST keeps a wide field. Several multivariate and isogeny proposals from earlier rounds of post-quantum competitions fell to attacks late in the process, sometimes after years of study. That record cuts both ways. It shows the evaluation process works, and it warns against betting a product roadmap on any scheme that has not survived long public scrutiny. A candidate reaching round three means it survived earlier rounds, not that it is safe to deploy.
Implementation maturity lags even further. A scheme needs constant-time code, side-channel review, fault-injection analysis and several independent implementations before security teams will sign off. ML-DSA and SLH-DSA have been through more of that process than any round-3 entrant. When a vendor pitches a compact scheme from this list, ask for the audit history and the versioning policy, because parameters may shift between rounds.
Benchmarks: What the Data Covers and Where It Stops #
Honest benchmarking of post-quantum signatures draws from three kinds of sources, and each one has blind spots. NIST’s own evaluation reports, including IR 8610, assess candidates on security, cost and performance as submitted. Submission teams publish reference and optimized implementations with their own timing tables. Open-source projects such as the Open Quantum Safe effort and the PQClean collection package many schemes behind one interface so you can measure them on your own hardware. A November 9, 2026 project release that mentions PQClean alongside ML-DSA, HQC, SLH-DSA and FN-DSA shows that maintenance and auditing work continues.
The blind spots are real. Submission-team tables come from different machines, compilers and optimization levels, so cross-scheme comparisons mislead. NIST reports measure candidates as submitted, and parameter sets shift between rounds. Library benchmarks vary with CPU instruction sets, side-channel countermeasures and whether the build uses constant-time code. And the FN-DSA fixed-point proposal means any Falcon timing from floating-point code may not describe the final standard at all. The research record here holds no cross-source numbers that survive those caveats, so this section gives none. A made-up leaderboard would be worse than no leaderboard.
What you can do is benchmark in your own environment, where the answer is the one that counts. The harness below uses the liboqs Python bindings, enumerates whichever signature mechanisms your build enables, filters by family name, and times key generation, signing and verification on your hardware. It hardcodes no scheme list, because enabled mechanisms depend on the build and on which candidates the library maintainers have added.
import time
import oqs
FAMILIES = ("ML-DSA", "SLH-DSA", "Falcon", "FN-DSA", "MAYO", "UOV", "SNOVA", "CROSS", "HAWK", "SQIsign")
MESSAGE = b"x" * 1024
RUNS = 50
def timed(fn, runs=RUNS):
start = time.perf_counter()
for _ in range(runs):
fn()
return (time.perf_counter() - start) / runs
for name in oqs.get_enabled_sig_mechanisms():
if not any(f in name for f in FAMILIES):
continue
with oqs.Signature(name) as signer:
public_key = signer.generate_keypair()
signature = signer.sign(MESSAGE)
keygen = timed(lambda: signer.generate_keypair())
sign = timed(lambda: signer.sign(MESSAGE))
with oqs.Signature(name) as verifier:
verify = timed(lambda: verifier.verify(MESSAGE, signature, public_key))
print(f"{name}: pk={len(public_key)}B sig={len(signature)}B "
f"keygen={keygen*1e3:.2f}ms sign={sign*1e3:.2f}ms verify={verify*1e3:.2f}ms")
Run it on the machines your signers and verifiers actually use, including the slowest one. A verifier on a microcontroller tells you more than a signer on a laptop. Record the library version, compiler flags and CPU model next to every result, and rerun after each library upgrade. For a worked example of size and speed in the finished trio against classical schemes, see the earlier comparison of ML-DSA, ECDSA and RSA signatures.
Capture more than a single average. Signing time for some lattice schemes varies from run to run because the algorithm retries internally, so report percentiles and worst cases, not only means. Track peak memory and stack depth, which decide whether a scheme fits on a small device. Measure the on-the-wire cost too: public key plus signature bytes per message, per certificate chain and per day of logs. And measure verification throughput under load, since in most systems verifiers outnumber signers by orders of magnitude.
Pricing and Cost: No Price Tag, Real Costs #
NIST standards carry no official price. The available NIST results show no product catalog, no paid license, and no commercial plan for ML-DSA, SLH-DSA, FN-DSA or any round-3 candidate as of November 10, 2026. NIST IR 8547 is a government technical roadmap, not a pricing document. Vendors will sell products that implement these algorithms, such as HSMs, signing services and libraries, but those prices belong to the vendors and fall outside the standards themselves.
| Option | Official price | Where the cost shows up |
|---|---|---|
| ML-DSA (FIPS 204) | None applies | Bandwidth and storage from larger keys and signatures, library upgrades, HSM firmware support |
| SLH-DSA (FIPS 205) | None applies | Signing time and signature size, plus key-usage tracking if you adopt the limited-use sets |
| FN-DSA (planned FIPS 206) | None applies | Rework risk if early Falcon code diverges from the final text |
| Round-3 candidates (nine) | None applies | Research-grade code, no standard, higher chance of parameter changes |
| Hybrid (classical plus PQC) | None applies | Two signatures to produce, carry and verify during the transition |
The expensive parts are labor and risk. Inventory work, protocol changes, test coverage and vendor coordination dwarf any license fee, and they scale with how many places your organization signs things. Teams that treat the migration as an architecture project cost less overall than teams that bolt on algorithms system by system. Larger signatures also raise operating costs in places people forget: log storage, CDN transfer, certificate transparency submissions and mobile data.
If a vendor quotes you a premium for post-quantum support, ask which standard and which parameter set it implements, whether the product has been validated against the final FIPS text, and how upgrades work once FN-DSA or other standards appear. Pay for agility, meaning the ability to swap algorithms, not for a single algorithm choice that may age.
Real-World Examples: Who Is Moving, and How Far #
Adoption evidence for signatures is thinner than for key exchange, and honest reporting says so. The examples below are the dated, checkable ones from the current record. Each shows a different stage of the pipeline.
- Federal identity credentials. In June 2026, NIST released preliminary working drafts for adding post-quantum algorithms to the PIV standards. NIST labels the material preliminary, so it signals direction, not a finished profile.
- Self-hosted identity software. The authentik project published a post on November 3, 2026 describinghow authentik is handling post-quantum cryptography . It is a useful read for teams running their own identity stack, and it reflects how open-source infrastructure vendors are framing the question.
- Threshold signing research. NIST-hosted work on TALUS, updated October 27, 2026, describes a threshold-signing protocol that yields standard ML-DSA signatures verifiable by an unmodified verifier. That matters for organizations that split signing authority across parties, though only one source describes it.
- Falcon code in the wild. The falcon-rs Rust crate reportedly reached 0.3.1 on August 31, 2026. Packages like it show demand for compact signatures ahead of the standard.
- Protocol drafts. An IETF draft dated November 1, 2026 defines FN-DSA serialization for JOSE and COSE, referring to FIPS 206 as expected in late 2026 or early 2027. Separately, an IETF draft describes HQC-based key exchange for TLS 1.3, including hybrids with ML-KEM and with X25519 and X448. The existing breakdown ofML-KEM versus HQC covers that key-exchange side.
- Shared libraries. A November 9, 2026 release of a project that bundles ML-DSA, HQC, SLH-DSA, FN-DSA and PQClean support shows maintainers treating all of them as live targets, even though two are unfinished.
The pattern across these examples is consistent. Standards bodies and infrastructure projects are building plumbing for ML-DSA first, SLH-DSA second, and Falcon in a holding pattern. Round-3 candidates appear mostly in research and library catalogs. If you are waiting for a mature ecosystem around a round-3 scheme before you plan, you will wait past the 2031 signature deadline for federal systems.
Protocol work deserves special attention because signatures travel inside formats. JOSE and COSE carry tokens and attestations. Certificates carry signatures in chains. Update frameworks bundle signatures with firmware images. Every one of those formats needs an algorithm identifier registered, and that registration process lags the cryptography. The IETF drafts above are the visible edge of a long queue, and teams that depend on a given format should check whether the identifier they need exists yet.
What NIST’s Own People Said About Backups and Timing #
The March 2025 announcement of HQC is the clearest statement of NIST’s philosophy on backups, and it applies equally to the signature contest. In that announcement, Dustin Moody, head of NIST’s post-quantum cryptography project at the time, told the public: “We are announcing the selection of HQC because we want to have a backup standard that is based on a different math approach than ML-KEM.” The reasoning maps directly onto signatures. A second standard on different mathematics is insurance, not a replacement.
In the same announcement, Moody explained the risk being insured against: “As we advance our understanding of future quantum computers and adapt to emerging cryptanalysis techniques, it’s essential to have a fallback in case ML-KEM proves to be vulnerable.” Swap ML-KEM for ML-DSA and the logic holds for signatures, which is why SLH-DSA sits beside ML-DSA and why the round-3 field includes hash, code and symmetric-key designs.
On timing, the same March 2025 statement said: “Organizations should continue to migrate their encryption systems to the standards we finalized in 2024.” That quote is more than a year old, and it predates IR 8547, but the October 2026 roadmap reinforces it with hard dates. The message for signature owners is the same as for encryption owners. The finished standards are the ones to migrate to, and additional standards are for later.
One more point comes from the facts rather than a quote. NIST wrote in its May 2026 round-two status report that any future selections would augment FIPS 204, FIPS 205, FIPS 186-5 and SP 800-208. FIPS 186-5 is the existing digital signature standard covering RSA, ECDSA and EdDSA, and SP 800-208 covers stateful hash-based signatures such as LMS and XMSS. NIST is clearly planning for a portfolio, not a single winner.
The 2030, 2031 and 2035 Deadlines for Signatures #
Deadlines drive budgets, so they deserve their own table. The 2030 and 2031 dates come from Executive Order 14412 as summarized in reports on the final IR 8547, and they apply to federal high-value assets and high-impact systems. The 2035 date is the broader NIST disallowance horizon. A Futurex analysis of the NIST and NSA timelines frames what these dates mean for enterprise crypto agility, and its reading matches the dates below.
| Date | Milestone | Who it affects |
|---|---|---|
| August 13, 2024 | FIPS 203, 204 and 205 finalized | Everyone, standards available |
| November 2024 | IR 8547 initial public draft (reported) | Planners following the transition |
| March 11, 2025 | NIST selects HQC as a backup key-establishment scheme | Key-exchange designers |
| April 13, 2026 | Draft SP 800-230 released, six extra SLH-DSA sets | Firmware and software signers |
| May 14, 2026 | Nine round-3 signature candidates named, IR 8610 published | Signature researchers and implementers |
| June 12, 2026 | SP 800-230 comment period closed | Reviewers |
| October 27, 2026 | IR 8547 final published | Federal agencies and their suppliers |
| 2027 | HQC final standard targeted, new commercial national security systems must support quantum-resistant algorithms (reported) | Key-exchange designers, NSS vendors |
| December 31, 2030 | Federal high-value and high-impact systems: key establishment migrated | Federal systems |
| After 2030 | Quantum-vulnerable public-key algorithms deprecated | All NIST-aligned users |
| December 31, 2031 | Federal high-value and high-impact systems: digital signatures migrated | Federal systems and signature suppliers |
| After 2035 | Quantum-vulnerable algorithms disallowed under NIST standards and guidelines | All NIST-aligned users |
Signatures have a quirk that pushes some deadlines earlier in practice. A signature you create today must stay verifiable for as long as the thing it protects lives. Firmware signed with RSA today and shipped on devices that run for a decade or more needs a plan well before 2035. Long-lived roots of trust, code-signing certificates and archival document signatures should move first. By contrast, short-lived session authentication has less urgency than the key-exchange side, where harvest-now-decrypt-later attacks already create risk.
For teams who want the finer points on what disallowance means for RSA and ECDSA, the dedicated write-up on RSA and ECDSA after 2035 walks through the replacement mapping. Hybrid deployment, where a classical and a post-quantum signature travel together, is described in IR 8547 as an option during the transition. NIST does not demand an immediate single-algorithm swap in every deployment.
Suppliers to federal agencies should read the dates as contract language. An agency owner facing a 2031 signature target will ask vendors for roadmaps in 2027 and 2028, which means your product plans for ML-DSA or SLH-DSA support need dates well before the deadline. Non-federal teams that sell into regulated industries tend to inherit the same expectations through procurement, even without a legal mandate.
Use-Case Recommendations #
These recommendations follow from the status and trade-offs above. They are editorial judgment, not NIST guidance, and each assumes you start with the finished standards.
- Firmware and software release signing. Use SLH-DSA or a hybrid of a classical scheme and ML-DSA. Signing is infrequent, so slower signatures hurt little, and the hash-only security argument suits keys that live for a decade. Watch draft SP 800-230 if your signing volume stays well below its per-key cap. For a ranked look at the options, see the existing guide topost-quantum firmware signing .
- Web PKI and certificate chains. Start with ML-DSA in test environments. Large signatures inflate handshakes and chains, so measure the effect on latency before you plan rollouts. Do not wait for FN-DSA to begin testing, but avoid committing production chains to unfinished schemes.
- Government identity and PIV-style credentials. Track NIST’s PIV working drafts and plan around ML-DSA. The June 2026 drafts are preliminary, so build abstraction layers instead of hardcoding choices.
- Constrained IoT and bandwidth-limited links. This is where FN-DSA and the compact round-3 candidates matter. Today, you have two choices. Use ML-DSA and accept the overhead, or keep classical signatures behind a short-lived hybrid with a migration date. Do not field unstandardized schemes on devices you cannot update.
- Long-term document and archive signing. Prefer SLH-DSA for its conservative assumptions and combine it with periodic re-signing or timestamping. Archives outlive algorithms, so metadata about which algorithm signed what is as important as the signature.
- Multi-party and custody signing. Watch threshold work around ML-DSA, such as TALUS, but treat it as research until multiple independent sources confirm a stable design.
- Vendors and platform teams. Push suppliers for written support for FIPS 204 and 205, a published plan for FIPS 206, and a documented way to rotate algorithms without replacing hardware.
One theme repeats across all seven. The correct answer to “which signature should I pick” depends less on raw speed than on how long the signature must stay trustworthy, how often you sign, and whether the verifier can be updated. Answer those three questions per system and the choice usually becomes obvious.
Migration Guide: From RSA and ECDSA to Post-Quantum Signatures #
NIST’s IR 8547 puts the early work in order: inventory, strategy, awareness and training during 2026 and 2027, then implementation. A practical sequence for a signature-heavy organization follows. The wider cryptography coverage in the cryptography section collects the surrounding standards.
Step 1: Inventory every signing and verifying system. List certificate authorities, code-signing pipelines, firmware update paths, JWT and SAML issuers, document-signing tools, SSH keys, and vendor appliances. Record the algorithm, key owner, key lifetime and who verifies. Start with a simple search of repos and configs to find hardcoded algorithms:
grep -RInE "RSA|ECDSA|Ed25519|secp256|rsa-sha|RS256|ES256|EdDSA" \
--include="*.go" --include="*.py" --include="*.java" --include="*.rs" \
--include="*.yaml" --include="*.yml" --include="*.json" --include="*.tf" . \
| tee signature-inventory.txt
Step 2: Rank by lifetime and exposure. A firmware root that signs devices shipping for years outranks a token issuer rotating keys weekly. Mark anything that must stay verifiable past 2031.
Step 3: Introduce algorithm agility. Put the algorithm identifier in your data formats, not in code constants. Make verifiers accept multiple algorithms and make signers emit more than one when needed. Crypto-agility is the capability that makes every later step cheaper.
Step 4: Pilot hybrids. Sign with a classical scheme and ML-DSA (or SLH-DSA for firmware roots) at the same time, and require both to verify during the pilot. IR 8547 discusses combining conventional and post-quantum cryptography during the transition. Hybrids cost extra bytes, so measure them with the harness shown earlier.
Step 5: Test size-sensitive paths. Push larger signatures through every protocol, database column, log pipeline, HSM interface and embedded buffer. Many failures will be mundane, such as a fixed-length field or a message-size limit.
Step 6: Update key management. Check that HSMs, KMS services and signing appliances support the finalized FIPS 204 and 205 text and have an upgrade path. Ask vendors for written dates.
Step 7: Roll out in tiers. Start with internal and low-risk systems, then move to externally visible ones, with classical fallbacks until verifiers are updated. Keep rollbacks cheap.
Step 8: Prepare for FN-DSA and later standards. Keep a slot in your agility layer for FIPS 206. Do not backport unfinished Falcon code into production paths. Revisit after NIST publishes a draft.
Step 9: Track the calendar. Federal suppliers should map their systems to the 2030 and 2031 targets. Everyone else should treat 2030 deprecation and 2035 disallowance as the outer bounds for NIST-aligned buyers.
Three mistakes recur in early migrations. Teams hardcode an algorithm name in a database schema, then discover the new signature will not fit the column. Teams enable a post-quantum scheme on the signer but forget that a downstream verifier, often a third party, rejects the unfamiliar identifier. And teams keep no record of which algorithm signed which artifact, so they cannot tell later which archives need re-signing. The inventory in step 1 and the agility layer in step 3 prevent all three.
Pros and Cons of Each Path #
ML-DSA (FIPS 204)
- Pro: Final standard, general-purpose design, active federal migration support.
- Pro: Broadest implementation and tooling momentum among the post-quantum signatures.
- Con: Keys and signatures much larger than ECDSA or Ed25519.
- Con: Shares the lattice family with FN-DSA, so a lattice break would hit both.
SLH-DSA (FIPS 205)
- Pro: Hash-only security argument, no reliance on lattice assumptions.
- Pro: Stateless, so no state-tracking mistakes that plague stateful hash signatures.
- Con: Larger and slower signatures than ML-DSA.
- Con: The more compact SP 800-230 sets remain a draft and carry a per-key cap of 2^24 signatures.
FN-DSA (planned FIPS 206)
- Pro: Intended as a compact signature option alongside ML-DSA and SLH-DSA.
- Pro: The reported fixed-point proposal targets Falcon’s floating-point portability problems.
- Con: No public draft, no confirmed publication date, existing code may not match the final text.
- Con: Cannot be used in compliance-driven deployments today.
Round-3 candidates (FAEST, HAWK, MAYO, MQOM, QR-UOV, SDitH, SNOVA, SQIsign, UOV)
- Pro: Cover several math families, adding diversity beyond lattices and hashes.
- Pro: Several aim at smaller signatures or keys than the finished standards.
- Con: No standard, no guaranteed winner, and parameters can change.
- Con: Newer designs have had less cryptanalysis than lattices or hash-based schemes.
Verdict: Ship ML-DSA and SLH-DSA, Watch the Rest #
The data points to a clear call. For production signatures in November 2026, choose between two finalized standards, ML-DSA for default use and SLH-DSA for long-lived, low-volume signers such as firmware roots. Both reached final status on August 13, 2024, both are tied to the federal 2031 signature target, and neither has been renamed, retired or superseded.
FN-DSA earns a watch rating. It has been in development for years with no public draft, and the reported fixed-point proposal suggests the final text may differ from existing Falcon code. Plan a slot for it. Do not build around it. The nine round-3 candidates earn a research rating. They could change the picture for compact signatures in the early 2030s, but NIST has said any winners will augment the current standards, and no timeline exists for their selection.
The takeaway: the winning move is agility, not algorithm prophecy. Teams that can swap a signature algorithm in weeks will handle FN-DSA, SP 800-230 and any round-3 selection with little fuss. Teams that hardcode RSA, or hardcode any single post-quantum scheme, will repeat this migration. Start the inventory this quarter, pilot hybrids in the next, and hold the 2030 and 2031 dates in view.
Frequently Asked Questions #
Which post quantum cryptography signature standards are final today?
Two: ML-DSA in FIPS 204 and SLH-DSA in FIPS 205, both finalized on August 13, 2024. FN-DSA, expected to become FIPS 206, is not published.
Is Falcon the same as FN-DSA?
FN-DSA is the planned standardized name for the Falcon-derived signature scheme. Falcon is the pre-standardization name. Existing Falcon implementations should not be assumed to match the eventual FN-DSA specification.
What are the nine round-3 signature candidates?
FAEST, HAWK, MAYO, MQOM, QR-UOV, SDitH, SNOVA, SQIsign and UOV. NIST announced them on May 14, 2026 alongside IR 8610.
Will a round-3 candidate replace ML-DSA?
NIST’s status report says future selections would augment FIPS 204, FIPS 205, FIPS 186-5 and SP 800-208, not replace them. No selection date has been announced.
When do federal systems have to move to post-quantum signatures?
Under Executive Order 14412 as summarized for the final IR 8547, federal high-value assets and high-impact systems have a December 31, 2031 target for digital signatures and December 31, 2030 for key establishment. NIST’s roadmap deprecates quantum-vulnerable public-key algorithms after 2030 and disallows them after 2035.
What does SP 800-230 change for SLH-DSA?
The April 13, 2026 initial public draft proposes six additional parameter sets at security levels 1, 3 and 5. They give faster verification and smaller signatures for software, firmware and certificate signing, but cap each signing key at 2^24 signatures. The record does not confirm that it is final.
Do post-quantum signatures cost money to license?
NIST publishes the standards without a price, and no official price applies to any of the algorithms covered here. Costs come from implementation, testing, hardware support and larger data sizes. Check vendor terms and any intellectual-property questions with your own counsel.