What NIST IR 8610 Third Round PQC Candidates Mean for Security Architects

On May 14, 2026, NIST published NIST IR 8610, announcing that nine digital signature candidates have advanced to the third round of its Additional Digital Signatures standardization process. After 18 months of evaluation and the elimination of five candidates, nine algorithms spanning four distinct mathematical families remain in evaluation.

This is not a routine process update. This blog takes a technical look at the nine candidates, their mathematical foundations, the cryptanalytic events that shaped round two, and what security architects and migration planners should take away.

Why NIST Launched This Process in the First Place

NIST finalized two post-quantum signature standards, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205), while a third, FN-DSA (FIPS 206), is undergoing standardization with its final publication expected in late 2026 or early 2027. That looks like substantial coverage until you examine the mathematical foundation these three standards rest on.

For a detailed breakdown of Categories 1–5, their AES/SHA reference points, and deployment guidance, see NIST Post-Quantum Cryptography Security Levels: A Guide to Categories 1–5.

ML-DSA is lattice-based, built on the assumed hardness of Module-LWE and Module-SIS problems. FN-DSA is also lattice-based, but draws its security from a different foundation: the hardness of finding short vectors in NTRU lattices. Both are structured-lattice schemes, which means they share a common mathematical family while relying on distinct hardness assumptions. SLH-DSA is hash-based, which provides an independent security foundation, but at a performance cost.

For reference, SLH-DSA-128 (the Category 1 parameter set) produces signatures ranging from 7,856 bytes in the compact variant up to 17,088 bytes in the fast variant. If a cryptanalytic breakthrough compromised structured lattice assumptions, whether classically or with a sufficiently capable quantum computer, two of NIST’s three signature choices would fall simultaneously, leaving SLH-DSA as the only remaining option in a role it was never designed to carry alone.

History gives this concern real weight. Rainbow, a multivariate signature scheme that reached the finalist stage of the original NIST PQC process, was broken in 2022 following a cryptanalytic advance that caught the community by surprise. SIKE, an isogeny-based key encapsulation mechanism was broken during round four of NIST scrutiny, the same year using a classical attack by Castryck and Decru. Lattice cryptography has been studied more extensively than either of those schemes, but putting all your trust in one mathematical family is still a risk.

Beyond portfolio diversity, there is a concrete performance problem. ML-DSA-44 (the Category 2 parameter set) produces signatures of 2,420 bytes. FN-DSA-512 produces approximately ~666 bytes per the current Falcon specification. Compare those to the 64 bytes of ECDSA P-256 (which expands to 71–72 bytes when DER-encoded), and the size increase in migrating to post-quantum signatures becomes immediately apparent. For most standard internet applications (TLS over high-bandwidth connections and code signing for general-purpose systems), these sizes are manageable if inconvenient. For others, they are hard blockers.

DNSSEC is one example. DNSSEC validation chains stack signatures through root, TLD, and second-level domain records, and responses have historically been engineered around 512-byte UDP packets. Using ML-DSA signatures in DNSSEC would push nearly every response out of UDP and into connection-oriented transport, significantly complicating an infrastructure that was deliberately designed to be lightweight.

Constrained IoT and OT environments face the same problem from a different angle. Legacy fieldbus protocols with fixed message sizes, 8-bit microcontrollers with limited RAM, and safety-critical control systems with tight timing requirements cannot simply absorb a several-kilobyte signature appended to every command. For these environments, a compact post-quantum signature is not a performance optimization. It is the condition that determines whether deployment is possible at all.

NIST’s Call for Additional Digital Signatures, issued in September 2022, was explicit about both motivations. The process received 50 submissions, accepted 40 into the first round, advanced 14 to the second round, and now has nine entering the third.

The Nine Survivors and Their Mathematical Foundations

The nine third-round candidates span four distinct mathematical families. Each family brings a different hardness assumption to the table, and that diversity is the whole point. A breakthrough against one family leaves the others standing. The table below gives a snapshot of where each candidate stands heading into the third round, organized by mathematical family rather than alphabetical order, so the structural relationships between candidates are immediately visible.

Algorithm	Family	Round 3 Status	Key Advantage	Key Tradeoff	NIST Confidence Note
FAEST	MPC-in-the-Head (VOLEitH)	Selected	Security relies primarily on well-established symmetric primitives (AES); competitive MPCitH performance	Complex design and recently updated security proofs require continued community verification	NIST found most confidence in FAEST’s security among the MPCitH candidates
MQOM	MPC-in-the-Head (TCitH)	Selected	Strongest performance numbers among MPCitH candidates; at all three security levels it offers the smallest total public-key and signature sizes in the MPCitH category	ROM and QROM security proofs may not yet be considered mature or complete	NIST found MQOM to have the strongest performance numbers among MPCitH candidates
SDitH	MPC-in-the-Head (VOLEitH)	Selected	Security based on the syndrome decoding problem for unstructured linear codes over the binary field, one of the most extensively studied problems in the MPCitH category	Higher computational cost than peers	Hardness assumption is one of the most conservative among its peers
HAWK	Lattice-based	Selected	555-byte signatures at Category 1; smaller than Falcon and ML-DSA; integer-only arithmetic	Further analysis of smLIP in cyclotomic number fields is needed	Selected for strong performance and implementation simplicity
SQIsign	Isogeny-based	Selected	Smallest combined key and signature sizes among all candidates; signatures as low as 148 bytes	Higher signing latency; fully constant-time signing remains a goal	Increased maturity and unique compactness justified advancement
UOV	Multivariate	Selected	Signatures as small as 96 bytes; very fast verification; decades of study	Expanded public keys exceed 200 KB; NIST is primarily interested in UOV’s suitability for certain applications rather than as a general-purpose signature scheme	Long-standing history and continued existence of unbroken parameter sets support further evaluation
MAYO	Multivariate	Selected	Smaller public keys than standard UOV; balanced profile suitable for general-purpose use	Wedge attack caused 28-bit security deficiency in MAYO2 Category 1 parameters	Attractive balanced performance, but parameter-selection risks highlighted by recent attacks
QR-UOV	Multivariate	Selected	Resistant to wedge attacks affecting other UOV variants; public keys roughly 15–50% of standard UOV	Public keys remain larger than MAYO and SNOVA	No attacks decreased QR-UOV’s security during the second round
SNOVA	Multivariate	Selected	Potentially very small public keys and signatures; competitive with Falcon-class performance on proposed parameters	Significant history of cryptanalysis; most original parameter sets broken	NIST does not consider SNOVA to have reached a stable form and expects a longer path toward possible standardization

MPC-in-the-Head: FAEST, MQOM, and SDitH

MPCitH schemes prove knowledge of a secret key by simulating a multi-party computation inside a zero-knowledge proof, then converting it to a non-interactive signature via the Fiat-Shamir transform. Security can rest on symmetric primitives rather than novel algebraic assumptions, but the resulting signatures are large, running to several kilobytes at Category 1.

FAEST grounds its security in AES via the Vector Oblivious Linear Evaluation in-the-Head (VOLEitH) framework. The signing key is an AES key; the signature proves knowledge of the key, mapping a public input to a public output. NIST has stated the highest confidence in FAEST’s security assumptions of any candidate in the MPCitH category. Tradeoff: signatures range from approximately 3.9 KB to 5.9 KB at Category 1, depending on parameter set, though all variants beat SLH-DSA.

MQOM uses Threshold Computation in the Head over the multivariate quadratic (MQ) problem. It had the smallest combined public-key-plus-signature sizes of any MPCitH candidate across all three security levels in Round 2. Tradeoff: security proofs in the Random Oracle Model and Quantum Random Oracle Model are still maturing, flagged explicitly by NIST.

SDitH applies MPCitH to the syndrome decoding problem for random linear codes, an assumption studied since the 1970s. Among MPCitH candidates, only FAEST can claim a comparably well-analyzed foundation. Tradeoff: slower than its MPCitH peers.

Multivariate: UOV, MAYO, QR-UOV, and SNOVA

All four are variants of Unbalanced Oil and Vinegar (UOV), introduced in 1999. The appeal is signature compactness: UOV produces 96-byte signatures at Category 1, approaching ECDSA-class sizes. The cost is public key size, which in the classic expanded construction runs to approximately 272 KB at Category 1; the compressed variant (uov-Ip) is approximately 43 KB. MAYO, QR-UOV, and SNOVA are compression variants that trade different degrees of public-key reduction against various structural constraints.

The second round brought a major cryptanalytic event. The wedge attack (Ran, 2025) uses exterior products to expose the hidden oil subspace in characteristic-2 fields, pushing three of UOV’s four original parameter sets below their security targets and costing MAYO’s Category 1 set exactly 28 bits. SNOVA was hit hardest, with most of its parameter sets broken. QR-UOV was immune: its odd-characteristic fields are structurally incompatible with the attack.

NIST advanced all four candidates because no successful attack has broken the core UOV design, using odd-characteristic fields appears to improve security, and their potential for very small signatures is unmatched. However, NIST has noted that the multivariate family will take longer to standardize, and SNOVA is still not considered fully stable.

Isogeny-Based: SQIsign

SQIsign produces 148-byte signatures at Category 1, giving it the smallest combined public key and signature size of any candidate in the process, and smaller than RSA-2048 signatures. For bandwidth-constrained applications such as DNSSEC, Roughtime, and IoT firmware signing, that size matters concretely.

Security rests on the hardness of computing isogenies between supersingular elliptic curves and determining their endomorphism rings. The scheme underwent a major architectural overhaul for Round 2, switching from a KLPT-based approach to higher-dimensional isogenies, which improved signing speed approximately 20x and verification approximately 6x. The SIKE break in 2022 is frequently cited as a concern; SQIsign avoids the structural vulnerability that enabled that attack, but the isogeny field is still young, and the analyst pool is limited.

Two open issues remain heading into Round 3: security proofs need broader community verification, and fully constant-time signing has not been achieved. Partial side-channel leakage during signing has been shown to enable key recovery.

Lattice-Based: HAWK

HAWK is the only lattice-based candidate in the process, but it earns its place by solving a specific problem neither ML-DSA nor FN-DSA addresses. FN-DSA requires floating-point arithmetic for its Gaussian sampling, making constant-time implementation difficult on hardware without floating-point units. HAWK uses integer-only arithmetic throughout, producing 555-byte signatures at Category 1, smaller than both FN-DSA-512 and ML-DSA-44.

The tradeoff is that HAWK’s security rests on two newer assumptions: the Search Module Lattice Isomorphism Problem (smLIP) and the One-More-Shortest-Vector Problem (omSVP). Both were subject to cryptanalytic attention in Round 2. The HAWK team addressed a definitional issue in the omSVP formulation; advances in attacking smLIP variants were made, but do not currently apply to the cyclotomic fields HAWK uses. Further analysis of both assumptions is the stated Round 3 priority.

That covers all nine candidates who made it through. Before turning to what the advancement means for migration planning, it is worth understanding the five that did not make it, because the reasons tell you as much about NIST’s priorities as the selections themselves.

What Did Not Advance and Why

Understanding who did not advance is as important as knowing who did. The five eliminated candidates reveal exactly what NIST weighted most heavily when the field was competitive. In each case, the decision came down to some combination of security uncertainty, performance shortfall, or consolidation in an overcrowded category.

Candidate	Family	Primary Reason for Elimination per NIST IR 8610
CROSS	Code-based (Restricted Syndrome Decoding)	Small public keys but very large signatures, much like SLH-DSA. The underlying security problem has a much shorter history of study than SLH-DSA’s. A second-round attack led the team to update its parameters, combining security uncertainty with less competitive performance.
LESS	Code-based (Linear Code Equivalence)	Small signatures but very large public keys, and much slower than CROSS for key generation, signing, and verifying. A second-round attack brought the understanding of its security into question.
Mirath	MPCitH (MinRank, merger of MIRA and MiRitH)	Performance profile overlapped sufficiently with competing MPCitH candidates. NIST chose to prioritize candidates that offer more established security assumptions or a superior performance profile relative to the remaining MPCitH options.
PERK	MPCitH (Permuted Kernel)	FAEST offers superior speed and relies solely on AES. NIST did not select PERK based on practical performance trade-offs. NIST noted this decision should not be interpreted as a lack of confidence in the underlying Permuted Kernel Problem.
RYDE	MPCitH (Rank Syndrome Decoding)	To avoid standardizing multiple schemes with very similar operational trade-offs, NIST chose to prioritize candidates that demonstrated the most robust combination of performance and community-wide analysis.

The third-round selections and eliminations together reflect the current state of the cryptographic community’s confidence across the post-quantum signature landscape. For security teams running live migration programs, the more immediate question is what any of these changes mean for the work already underway.

What This Means for PQC Migration Planning

The immediate priority has not changed. ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) are finalized standards. FN-DSA (FIPS 206) is selected, with a draft expected in late 2026 and finalization likely in 2027. These are the standards to migrate toward now.

For organizations subject to NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0, issued September 2022), none of the third-round additional signature candidates are covered by existing mandates. CNSA 2.0 requires ML-KEM-1024 for key establishment and ML-DSA-87 for digital signatures, with timelines running from 2027 for new National Security Systems through 2030 to 2033 for legacy infrastructure. Government contractors and defense industrial base organizations should focus migration efforts on completing those obligations on the published schedule and treat the additional signature candidates as future portfolio additions.

The existence of this process carries a practical implication for system architecture: crypto-agility matters more, not less. NIST running a parallel evaluation to find alternatives to its own recently published standards reflects a simple reality: the post-quantum field is still evolving. Systems deployed today must be designed for algorithm substitution without requiring architectural overhaul.

The signature size problem is real. If SQIsign achieves constant-time signing, its 148-byte signatures would be transformative for bandwidth-constrained protocols like DNSSEC and Roughtime. If HAWK’s newer lattice assumptions hold, it offers a practical integer-arithmetic alternative for constrained hardware that cannot safely run FN-DSA. If the multivariate family stabilizes through odd-characteristic reparameterization, it brings near-ECDSA signature sizes into the post-quantum world.

Those are significant open questions. Migration planning should be built around current standard sizes and treat future compact options as potential improvements to incorporate once standardized, not as dependencies to wait for.

One important distinction on urgency: digital signatures are not subject to the Harvest Now, Decrypt Later threat model in the same way that encryption is. An adversary who records your encrypted traffic today can attempt to decrypt it later when quantum computing matures. They cannot harvest your signed documents and retroactively forge signatures once quantum computers arrive, because forgery would require real-time cryptanalytic capability at the time of signing.

The related threat for signatures is sometimes called Trust Now, Forge Later: long-lived signatures on firmware, legal documents, or root certificates that must remain trusted for decades are vulnerable to future forgery by a cryptographically relevant quantum computer. The urgency of migrating signature schemes is real, but it differs from the immediacy of the encryption case.

What to Track in the Third Round

The third round officially began May 14, 2026, and is expected to last approximately two years. Four questions will define how it unfolds.

The most significant issue is whether the multivariate candidates can stabilize their security after the wedge attack. Updated parameter sets targeting odd-characteristic fields are due by August 14, 2026. How those parameters hold up under concentrated third-round cryptanalysis is not yet known.

For SQIsign, the question is whether constant-time signing can be achieved. The compact signature sizes were compelling enough for NIST to advance the scheme despite this open problem, but resolving it is a prerequisite for standardization.

For the MPCitH candidates, FAEST, MQOM, and SDitH, the question is whether the broader research community can verify and strengthen the security proofs. Both Threshold Computation in the Head and VOLE-in-the-Head were incorporated during the second round, and the resulting proofs are complex and relatively fresh.

For HAWK, the question is whether the smLIP and omSVP assumptions hold under sustained third-round scrutiny. If they do, HAWK fills a genuine gap: compact, integer-arithmetic lattice signatures for hardware that cannot safely run FN-DSA.

The nine candidates that survived reflect a methodical effort to build real cryptographic depth. Not redundancy for its own sake, but genuine mathematical diversity that keeps alternatives available as the post-quantum ecosystem matures.

How Can Encryption Consulting Help

If you are wondering where and how to begin your post-quantum journey, Encryption Consulting is here to support you. You can count on us as your trusted partner, and we will guide you through every step with clarity, confidence, and real-world expertise.

We begin with a Cryptographic Discovery and Inventory, scanning your entire environment to identify certificates, keys, algorithms, and protocols across endpoints, applications, APIs, and infrastructure. This builds the baseline you need before any migration can begin.

From there, we conduct a PQC Assessment to evaluate your exposure to quantum threats, identify RSA- and ECC-dependent systems, and deliver a prioritized report of vulnerable assets with risk severity ratings.

With that clarity, we develop a PQC Strategy and Roadmap, a phased migration plan aligned to your risk appetite, regulatory requirements, and long-term security goals, including cryptographic agility so your systems can adapt as standards evolve.

We then support Vendor Evaluation and Pilot Testing, helping you select the right tools, run proof-of-concept tests, and validate interoperability before any full-scale rollout.

Finally, we manage Full Implementation, deploying hybrid classical and quantum-safe models, rolling out PQC across your PKI and infrastructure, and setting up monitoring for long-term cryptographic health.

CBOM Secure

Encryption Consulting’s CBOM Secure tool plays a key role in helping organizations prepare. Instead of dealing with spreadsheets, manual OpenSSL outputs, or scattered configuration files, our CBOM tool gives a clear view of crypto usage across environments. It shows which algorithms are in use, what needs to change for post-quantum security, and whether systems meet security goals. For organizations getting ready for board meetings, architecture choices, or compliance planning, our tool provides clarity and speed.

Our CBOM Secure is more than just a reporting tool; it also speeds up the process. It automates crypto inventories, checks TLS configurations, validates algorithms, and aligns policies, so teams can move from discovery to action without guessing. In future releases, Encryption Consulting plans to add automated fixes, cloud-native integrations, and policy enforcement to keep configurations in line with security standards at all times.

Now is a great time to get started: test PQC in a staging environment, map your current crypto usage, and begin creating internal policies. If your organization wants to pilot quantum-safe projects, give feedback, or help shape new features, we at Encryption Consulting encourage you to reach out. The earlier the teams start, the easier the long-term work will be.

Conclusion

NIST advancing nine third-round candidates is not a signal that the post-quantum signature problem is nearly solved. It is a signal that NIST is taking portfolio risk seriously enough to run a parallel track for alternatives while its primary standards are still rolling out.

The migration priority is unchanged: move to ML-DSA, FN-DSA, and SLH-DSA. Nothing in this pipeline changes that. But build for crypto-agility, because if SQIsign resolves its constant-time signing problem, or HAWK’s assumptions hold, or the multivariate family stabilizes, the organizations that are designed for algorithm substitution will be able to adopt compact alternatives cleanly. Those who hardcoded a single scheme will not.

The immediate action for security teams is not to track these candidates weekly. It is important to know what signature algorithms your systems are running today, where, and what it would take to replace them. That visibility is the foundation for every migration decision that follows.