← Back to Blog Research

NIST IR 8413: Round 3 PQC Standardization Report

11 min read

NIST Internal Report (IR) 8413 was published in July 2022. Its full title is "Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process." It is the document that announced the winners of the seven-year PQC competition that began in 2016. Every later NIST standard (FIPS 203, 204, 205, the draft 206) traces back to the choices documented in IR 8413.

Think of IR 8413 as the verdict at the end of a long trial. Sixty-four candidate schemes started. The judges (NIST plus the global cryptographic community) heard arguments, pored over evidence, and ran experiments. IR 8413 is the written verdict explaining who won and why.

This walkthrough goes through the report's structure, the selection rationale for each algorithm, the eliminations, and the implications for everyday users.

Section 1: The Competition's Goals

IR 8413 opens by recapping NIST's goals for the PQC project, set in 2016 and refined through three rounds of competition:

Standardize one or more KEMs that resist quantum attacks
Standardize one or more digital signature schemes that resist quantum attacks
Provide diversity in mathematical assumptions
Maintain reasonable performance and key sizes

The diversity requirement was important. NIST did not want a portfolio that could collapse if a single mathematical assumption was broken. The chosen algorithms span lattice-based, hash-based, and (in earlier rounds) code-based assumptions.

For more on the broader timeline, see NIST PQC standards timeline and what is post-quantum cryptography.

Section 2: The Winners

Section 2 announces the four selected algorithms:

CRYSTALS-Kyber (now ML-KEM, FIPS 203): the primary KEM for general use
CRYSTALS-Dilithium (now ML-DSA, FIPS 204): the primary signature for general use
FALCON (now FN-DSA, draft FIPS 206): a small-signature alternative
SPHINCS+ (now SLH-DSA, FIPS 205): a hash-based signature for diversity

Three of the four are based on lattice problems. SPHINCS+ uses only hash functions. The mix gives NIST diversity in case lattice problems are broken in the future.

NIST also announced a fourth round of analysis for additional KEMs (HQC, BIKE, Classic McEliece, SIKE) to provide more KEM diversity. SIKE was famously broken later in 2022 and removed from consideration. HQC was eventually selected for standardization in 2025. See HQC explained.

Section 3: Why CRYSTALS-Kyber Won the KEM Slot

Section 3 explains the selection rationale for ML-KEM. NIST praised:

Strong security analysis with multiple independent reductions
Compact public keys and ciphertexts compared to alternatives
Fast keygen, encapsulation, and decapsulation across all platforms
Conservative parameter choices with built-in safety margins

The competing finalists were NTRU, SABER, and Classic McEliece. NTRU and SABER had similar performance to Kyber but were judged less likely to gain rapid implementation traction. Classic McEliece had much larger public keys (around 1 MB) but smaller ciphertexts.

NIST chose Kyber as primary and signaled willingness to standardize alternatives later. Classic McEliece was kept under consideration in the fourth round.

For more on Kyber and its alternatives, see ML-KEM explained and NTRU vs ML-KEM.

Section 4: Why CRYSTALS-Dilithium Won the Signature Slot

Section 4 explains the ML-DSA selection. The strengths NIST cited:

Conservative security argument grounded in MLWE and MSIS
Stateless design (no counter management like LMS)
Reasonable signature size (around 2-4 KB)
Fast verification, fast signing
Naturally pairs with Kyber (similar mathematical structure simplifies hardware implementation)

Competing finalists were FALCON, SPHINCS+, and Rainbow. NIST chose Dilithium as the workhorse, FALCON as small-signature alternative, and SPHINCS+ as hash-based diversity. Rainbow was eliminated when a devastating attack was published during Round 3.

Section 5: Why FALCON Won the Small-Signature Slot

Section 5 covers FALCON. The highlight: very small signatures (around 666 bytes for FALCON-512) and small public keys (around 897 bytes). This makes FALCON ideal for high-volume signing applications like CA certificate issuance.

The downside, also discussed in Section 5: FALCON's signing algorithm uses Gaussian sampling that requires high-precision floating-point arithmetic. This creates implementation hazards (variable-time floating-point, side-channel risks) that delayed the FIPS 206 standardization. See FIPS 206 draft deep dive.

Section 6: Why SPHINCS+ Won the Hash-Based Slot

Section 6 explains the SPHINCS+ selection. SPHINCS+ relies only on the security of hash functions. If lattices are broken tomorrow, SPHINCS+ stands. NIST included it as the conservatism floor.

The downsides are signature size (7-50 KB depending on parameters) and signing speed. SPHINCS+ is slow at signing time. NIST acknowledged this and positioned SPHINCS+ for low-frequency, high-value use cases (firmware signing, root CA signatures).

For comparison with the other signature schemes, see ML-DSA vs SLH-DSA and FIPS 205 walkthrough.

Section 7: Eliminations and Why

Section 7 lists the algorithms eliminated during Round 3 and earlier rounds. The eliminations fall into three categories:

Category 1: Broken by Cryptanalysis

Rainbow (multivariate signature): Beullens published a key-recovery attack in February 2022 that broke the standard parameter sets in days on a laptop.
GeMSS (multivariate signature): Similar issues to Rainbow, less catastrophic but still concerning.

Category 2: Performance or Implementation Concerns

NTRU: Strong security but no clear advantage over Kyber. Eliminated for portfolio diversity reasons.
SABER: Similar to NTRU. NIST chose Kyber as the canonical lattice KEM.
Picnic: Hash-based signature with very large signatures. Eliminated because SPHINCS+ provided similar properties at lower cost.

Category 3: Patent or IP Concerns

Several candidates had open patent licensing terms but with restrictions that NIST judged inconsistent with universal deployment.

Category 4 (post-Round 3): SIKE

The most dramatic elimination came after IR 8413 was published. In August 2022, Castryck and Decru published a polynomial-time attack on SIKE (Supersingular Isogeny Key Encapsulation), one of the fourth-round candidates for additional KEM diversity. SIKE was eliminated immediately. This event reinforced NIST's preference for diversity: the math underlying SIKE looked promising for years before it collapsed, and the world was glad SIKE was not the primary KEM.

Section 8: The Fourth Round

Section 8 announced the fourth round, which continues to consider additional KEMs:

HQC (code-based): selected in 2025 for standardization. See HQC explained.
BIKE (code-based): still under analysis.
Classic McEliece (code-based): still under analysis, large public keys remain a concern.
SIKE (isogeny-based): eliminated August 2022.

The fourth round is about adding more diversity in case the lattice schemes face future cryptanalysis. HQC's selection in 2025 added a code-based KEM to the standardized lineup.

Section 9: Migration Recommendations

Section 9 summarizes NIST's migration recommendations:

Begin discovery and inventory of cryptographic uses immediately
Plan hybrid deployments using approved classical and PQC algorithms
Prioritize protection of long-lived data against harvest-now-decrypt-later attacks
Coordinate with NSA's CNSA 2.0 deadline for federal systems

Section 10: Lessons from the Competition

IR 8413 closes with lessons learned:

Open competitions catch attacks faster than closed standardization
Diversity in mathematical assumptions is essential
Implementation hazards matter as much as mathematical security (FALCON delay)
Real-world performance constraints shape standardization (SPHINCS+ as backup)

The seven-year process produced standards that survived intense scrutiny. The cryptographic community considers the process a success.

How QNSQY Reflects IR 8413

QNSQY uses the algorithms NIST chose:

ML-KEM-768 + X25519 for key establishment (FIPS 203 + SP 800-56A)
ML-DSA-65 + Ed25519 for digital signatures (FIPS 204 + SP 800-186)
SLH-DSA available as conservative hash-based alternative (FIPS 205)
HQC available as code-based alternative for Business tier
LMS available as stateful hash-based alternative for archival use

Defaults follow NIST primary recommendations. Power users can select alternatives via configuration. The architecture is intentionally aligned with IR 8413 selections.

What the Report Did Not Say

IR 8413 is a winner-announcement report, but reading between the lines reveals a few things worth noting.

First, NIST chose to make the four algorithms primary standards rather than splitting one into "primary" and three into "alternates." All four (ML-KEM, ML-DSA, FN-DSA, SLH-DSA) are fully approved standards, not backups. The portfolio approach is intentional.

Second, the report acknowledges that lattice-based schemes dominate the portfolio. NIST's response is the fourth round, which considers code-based alternatives (HQC, BIKE, Classic McEliece). HQC was selected in 2025 specifically to add code-based diversity.

Third, the report explicitly mentions that future cryptanalysis could change recommendations. NIST committed to ongoing analysis and is prepared to deprecate or replace any algorithm if a flaw emerges. This is unusual for a final standardization report.

How the Competition Compared to AES

IR 8413 echoes the AES competition (1997-2001) in structure but differs in scope. AES selected one algorithm. PQC selected four. AES was a single-purpose competition. PQC covered both KEMs and signatures.

The duration was also longer: AES took 4 years; PQC took 7. The reasons include:

More candidates initially (over 60 vs 15 for AES)
More mathematical assumptions to evaluate (lattices, codes, hashes, multivariate, isogenies)
More complex implementation security (FALCON's floating-point challenge)
More attempts at cryptanalysis (Rainbow break, SIKE break)

The seven-year process produced a portfolio with substantial confidence. The cryptographic community considers it a model for future standardization efforts.

Implications for Migration Timelines

IR 8413's selections fixed the migration target. For organizations planning the move from classical to PQC:

Use ML-KEM and ML-DSA as the default migration target
Add SLH-DSA where conservative hash-based signing is required
Wait for FIPS 206 finalization before deploying FN-DSA in production
Consider HQC for code-based diversity in Business-tier or Federal deployments

Migration is not all-or-nothing. Hybrid deployments per SP 800-227 provide a smooth path. Most organizations will run hybrid for 5-10 years, then migrate to pure PQC after CNSA 2.0 deadlines.

How the Cryptographic Community Responded

After IR 8413's publication, the cryptographic community responded in several ways:

Implementation efforts accelerated: open-source libraries (BoringSSL, OpenSSL, libsodium, pqcrypto) added implementations of the four selected schemes. By mid-2023, production-quality implementations existed for all four.
IETF and ISO standardization started: the IETF began work on TLS, IKEv2, and S/MIME extensions for PQC. ISO/IEC followed with corresponding international standards.
Vendors began rollouts: cloud providers, browser makers, and CDN companies announced PQC rollouts. By 2024, hybrid PQC was deployed in production at major TLS endpoints.
Hardware support emerged: chip vendors started including PQC accelerators in security chips, smart cards, and HSMs.

Within two years of IR 8413, PQC moved from research to production. The standardization process produced not just standards but ecosystem readiness.

What Comes After IR 8413

NIST has published several follow-up reports and documents:

NIST IR 8413-A and similar update reports for the fourth round of analysis
FIPS 203, 204, 205 as the formal standards
Draft FIPS 206 for FN-DSA pending finalization
NIST SP 800-227 for hybrid deployment guidance
HQC selection in 2025 for code-based KEM diversity

The NIST CSRC PQC project page maintains the current state. Engineers planning long-term migrations should subscribe to NIST PQC announcements.

FAQ

Why did NIST pick four algorithms instead of one?

For diversity. If a flaw is found in lattice-based crypto, hash-based SLH-DSA still works. If signatures need to be smaller than ML-DSA, FN-DSA is available. The portfolio approach reduces single-point-of-failure risk.

What about the algorithms eliminated for IP reasons?

NIST has historically required royalty-free use of standardized algorithms. Several promising candidates fell short on licensing terms. Some have since been re-licensed but were not added back to the standard list.

Is SIKE still safe?

No. SIKE was broken polynomially in August 2022. Any deployment using SIKE should migrate immediately.

When will HQC become a FIPS standard?

HQC was selected for standardization in March 2025. The corresponding FIPS document is in development. Until publication, HQC implementations follow the round-4 specifications.

What is the practical difference between ML-DSA and FALCON?

ML-DSA produces larger signatures (2-4 KB) but is easier to implement safely. FALCON produces smaller signatures (~666 bytes) but uses floating-point math that introduces implementation hazards. ML-DSA is the recommended default; FALCON awaits FIPS 206 finalization.

Sources

NIST IR 8413, Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process, NIST, July 2022
NIST IR 8309, Status Report on the Second Round of the NIST PQC Standardization Process, NIST, July 2020
NIST IR 8240, Status Report on the First Round of the NIST PQC Standardization Process, NIST, January 2019
Castryck and Decru, An Efficient Key Recovery Attack on SIDH, IACR ePrint, August 2022
Beullens, Breaking Rainbow Takes a Weekend on a Laptop, IACR ePrint, February 2022

Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

Try QNSQY