FIPS 203, 204, and HQC Explained: What Security Architects Need to Know About NIST's Finalized PQC Standards

Security architects are now encountering FIPS 203 and FIPS 204 in vendor documentation, procurement requirements, and compliance frameworks — but the naming conventions around these standards are genuinely confusing. Kyber, ML-KEM, and FIPS 203 are related but not interchangeable references. The same problem applies to Dilithium, ML-DSA, and FIPS 204. Misusing these names in security policies or procurement documents creates real compliance risk. This article maps the full picture: what each standard covers, how the three parameter sets within each standard translate to practical deployment decisions, and what the March 2025 selection of HQC as a backup KEM means for architecture planning today.

This article draws on published standards and official documentation from NIST FIPS 203, NIST FIPS 204, NIST IR 8545, and NIST's Post-Quantum Cryptography project pages. Last reviewed March 2026.

Key Takeaways

• FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) are final, published federal standards as of August 13, 2024 — not drafts or experimental specifications.
• The algorithm names Kyber and Dilithium refer to competition submissions; ML-KEM and ML-DSA are the normative NIST designations. Procurement documents should use FIPS numbers or NIST algorithm names, not the original submission names.
• ML-KEM handles key establishment (replacing RSA-KEM and ECDH); ML-DSA handles digital signatures (replacing RSA signatures and ECDSA). They are not interchangeable and address different parts of a protocol stack.
• ML-KEM and ML-DSA public keys and signatures are significantly larger than classical equivalents — architects must account for TLS handshake sizes, certificate storage, and HSM buffer constraints.
• HQC was selected in March 2025 as a code-based backup KEM to provide algorithmic diversity against potential lattice vulnerabilities; it is a contingency mechanism, not an immediate replacement for ML-KEM.

Why These Three Standards Are Your Starting Point

FIPS 203 and FIPS 204 are not proposals awaiting finalization. NIST published both standards on August 13, 2024, alongside FIPS 205 (SLH-DSA, a stateless hash-based signature scheme). These are binding federal standards for U.S. government use and the reference point that regulated industries, allied governments, and major platform vendors are aligning to. CISA's post-quantum guidance already directs critical infrastructure operators toward these standards. ENISA's PQC guidance similarly references the NIST process as the primary standardization baseline for European operators.

Waiting for vendors to abstract these details away is a reasonable operational posture for some decisions, but it is not a substitute for architectural understanding. Certificate lifetimes, protocol negotiation choices, HSM procurement cycles, and CA hierarchy redesigns all require decisions that are being made now, against timelines that extend beyond the point at which quantum-capable adversaries may become credible. Architects who engage with these standards directly will make better decisions than those who rely entirely on vendor summaries.

The Naming Problem — Kyber, ML-KEM, and FIPS 203 Are Not the Same Thing

From Algorithm Submission to Federal Standard

The NIST Post-Quantum Cryptography standardization process began in 2016 as an open competition. CRYSTALS-Kyber and CRYSTALS-Dilithium were among the submissions evaluated over multiple rounds. When NIST selected them for standardization, it did not simply ratify the submitted specifications. Parameters were refined, formatting was standardized, and the algorithms were assigned new designations: ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) in FIPS 203 and ML-DSA (Module-Lattice-Based Digital Signature Algorithm) in FIPS 204. The FIPS documents are the normative compliance references. The original Kyber and Dilithium specifications are academic precursors, not the standards themselves.

Why the Name Change Matters in Practice

Libraries, protocol specifications, and vendor documentation are actively converging on ML-KEM and ML-DSA as the canonical names. The IETF, for example, references ML-KEM in its hybrid key exchange drafts for TLS 1.3. If your security policy, procurement documentation, or third-party audit criteria still reference "Kyber" or "Dilithium" without qualification, you risk ambiguity about whether you mean the competition submission or the finalized FIPS standard — and those are not bit-for-bit identical. Compliance auditors working against FIPS-referenced control frameworks will use the FIPS numbers and NIST algorithm names. Align your documentation accordingly.

ML-KEM (FIPS 203) — The Primary Standard for Key Establishment

What ML-KEM Actually Does (And What It Doesn't)

ML-KEM is a Key Encapsulation Mechanism. Its function is to allow two parties to establish a shared secret over an untrusted channel — the same role currently played by RSA key encapsulation and elliptic-curve Diffie-Hellman (ECDH) in protocols like TLS. FIPS 203 defines ML-KEM explicitly as a key encapsulation mechanism, not a general-purpose encryption scheme. It does not replace AES for bulk data encryption. Once ML-KEM establishes the shared secret, symmetric encryption (AES-256, for example) handles the data. Architects who conflate KEM with encryption will misapply it — specifying ML-KEM in contexts that require a symmetric cipher, or overlooking it in contexts where key exchange is the actual vulnerability.

Choosing a Security Level: ML-KEM-512, 768, or 1024

FIPS 203 defines three parameter sets. ML-KEM-512 targets a security level comparable to AES-128; ML-KEM-768 targets AES-192; ML-KEM-1024 targets AES-256. Public key sizes are approximately 800 bytes for ML-KEM-512, 1,184 bytes for ML-KEM-768, and 1,568 bytes for ML-KEM-1024. Encapsulation key (ciphertext) sizes follow a similar progression.

The practical mapping to existing RSA or ECDH deployment tiers requires care. NIST does not publish a direct RSA-bit equivalence table for ML-KEM, and simplistic comparisons — "ML-KEM-768 equals RSA-3072" — are misleading because the security models and attack surfaces differ fundamentally between lattice-based and factoring-based schemes. The more defensible framing for procurement and policy purposes is to map ML-KEM parameter sets to the symmetric security level targets (128-bit, 192-bit, 256-bit) and align those with your existing data classification tiers. Organizations currently operating at a 128-bit symmetric equivalent posture can anchor on ML-KEM-512 as a baseline; those with higher sensitivity requirements should assess ML-KEM-768 or ML-KEM-1024.

Performance and Size Implications for TLS and PKI

ML-KEM public keys are substantially larger than their classical counterparts. An ECDH P-256 public key is 64 bytes; ML-KEM-768 is 1,184 bytes — roughly 18 times larger. This has direct implications for TLS 1.3 handshake sizes, particularly when combined with post-quantum certificates in the same handshake. Certificate chain sizes, OCSP response payloads, and any protocol that carries public key material in-band will all be affected. Architects sizing network appliances, load balancers, and TLS termination infrastructure should treat these size increases as a confirmed constraint, not a theoretical concern, and validate that existing buffer allocations and MTU assumptions remain valid under post-quantum key material.

ML-DSA (FIPS 204) — The Primary Standard for Digital Signatures

Where ML-DSA Replaces RSA and ECDSA

ML-DSA addresses the signature function — authenticating that a message, document, or piece of code was produced by the holder of a specific key. FIPS 204 defines ML-DSA as the replacement for RSA signatures and ECDSA in contexts including TLS server certificates, code signing pipelines, S/MIME, and document authentication. This is architecturally distinct from ML-KEM: a TLS connection uses ML-KEM for key establishment and ML-DSA (or an equivalent) for the certificate signature that authenticates the server. Both are required for a fully post-quantum TLS deployment; neither substitutes for the other.

Signature and Key Size Realities

FIPS 204 defines three parameter sets: ML-DSA-44, ML-DSA-65, and ML-DSA-87, targeting security levels equivalent to AES-128, AES-192, and AES-256 respectively. Public key sizes range from approximately 1,312 bytes (ML-DSA-44) to 2,592 bytes (ML-DSA-87). Signature sizes range from approximately 2,420 bytes (ML-DSA-44) to 4,595 bytes (ML-DSA-87). For comparison, an ECDSA P-256 signature is approximately 64 bytes. The size increase is not incidental — it has direct implications for certificate storage infrastructure, revocation database sizing, HSM signature buffer allocations, and any system that stores or transmits large volumes of signed objects. Code signing pipelines that handle high-throughput binary distributions should model the storage and bandwidth impact before migration.

Long-Lived Certificates and Migration Sequencing

Certificate validity periods create a specific sequencing problem. A TLS certificate issued today with a classical algorithm and a two-year validity period will remain active through 2027 or 2028. A root CA certificate issued today may have a validity period extending to 2035 or beyond. If the quantum threat timeline matures before these certificates expire, the signing algorithm underneath them becomes the vulnerability. Migration to ML-DSA for CA hierarchies cannot be deferred until a threat is confirmed — the lead time for root CA transitions, cross-certification, and downstream relying-party updates is measured in years. Architects responsible for PKI should treat ML-DSA migration sequencing as a current-cycle planning item, not a future-cycle decision.

HQC — Why NIST Selected a Backup KEM and What It Means for Your Architecture

The Case for a Non-Lattice Backup

NIST IR 8545, published in March 2025, announced the selection of HQC (Hamming Quasi-Cyclic) as a backup KEM. The rationale is explicit: ML-KEM, ML-DSA, and the third finalized standard FIPS 205 (SLH-DSA) all depend on structured lattice mathematics or hash functions. HQC is code-based, deriving its security from the hardness of decoding quasi-cyclic codes — a different mathematical assumption entirely. If a structural weakness in lattice-based schemes were discovered, a code-based alternative provides a fallback that is not vulnerable to the same class of attack. NIST is clear that HQC is a contingency, not a primary recommendation: the current primary standards remain FIPS 203 and FIPS 204.

What HQC Means for Architecture Decisions Today

For most organizations, HQC does not change near-term implementation priorities. NIST IR 8545 indicates that a draft FIPS standard for HQC is expected, but as of March 2026 it is not yet finalized. The practical implication for architects is awareness rather than immediate action: design cryptographic agility into systems being built or updated now, so that algorithm substitution — including eventual HQC adoption in high-assurance or long-lifecycle systems — does not require architectural rework. Organizations operating in sectors where algorithmic diversity is a specific regulatory or assurance requirement (defense, critical national infrastructure) should monitor HQC's standardization progress and assess whether it belongs in their cryptographic inventory planning. For the majority of enterprise deployments, completing ML-KEM and ML-DSA migration planning is the higher-priority task.

Disclaimer: This content is for informational purposes only and does not constitute legal, regulatory, or compliance advice. Requirements vary by jurisdiction, organisation size, and specific circumstances. Consult a qualified professional before making compliance decisions based on this content. pqcinformation.com is an independent information resource and is not affiliated with any vendor, regulatory authority, or standards body.