On August 13, 2024, NIST published the first three finalized NIST post-quantum standards — FIPS 203, FIPS 204, and FIPS 205 — closing an eight-year, 82-submission public competition and giving security teams an actual specification to build against instead of a research paper. For software supply chain security, this is not an academic milestone. Every signed commit, every code-signing certificate, every SBOM attestation, and every TLS handshake protecting a software update today relies on RSA or elliptic-curve math that a sufficiently large quantum computer could break. Adversaries are already harvesting encrypted traffic and signed artifacts now, betting they can decrypt or forge them later once quantum hardware catches up. This overview walks through what each finalized standard actually specifies, why NIST moved when it did, how the new algorithms compare to what they replace, and what the migration timeline means for anyone shipping software today.
What Are the NIST Post-Quantum Standards?
The NIST post-quantum standards are three finalized Federal Information Processing Standards — FIPS 203, 204, and 205 — that define quantum-resistant standards for encryption key exchange and digital signatures, intended to replace RSA and elliptic-curve cryptography before large-scale quantum computers can break them. NIST opened its post-quantum cryptography (PQC) standardization project in December 2016, soliciting algorithm submissions from cryptographers worldwide. It received 82 candidate algorithms, narrowed those to 69 that met initial submission requirements, cut the field to 26 for round two in 2019, and announced four finalists in July 2022. Three of those finalists — CRYSTALS-Kyber, CRYSTALS-Dilithium, and SPHINCS+ — became the basis for FIPS 203, 204, and 205, respectively, after a public comment period and reference implementation review. A fourth algorithm, FALCON, is still headed toward standardization as a future FIPS 206. Unlike a draft or a research proposal, a finalized FIPS is a mandatory specification for U.S. federal systems and a de facto baseline that vendors, auditors, and compliance frameworks worldwide now measure against.
What Does Each of FIPS 203, 204, and 205 Actually Cover?
Each of the three standards solves a different cryptographic job, and none of them is a drop-in replacement for all of RSA's use cases. FIPS 203 defines ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), built from CRYSTALS-Kyber, and it's the mechanism two parties use to agree on a shared secret key over an untrusted channel — the quantum-safe successor to RSA and Diffie-Hellman key exchange in TLS. It ships in three parameter sets, ML-KEM-512, -768, and -1024, offering increasing security margins at the cost of larger keys. FIPS 204 defines ML-DSA (Module-Lattice-Based Digital Signature Algorithm), built from CRYSTALS-Dilithium, and it's the primary quantum-resistant signature scheme for signing code, documents, and certificates — the successor to RSA and ECDSA signatures. It also comes in three parameter sets: ML-DSA-44, -65, and -87. FIPS 205 defines SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), built from SPHINCS+, and it exists as a deliberately conservative backup: because it relies purely on hash function security rather than lattice math, it remains trustworthy even if an unforeseen weakness is later found in lattice-based cryptography. Among these three NIST PQC algorithms, ML-KEM and ML-DSA are expected to become the workhorses, with SLH-DSA reserved for scenarios that demand algorithmic diversity as a hedge.
Why Did NIST Finalize These Standards Now?
NIST finalized these standards now because the threat window for "harvest now, decrypt later" attacks is already open, even though a cryptographically relevant quantum computer capable of breaking RSA-2048 doesn't exist yet. Shor's algorithm, first described in 1994, can theoretically factor large integers and solve discrete-log problems — the exact math underpinning RSA and elliptic-curve cryptography — in polynomial time on a sufficiently powerful quantum computer, versus the billions of years classical computers would need. Intelligence agencies and researchers have documented adversaries intercepting and storing encrypted traffic today specifically to decrypt it once quantum hardware matures, which threatens anything requiring long-term confidentiality: firmware signing keys, long-lived certificates, and archived source code among them. The U.S. government moved on a parallel policy track to reinforce the deadline: National Security Memorandum 10 (NSM-10), issued in May 2022, directed federal agencies to inventory cryptographic systems, and OMB guidance required agencies to submit those inventories by May 2023. The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) followed, setting concrete adoption targets for vendors selling into national security systems. Waiting for a working quantum computer before migrating would leave a multi-year gap during which already-harvested data and signatures remain exposed.
How Do the New NIST PQC Algorithms Differ from RSA and ECC?
These algorithms differ from RSA and ECC primarily in the math problem they rely on and, as a direct consequence, in the size of their keys and signatures. RSA and ECC derive their security from integer factorization and elliptic-curve discrete logarithms — both solvable in polynomial time by Shor's algorithm on a quantum computer. ML-KEM and ML-DSA instead rely on the hardness of lattice problems (specifically, module learning-with-errors), which have no known efficient quantum attack, and SLH-DSA relies purely on the collision resistance of hash functions. The tradeoff is size: an RSA-2048 public key is about 256 bytes and produces a 256-byte signature, while ML-KEM-768 needs a 1,184-byte public key and produces a 1,088-byte ciphertext, and ML-DSA-65 needs a 1,952-byte public key and a 3,293-byte signature. SLH-DSA goes further in the other direction — tiny keys but signatures ranging from roughly 7,856 to 49,856 bytes depending on the parameter set. For software supply chains, that size increase is not cosmetic: it inflates TLS handshake overhead, code-signing certificate chains, firmware images on constrained embedded devices, and every SBOM or attestation payload that bundles a signature. Teams that assumed fixed-size cryptographic fields in their tooling, storage schemas, or bandwidth budgets will need to re-test those assumptions against quantum-resistant standards before deploying them at scale.
What's the Migration Timeline, and Who Has to Move First?
Federal agencies and national security systems face the earliest deadlines, but commercial software vendors will be pulled into the same timeline through contracts and compliance requirements well before that. CNSA 2.0 calls for software and firmware signing to support quantum-resistant algorithms by 2025, for web browsers and servers to support them by 2025, and for national security systems to complete the transition by 2033. NIST itself has signaled that it intends to deprecate 112-bit-security classical algorithms (like RSA-2048 and ECDSA P-256) by 2030 and disallow them by 2035 in federal contexts. In practice, that means any vendor selling into FedRAMP, DoD, or other regulated federal environments should expect procurement language requiring documented crypto-agility and PQC support well ahead of the 2030 mark, since audits, third-party risk assessments, and contract renewals move faster than hard deadlines. Outside government, the timeline is softer but not absent — payment networks, certificate authorities, and browser vendors are already piloting hybrid classical/PQC key exchange in TLS 1.3. The longest tail belongs to embedded and IoT devices with multi-year hardware refresh cycles, where a firmware signing key chosen today may still be verifying updates on hardware in the field in 2035. That's the strongest argument for starting cryptographic inventory work now rather than waiting for a mandate.
How Safeguard Helps
Migrating to the NIST post-quantum standards starts with knowing exactly where classical cryptography is embedded in your software supply chain today, and that's precisely the visibility gap Safeguard closes. Safeguard inventories the algorithms behind every signature, certificate, and key exchange used across your build pipelines, container images, and third-party dependencies, producing a cryptographic bill of materials alongside your existing SBOM so you can see which artifacts still depend on RSA or ECC signing before an auditor asks. As package registries, Sigstore, and CI/CD signing tools roll out support for ML-DSA and ML-KEM, Safeguard verifies provenance and attestations against whichever signature scheme an artifact actually used, so your verification pipeline doesn't break the moment a vendor upstream migrates. For teams tracking CNSA 2.0 and federal deadlines, Safeguard maps discovered cryptographic dependencies to compliance milestones, flagging which signing keys, TLS endpoints, or firmware images need remediation first based on exposure and contractual deadlines rather than guesswork. And because crypto-agility is now a stated requirement rather than a best practice, Safeguard's continuous monitoring re-checks your supply chain as new artifacts are published, so a quantum-resistant migration isn't a one-time audit but a property you can prove on an ongoing basis — to regulators, customers, and your own security team alike.