NIST IR 8610 Explained: 9 Promising Signature Algorithms Shaping the Next PQC Standards 

For almost ten years, cryptographers have been racing against a clock that hasn’t started ticking yet. The clock belongs to quantum computers, and when it finally goes off, the public-key cryptography behind nearly everything we trust online today will simply stop working. 

RSA. ECDSA. ECDH. Classical Diffie-Hellman. All of it falls to Shor’s algorithm the moment a sufficiently capable quantum machine exists. That’s the encryption protecting your bank, your software updates, your TLS handshakes, and the certificates that tell your browser a website is who it claims to be. And the threat cuts two ways: data captured today can be decrypted later, and anything signed today can be forged later, a quieter risk that lands hardest on signatures meant to stay trustworthy for decades. 

NIST has been quietly leading the response. Since 2016, the agency has run a years-long evaluation to find replacements, and the results so far are already in production: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). FN-DSA (FIPS 206, based on Falcon) is on deck, with finalization expected in 2027. HQC was added last year as a backup key-establishment mechanism. 

So the migration is well underway. Why, then, is NIST running another competition? 

The Hidden Problem in NIST’s Own Portfolio 

Look closely at the three signature standards, and you’ll notice something uncomfortable. Two of them, ML-DSA and FN-DSA, rest on the same family of structured-lattice assumptions. If a single cryptanalytic breakthrough hits that family the wrong way, a large chunk of the post-quantum signature portfolio could become questionable overnight. 

NIST saw this in 2022 and did something rare for a standards body: it admitted the gap and opened a separate call for additional digital signature schemes. The brief was specific. Build on different mathematical foundations. Optimize for smaller signatures or faster verification. Give us options the current portfolio cannot reach. 

By the June 2023 deadline, 50 submission packages had arrived. Forty were accepted into round one. Fourteen advanced to round two in October 2024. That round just wrapped. 

What NIST IR 8610 Actually Says 

In May 2026, NIST published Internal Report 8610, the official status report on the second round. The round ran from October 24, 2024 through May 14, 2026, and included the Sixth NIST PQC Standardization Conference in Gaithersburg last September. After eighteen months of cryptanalysis, public review, and patient back-and-forth between submitters and the community, NIST narrowed fourteen candidates down to nine. 

The evaluation bar was set early. Lattice-based submissions had to clearly beat both CRYSTALS-Dilithium and Falcon on some meaningful performance dimension. Non-lattice submissions had to beat SPHINCS+ in the same way. From there, every candidate was weighed on three criteria in this order: security first, cost and performance second, and algorithm and implementation characteristics third. The security floor was EUF-CMA, with SUF-CMA treated as a bonus. 

Here are the nine that made it, sorted by their mathematical family:

Category	Advancing Candidates
Lattice-Based	HAWK
Isogeny-Based	SQIsign
MPC-in-the-Head	FAEST, MQOM, SDitH
Multivariate	UOV, MAYO, QR-UOV, SNOVA

The Nine That Advanced 

A quick orientation before we go through them. Every digital signature scheme is built on a math problem the world believes is hard to solve. RSA bets on the difficulty of factoring huge numbers. ECDSA bets on the difficulty of certain elliptic curve calculations. Both of those bets lose to a working quantum computer. 

The nine candidates below place their bets on four very different problems, and that diversity is the whole point. NIST wants several independent foundations so that one breakthrough can’t take down everything at once. Here’s what each one is actually doing.

FAEST: Built on What the Industry Already Trusts 

FAEST’s security ultimately rests on AES, the symmetric encryption standard that protects most internet traffic today. The scheme uses a zero-knowledge proof system to demonstrate that the signer knows an AES key consistent with certain public values, without revealing the key itself. Because AES has been studied and attacked continuously for more than 25 years without compromise, FAEST inherits an unusually mature foundation for a post-quantum scheme. 

The technical machinery is a proof framework called VOLE-in-the-Head, paired with a protocol called QuickSilver. Round two delivered a meaningful set of optimizations: a more efficient commitment scheme, an AES-based PRG, a cleaner method for expressing AES constraints with degree-3 polynomials, and new security reductions in the Quantum Random Oracle Model. 

Of the six MPCitH candidates in round two, NIST expressed the strongest confidence in FAEST’s security, citing its reliance on extensively studied symmetric primitives. Side-channel and fault-injection work has identified vulnerabilities in masked FAEST implementations, but those findings do not affect the scheme’s underlying security model.

HAWK: A Lattice Scheme Designed for Constrained Hardware 

HAWK sits in the same mathematical family as NIST’s existing lattice-based standards, ML-DSA and the forthcoming Falcon-based FN-DSA, but it addresses one of Falcon’s most persistent implementation challenges. Falcon’s signing process requires floating-point arithmetic, which is difficult to implement correctly on smart cards, secure elements, and many embedded systems. Implementation errors in that arithmetic can leak the private key. HAWK uses integer-only arithmetic, which eliminates that class of failure mode entirely. 

The performance is also competitive. At security category 1, HAWK signatures are 555 bytes, smaller than both Falcon and ML-DSA. Key-recovery security rests on the Search Module Lattice Isomorphism Problem (smLIP) of rank 2. Unforgeability rests on the One-More-Shortest-Vector Problem (omSVP). Both are lattice-based, which means a fundamental breakthrough against lattice cryptography would affect HAWK alongside the existing standards. 

During round two, cryptanalysts identified a discrepancy in the original definition of omSVP. The HAWK team responded with a refined definition that excludes the relevant attack vector. Further research established that the underlying number field meaningfully affects security, and HAWK’s choice of cyclotomic fields appears resilient to known attacks. NIST advanced HAWK and encouraged the community to continue stress-testing smLIP in HAWK’s specific ring structure.

MAYO: Addressing UOV’s Public-Key Problem 

UOV (covered later in this list) produces very small signatures but is held back by a very large public key. MAYO is a redesign that preserves the small signatures and reduces the key burden by working from a compact starter key and expanding it into the full UOV system when needed. The expansion mechanism, called a “whipping” transformation, creates the larger instance with a block structure that maintains security while compressing the key. 

Round two surfaced a meaningful concern. A new technique called the wedge attack, applied to characteristic-2 UOV variants, hit MAYO’s category 1 parameter set with roughly a 30-bit security deficiency. NIST attributed the impact, which is larger than the corresponding effect on plain UOV, to the balance between the number of quadratic forms and the codimension of the secret subspace, rather than the whipping construction itself. 

MAYO retains some of the smallest public-key sizes in the multivariate category, with efficient signing and verification. NIST advanced MAYO while flagging the parameter-selection lesson and encouraging the team to evaluate odd-characteristic parameters as a countermeasure.

MQOM: Strongest Performance in the MPCitH Category 

MQOM rests on the difficulty of solving large systems of quadratic equations over a finite field, one of the longer-studied hard problems in cryptography. Its signing process uses an MPC-in-the-Head construction: the signer simulates multiple parties jointly computing on shares of a secret and proves that the simulation ran correctly, without revealing the secret itself. 

The round two version uses TCitH (Threshold Computation in the Head), a specialization of MPCitH that replaces traditional additive secret sharing with threshold Shamir secret sharing. 

By the numbers, MQOM is the standout in the MPCitH category. Across all three security levels, it has the smallest combined public-key and signature sizes of any MPCitH candidate, with very competitive signing and verification cycle counts. NIST advanced it on the strength of those numbers and the long-standing maturity of the underlying MQ problem, while noting that the formal security proofs in the Random Oracle Model and QROM require further refinement. 

QR-UOV: Efficient Compression Without Compromise

QR-UOV applies a mathematical technique called quotient rings to compress the standard UOV public key. Each block in the public key requires ℓ numbers to describe instead of ℓ², reducing public keys to roughly 15 to 50 percent of standard UOV’s size, without altering the underlying security model. 

QR-UOV was the most quietly successful multivariate candidate in round two. The wedge attack primarily targets a specific class of number fields, characteristic-2 fields, and QR-UOV uses odd-characteristic fields.

Even when the attack was extended to cover odd characteristic, its complexity against QR-UOV remained higher than existing attacks. In addition, the round two submission delivered signing and verification speeds 15 to 20 times faster than round one, with public-key and signature sizes held constant. NIST advanced QR-UOV with notable confidence, citing the absence of decisive attacks and the meaningful public-key reduction. 

SDitH: The Most Conservative Hardness Assumption 

SDitH (Syndrome Decoding in the Head) is built on a problem from coding theory that has been studied since the 1970s. Given a corrupted message and the error-correction code that produced it, identifying the exact error pattern is computationally infeasible. Error-correcting codes underpin much of modern communications, including Wi-Fi, cellular networks, and storage systems, so the underlying mathematics is among the most thoroughly examined in the field. SDitH converts that hardness into a signature scheme. 

Like other MPCitH candidates, SDitH was redesigned in round two to incorporate VOLE-in-the-Head and Threshold Computation in the Head techniques. The arithmetic encodes the syndrome decoding problem over the binary field, with unstructured linear codes. 

NIST highlighted SDitH specifically for the conservatism of its hardness assumption. Of the six MPCitH candidates, only FAEST has a comparably well-vetted foundation. The trade-off is computational cost, which tends to run higher than its peers. NIST advanced SDitH on the strength of its security assumption and to maintain assumption diversity within the MPCitH category.

SNOVA: High Potential, Unsettled Form 

SNOVA is another UOV variant, and on paper it produces the smallest keys and signatures of any multivariate candidate. The complication is its cryptanalysis history. Each round of close review has surfaced new weaknesses, and the team has responded with successive redesigns. It is simultaneously the most attractive candidate by raw performance and the least settled in its current form. 

Structurally, SNOVA borrows ideas from non-commutative rings and can be viewed as applying a MAYO-style whipping transformation on top of an already-structured UOV public key. 

The cryptanalysis history requires careful reading. A variant of the wedge attack broke most of SNOVA’s proposed parameter sets in round two, often by significant margins. The team responded with a redesign using odd-characteristic fields and symmetric quadratic forms. The new category 1 parameter set has both public-key and signature sizes smaller than Falcon, the most compact lattice-based signature NIST has standardized to date. 

NIST’s assessment is unusually direct. SNOVA could deliver a general-purpose signature scheme with fast verification and very compact outputs, but the report states explicitly that NIST “does not see SNOVA as having reached a stable form,” will consider larger modifications than for other candidates, and will require a longer time frame before considering any variant for standardization.

SQIsign: The Smallest Footprint in the Competition 

SQIsign operates in a distinct mathematical area from the other candidates, the geometry of supersingular elliptic curves. The underlying problem is challenging to summarize without specialized background, but the result is unambiguous. SQIsign produces the smallest combined public-key and signature footprint of any candidate in the entire competition. A category 1 signature is 148 bytes, small enough to fit inside a single Ethernet frame. 

For organizations weighing isogeny-based cryptography against the cautionary case of SIKE, the isogeny-based KEM that was kept under consideration through four NIST rounds before being broken over a single weekend in 2022, SQIsign is structurally different. It does not expose the auxiliary torsion-point information that SIDH-style attacks exploited. It belongs to the same broad mathematical family but uses a different construction. 

Between rounds, SQIsign underwent a significant architectural change, moving from the original KLPT-based path-finding algorithm to one based on higher-dimensional isogenies. The result was roughly a 20x improvement in signing speed and a 6x improvement in verification. NIST advanced SQIsign for its compactness and growing maturity, while noting that fully constant-time signing remains an open problem worth resolving for side-channel protection. 

UOV: The Long-Established Multivariate Baseline 

UOV is the original multivariate signature scheme, dating to the 1990s, and it has been studied for nearly thirty years. Its signature properties remain exceptional: 96 bytes per signature at category 1, with verification in the tens of thousands of CPU cycles. The trade-off is a public key exceeding 200 kilobytes, which makes UOV unsuitable as a general-purpose replacement for RSA or ECDSA. It is well-suited, however, to scenarios where a single public key is provisioned once and verifies many compact signatures, such as firmware updates and code signing for embedded devices. 

Mathematically, UOV uses a structured system of quadratic polynomials that vanishes on a secret subspace. The secret-holder can compute preimages efficiently using a small linear system and an affine projection; everyone else cannot. 

Round two introduced new attacks. A wedge attack using exterior products exposed the hidden secret subspace in three of four proposed parameter sets, with security reductions ranging from a few bits at category 1 to roughly 20 bits at category 5. A follow-up attack exploiting small-field characteristics pushed those same parameter sets below their target security strengths.

NIST advanced UOV citing its long track record, the existence of parameter sets that are not affected, and the diversity value of preserving a classical multivariate option in the portfolio. The team is being encouraged to evaluate odd-characteristic parameters, the same recommendation NIST is making across several multivariate candidates. 

What Didn’t Make It, And Why 

Five candidates from round two were dropped. The reasoning is worth understanding because it tells you what NIST is actually optimizing for. 

• CROSS (code-based, Restricted Syndrome Decoding) had a performance profile in the neighborhood of SPHINCS+ but with a less mature underlying hardness assumption, and round two attacks forced parameter updates. The performance edge wasn’t enough to justify the security trade-off. 
• LESS (code-based, Linear Code Equivalence) offered the smallest signatures among code-based schemes, but with enormous public keys and slow signing and verification. A round-two attack cut concrete complexity by 12 bits at category 1 and 24 bits at category 5. The numbers stopped working. 
• Mirath (MPCitH, MinRank, formed from the MIRA and MiRitH merger) posted up to 10x performance gains in round two but got squeezed out of a crowded MPCitH field. NIST kept the candidates with either stronger security (FAEST) or stronger performance (MQOM). 
• PERK (MPCitH, Permuted Kernel) produced signatures about 10 percent smaller than FAEST but was significantly slower. NIST framed this as a performance trade-off, not a vote against the Permuted Kernel Problem itself. 
• RYDE (MPCitH, Rank Syndrome Decoding) landed in the 3 to 3.5 kilobyte range at category 1, similar to MQOM and Mirath, but consistently slower than MQOM. NIST consolidated. 

Why NIST is Running This Competition at All 

Step back from the candidate list and the picture gets clearer. NIST is doing this for two practical reasons.

• Mathematical Diversity: Two of the three current signature standards lean on structured-lattice assumptions. History has been unkind to assumptions of overconfidence. Rainbow, a multivariate scheme, made it to the third round of the original NIST process and was broken in 2022. SIKE, an isogeny-based KEM that NIST kept under consideration through four rounds of evaluation, was broken over a weekend that same year. Putting too much weight on any one family of problems is the kind of mistake you only get to make once. 
• Signature Size and Speed: The deployment surface for signatures is enormous and varied. TLS, SSH, IKE, IPsec, OCSP, DNSSEC, certificate transparency, document signing, code signing, firmware updates. Each has its own bandwidth and timing budget, and several of those budgets simply don’t fit today’s lattice-based and hash-based signatures comfortably. NIST asked for schemes that could.

You can see the answer in the numbers. SQIsign at 148 bytes fits inside a single Ethernet frame. UOV at 96 bytes verifies in tens of thousands of cycles. HAWK at 555 bytes is smaller than anything standardized so far. These aren’t theoretical advantages; they map to real deployments that the current portfolio struggles with. 

What This Means for Your PQC Migration 

If you’re running a post-quantum program right now, the news from NIST doesn’t change your immediate plan. It clarifies it. 

The migration target today is still ML-DSA, SLH-DSA, and the forthcoming FN-DSA. Third-round candidates are not finalized and will not be soon. NIST has just opened public comment on the nine survivors, will accept updated submission packages by August 14, 2026, and is planning another standardization conference in the first half of 2027. Standardization decisions follow that conference and another round of cryptanalysis. Treating any of the nine as a near-term deployment target would be a planning mistake. 

What the announcement does change is how you should think about crypto-agility. When the standards body that publishes your standards is actively seeking alternatives to those same standards, the takeaway is unmistakable: build the ability to change algorithms without re-architecting the systems around them. The organizations that come out of this transition cleanest will be the ones that treated algorithm choice as a configuration concern, not a foundation concern. 

And if your environment includes constrained devices, satellite links, OT networks, IoT fleets, DNSSEC, or code signing for embedded firmware, you have a direct stake in what happens next. Pay attention to SQIsign, HAWK, and the multivariate candidates. Harvest-now-decrypt-later gets most of the airtime in PQC conversations, but its signature cousin, trust-now-forge-later, applies to anything signed today that needs to remain trustworthy for decades. Long-lived signed artifacts are quietly one of the higher-stakes problems in this space.

Where Encryption Consulting Fits In 

A real PQC migration is a multi-year program, and the work is broader than swapping algorithms. It runs through inventory, governance, architecture, vendor management, and the engineering teams who actually touch production systems. Our PQC Advisory Services are built around that full picture. 

We start with cryptographic discovery and inventory across certificates, keys, algorithms, libraries, and protocols, wherever they live: on-prem, cloud, hybrid, or SaaS. The engine behind that is CBOM Secure, our Cryptographic Bill of Materials platform, which gives you continuous, machine-readable visibility across source code, binaries, runtime environments, TLS endpoints, cloud KMS, HSMs, and IoT. 

From there, we run a quantum threat assessment and readiness gap analysis that classifies assets by sensitivity and lifespan, scores quantum vulnerability, and surfaces policy gaps against NIST guidance. The output feeds a PQC strategy and migration roadmap aligned with FIPS 203, 204, 205, and the forthcoming 206, with prioritization tied to your actual business risk rather than a generic timeline. 

The most important investment we help clients make, especially in light of NIST’s still-evolving portfolio, is crypto-agility framework design. Algorithm changes should happen through configuration, not re-engineering. That single design decision is what protects you from doing this migration twice. 

On the PKI side, PKIaaS is our fully managed, PQC-ready PKI. It issues hybrid and pure quantum-safe certificates (including ML-DSA), enforces algorithm policy centrally, and runs on a FIPS 140-3 Level-3 HSM-backed root CA. For code signing, CodeSign Secure centralizes signing operations with hybrid and PQC-ready support, policy-driven approvals, and HSM-backed key protection, without forcing changes to your CI/CD pipelines. 

Around all of that, we handle vendor evaluation and proofs of concept, hybrid PQC implementation across PKI and applications and cloud workloads, governance and policy alignment for NIST guidance, CNSA 2.0, EU and UK timelines, and sector-specific regulators, and the training and runbooks your internal teams need to sustain the program after we step back. 

Not sure where your organization stands? Start with a 30-minute scoping call where we assess your specific environment against NIST’s current and emerging standards, with no commitment to engage further. This is especially worth doing if your environment includes OT networks, IoT fleets, DNSSEC, satellite links, or long-lived signed firmware. Email [email protected] or book a demo directly to get started. 

Conclusion 

The advancement of nine signature candidates to the third round is not a procedural footnote. It’s a signal. The post-quantum field is still moving. No single mathematical family will be allowed to carry the full weight of digital trust. And how an algorithm performs in the real world matters as much as how secure it looks on paper. 

The next two years of cryptanalysis and engineering will decide which of FAEST, HAWK, MAYO, MQOM, QR-UOV, SDitH, SNOVA, SQIsign, and UOV are ready for production. 

For everyone else, the playbook is straightforward. Migrate to today’s standards on the timelines regulators have already set. Build the crypto-agility that lets you adopt tomorrow’s standards without starting over. And don’t wait for the dust to settle before starting the inventory and governance work, because that work is the part that takes the longest, no matter which algorithms end up on top.