NIST Post-Quantum Standards Guide: FIPS 203, 204, 205 and What Comes Next

The answer, up front

NIST has finalized three post-quantum standards: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for digital signatures, and FIPS 205 (SLH-DSA), a hash-based backup signature. Two more are pending: FN-DSA (FIPS 206), a compact signature scheme that NIST has not yet released as a public draft, and HQC, a backup key-encapsulation mechanism NIST selected in March 2025 4, 5.

Status at a glance (as of Sep. 30, 2026)

FIPS 203: ML-KEM

ML-KEM is the module-lattice key-encapsulation mechanism NIST standardized for key establishment 1. It replaces the key-exchange job that Diffie-Hellman, ECDH, and RSA key transport perform today 6.

OMB describes ML-KEM as efficient, with moderate key sizes and larger overhead than elliptic-curve cryptography 6. FIPS 203 sets the sizes: an ML-KEM-768 encapsulation key takes 1,184 bytes and its ciphertext takes 1,088 bytes, while ML-KEM-1024 takes 1,568 bytes for both 1. TLS 1.3 key shares carry these same values 7.

ML-KEM already runs on the internet through hybrid key exchange. RFC 10024, published in August 2026, defines three hybrid groups for TLS 1.3, including X25519MLKEM768 7. Hybrid vs. Pure Post-Quantum explains when to use hybrid.

FIPS 204: ML-DSA

ML-DSA is the module-lattice digital signature standard 2. OMB calls it a balanced choice with a solid lattice foundation and warns that signature size can strain bandwidth in some uses 6. FIPS 204 lists signatures of 2,420 bytes (ML-DSA-44), 3,309 bytes (ML-DSA-65) and 4,627 bytes (ML-DSA-87) 2. That is larger than the rough 1 to 2 KB figure in the OMB memo, so size your protocols from the standard. Use ML-DSA as your default signature algorithm for certificates, code signing, and document signing.

FIPS 205: SLH-DSA

SLH-DSA is the stateless hash-based signature standard 3. Its security rests on hash functions, not on lattices, so it works as a fallback if someone breaks a lattice assumption. The tradeoff is size and speed: OMB notes signatures in the tens of kilobytes and slower signing 6.

FN-DSA (FIPS 206): compact signatures, still in development

FN-DSA is the signature scheme based on the Falcon algorithm. It produces the smallest signatures of the lattice family, which suits bandwidth-limited settings. NIST's project page, last updated Aug. 5, 2026, lists FIPS 206 as in development 5. As of Sep. 30, 2026, I found no public draft on NIST's site and no Federal Register notice, so no comment period has opened and NIST has announced no final date. Earlier secondary reports of a late 2026 or early 2027 final are estimates, not NIST commitments.

NSA's CNSA 2.0 FAQ states that for National Security Systems, "ML-DSA is preferred, as FN-DSA seems more susceptible to implementation errors that may affect security" 9.

What to do: Do not deploy FN-DSA in production until NIST publishes the final standard. NSA says that any algorithm called CRYSTALS-Kyber or CRYSTALS-Dilithium that does not adhere to FIPS 203 or 204 is not CNSA 2.0 compliant 9.

HQC: the backup key-encapsulation mechanism

On Mar. 11, 2025, NIST selected HQC as a backup to ML-KEM because it rests on a different mathematical approach 4. NIST planned to release a draft standard for public comment in about a year, take comments for 90 days, and finalize in 2027 4. As of Sep. 30, 2026, NIST's project page still lists HQC as selected with standardization underway 5, and I found no published draft. NIST has presented the forthcoming standard as FIPS 207 8. Treat 2027 as NIST's plan, not a commitment, and check NIST's post-quantum project page before you quote a status.

What to do: Keep migrating to ML-KEM. HQC is a backup, not a replacement.

How the standards fit U.S. policy

• Civilian agencies: OMB M-26-15 lists FIPS 203, 204, and 205 as the algorithms agencies adopt and notes that FALCON and HQC may follow 6.
• National Security Systems: NSA's CNSA 2.0 suite selects specific parameter sets, including ML-KEM-1024 and ML-DSA-87, and states that non-conforming versions of the algorithms do not satisfy the requirement 9.
• Validated modules: The June 2026 executive order tells NIST to speed up validation of cryptographic modules 10. Check the Cryptographic Module Validation Program status of any library you plan to use.

Which standard for which job

What this means for executives and the board

You do not need to pick algorithms. You do need to know that the choice has narrowed. NIST finalized three standards in August 2024 1, 2, 3, and the finished set already covers key establishment and signatures 1, 2, 3, 4. That gives your organization something concrete to buy, build and audit against.

Three points matter at the leadership level.

• Confidentiality comes first. The harvest-now, decrypt-later risk targets data in transit and in storage, so key establishment (ML-KEM) is the first job to fix 1.
• Standards are not the same as compliance. A library can implement FIPS 203 and still lack the module validation your regime requires 10. Your CISO owns that check.
• Two standards are unfinished. FN-DSA and HQC are pending, so do not make purchase commitments that depend on them 4, 5.

ArcQubit guidance: treat this as an inventory and supplier question, not a science project. Your board should hear who owns the work, which systems come first, and which vendors have committed to the finished standards.

Decisions leadership must make in the next 90 days

These are our recommendations, not requirements from NIST.

1. Name one accountable owner. Assign a single executive, usually the CISO, who reports progress on the standards to the board.
2. Adopt the finished standards as your target. Write ML-KEM, ML-DSA and SLH-DSA into your architecture policy as the approved algorithms 1, 2, 3.
3. Freeze pre-standard bets. Tell teams not to deploy FN-DSA in production until NIST publishes the final standard 5. Tell them to keep HQC on the watch list only.
4. Put the standards into procurement. Ask new suppliers which of the three standards their products support, and in what form (hybrid or standalone).
5. Require validation evidence. Ask your compliance lead to confirm the Cryptographic Module Validation Program status of any library you plan to use 10.

Questions to ask your team this week

• Which of our systems establish keys today, and which of them could adopt ML-KEM first?
• Where do we sign code, certificates and documents, and which signatures must stay trustworthy for many years?
• Which of our suppliers have published support for FIPS 203, 204 and 205?
• Do we plan to use a hybrid group such as X25519MLKEM768, or a standalone algorithm, and who decided 7?
• Can our network gear and clients handle ML-DSA signatures of 2.4 to 4.6 KB 2, and larger ones for SLH-DSA 6?
• Which libraries do we depend on, and does each hold the validation our regime requires?
• Who tracks NIST's status on FN-DSA and HQC, and how often do they report?
• Does anyone in our organization treat a draft as final? If so, where?

A simple owner and timeline table

ArcQubit guidance. Adjust the owners and dates to your organization.

What it costs to wait

We cannot put a dollar figure on delay, and we will not invent one. We can name where the cost shows up.

• Data already collected. An attacker who records encrypted traffic today can try to decrypt it once a capable quantum computer exists. Waiting does not undo the recording.
• Procurement lead time. Products you buy now stay in service for years. If they lack the finished standards, you will replace or upgrade them under pressure.
• Supplier dependence. Your vendors ship the algorithms you use. If they lag, you lag, and you have less leverage once your renewal date arrives.
• Audit exposure. U.S. civilian agencies already work from a list that names FIPS 203, 204 and 205 6, and your supply chain may inherit those questions.

Common mistakes and how to avoid them

• Waiting for FN-DSA or HQC. Neither is final 4, 5. The three finished standards already cover your first steps. Start there.
• Treating a draft as a standard. NSA says that versions of Kyber or Dilithium that do not adhere to FIPS 203 or 204 are not CNSA 2.0 compliant 9. Confirm final status before you deploy.
• Confusing ML-DSA and SLH-DSA. ML-DSA is the general default. SLH-DSA is a fallback with larger signatures and slower signing 6. Do not use it everywhere because it sounds safer.
• Ignoring signature size. Larger signatures can strain bandwidth in some uses 6. Test your protocols before you commit.
• Skipping module validation. A correct algorithm in an unvalidated module may still fail your compliance test 10.
• Quoting a status you have not checked. Status for FN-DSA and HQC changes. Check NIST's post-quantum project page before you tell your board.

A worked example

A mid-sized services firm runs customer portals, an internal code-signing pipeline and a private certificate authority. Its CISO reads this guide and takes four steps.

First, she asks each team to list where the firm establishes keys and where it signs. Second, she picks the customer portals as the first ML-KEM target because they carry the data that an adversary would most want to store. Third, she sets ML-DSA as the default for code signing and holds the private certificate authority for review, since its roots of trust must last. That review asks whether an SLH-DSA fallback makes sense, at the cost of larger signatures 6. Fourth, she tells procurement to ask suppliers about validation status, and she puts FN-DSA and HQC on a quarterly watch list.

She briefs the board with one page: the three standards, the two pending ones, the systems in scope, the owners, and the dates. The board approves the plan without needing to weigh any algorithm.