What NIST Post-Quantum Cryptography Standards Mean for Your Organization

The answer, up front

NIST's post-quantum cryptography standards are not a research recommendation. FIPS 203, 204, and 205, finalized in 2024, name the specific algorithms federal systems and their supply chains must migrate to, and NIST's draft IR 8547 proposes dates for that requirement: NIST would deprecate quantum-vulnerable algorithms at the 112-bit strength after 2030 and disallow all quantum-vulnerable algorithms, including RSA and elliptic-curve cryptography, after 2035. That combination, a named destination plus a binding deadline, is what moves post-quantum migration out of the research backlog and into the same category as any other compliance mandate with a real date attached.

The three standards, plainly

Each of the three published standards solves a different problem, and understanding which is which matters for scoping a migration correctly.

• FIPS 203, ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism). This replaces RSA and Diffie-Hellman key exchange, the part of a TLS handshake or VPN connection that establishes a shared secret. It is the algorithm most systems will touch first, because key exchange is everywhere: web traffic, VPNs, internal service-to-service connections.
• FIPS 204, ML-DSA (Module-Lattice-Based Digital Signature Algorithm). This replaces RSA and ECDSA signatures, used for code signing, certificate authorities, and authentication. Signature migration tends to be harder than key-exchange migration because signatures are long-lived, a signed firmware image or a root certificate can remain valid and in use for years.
• FIPS 205, SLH-DSA (Stateless Hash-Based Digital Signature Algorithm). This is the backstop. Both ML-KEM and ML-DSA rely on lattice mathematics, a comparatively newer foundation than the hash functions SLH-DSA is built on. NIST standardized a structurally independent signature scheme specifically so that if a weakness is ever found in lattice cryptography, there is already a vetted, standardized alternative rather than a return to the drawing board.

Why the timeline is the part that makes this real

A named algorithm without a deadline is guidance. NIST's draft IR 8547 proposes turning FIPS 203 through 205 into a schedule: the draft would deprecate quantum-vulnerable algorithms at the 112-bit strength after 2030, meaning continued use requires a documented exception, and would disallow all quantum-vulnerable algorithms after 2035, meaning NIST-conformant systems could no longer use them at all. The document is still an initial public draft. Executive Order 14412 extends the pressure further, pushing the mandate down through federal agencies to their contractors and, by extension, into the vendor base those contractors depend on.

That flow-down matters more than most organizations realize at first. An organization with no direct NIST reporting obligation can still find the deadline arriving through a prime contract clause, a vendor security questionnaire, or a customer's own compliance program. By the time the requirement shows up that way, the runway to migrate calmly is much shorter than it looked from the outside.

What compliance actually requires

Naming an algorithm is the easy part. Demonstrating compliance requires an organization to be able to answer four questions, in order, for every system in its estate:

1. What cryptography is running, and where? This is the inventory question, and it has to span source code, dependencies, certificates, infrastructure, binaries, and runtime tokens, not just the surfaces a single scanning tool happens to cover.
2. Which instances are quantum-vulnerable, and how exposed is each one? Not every RSA key carries the same risk. Data sensitivity, system criticality, and how long the data has to stay confidential all change the priority.
3. What is the migration plan, with owners and dates? A spreadsheet of findings is not a program. Regulators and auditors expect a sequenced roadmap with accountable owners, not a one-time report.
4. Can you produce evidence for the decision? Audit and defensibility requirements mean the organization needs a documented trail, not just a completed migration, showing what the organization found, what it prioritized, why, and what it did about it.

That fourth question is where most organizations underestimate the work. A migration that happened but leaves no evidence does not satisfy an auditor, a regulator, or a board asking whether the organization is compliant.

What this means in practice

Read FIPS 203, 204, and 205 as a bill of materials, not a research paper: they tell you exactly which algorithms your inventory needs to move to. Read NIST IR 8547's proposed 2030 and 2035 dates as the planning deadline, not a distant horizon. And build the inventory, prioritization, and evidence trail as a standing program, because the four compliance questions above do not get answered once and stay answered.

QuTrust maps findings to FIPS 203, 204, and 205 automatically and maintains the living roadmap and evidence trail that a board, auditor, or regulator will actually accept.