NIST PQC standards guide

NIST post-quantum cryptography standards: what migration teams need to track

NIST has finalized three initial post-quantum standards and continues related standardization and migration work. Organizations can begin planning now, but standards publication is only one dependency in a safe production transition.

Decision brief

Primary query
NIST PQC standards
Best for
Teams that need reviewable cryptographic evidence, ownership, and continuous migration control.
Safety boundary
Evidence supports decisions; it is not proof of implementation safety or compliance.

FIPS 203 specifies ML-KEM for key establishment, FIPS 204 specifies ML-DSA for digital signatures, and FIPS 205 specifies SLH-DSA for stateless hash-based digital signatures. NIST reports that FIPS 206, based on FALCON, remains in development, and that HQC was selected for future standardization as an additional key-encapsulation mechanism. Teams should use current NIST pages rather than copying algorithm lists from undated vendor material.

A standards register should track publication status, approved parameters, implementation and module availability, protocol integration, platform support, interoperability, performance, and organizational policy. An inventory then identifies where current public-key cryptography appears and which systems can adopt supported replacements. Historical evaluations must retain the standards and policy version used at the time.

Capabilities

What the operating model needs to do

01

Current source register

Track NIST standards, project updates, migration publications, dates, and organizational interpretation.

02

Use-case mapping

Distinguish key establishment, digital signatures, certificate or protocol use, and implementation dependencies.

03

Inventory linkage

Connect observed quantum-vulnerable assets to candidate standards, owners, products, and migration waves.

04

Implementation evidence

Record library version, configuration, interoperability, performance, security review, rollout, and rollback.

Workflow

A repeatable path to evidence

Use explicit scope, accountable decisions, and verification gates. Keep unknowns visible so progress is not manufactured by narrowing the denominator.

  1. 1

    Monitor

    Assign ownership for current NIST publications and related protocol or platform support.

  2. 2

    Translate

    Create versioned internal policy and architecture guidance with source citations and explicit scope.

  3. 3

    Test

    Use supported implementations in representative non-production environments and capture reproducible results.

  4. 4

    Adopt carefully

    Migrate through approved waves, verify deployed state, and update controls that prevent regression.

Expected deliverables

Artifacts the next team can inspect

  • Dated NIST standards register
  • Internal policy and architecture mapping
  • Affected cryptographic inventory
  • Implementation and interoperability test record
  • Migration and verification plan

Buyer checklist

Questions for a proof of value

  1. 01Are we reading the current NIST publication?
  2. 02Which standardized function fits each protocol use case?
  3. 03Is a supported implementation available in our actual stack?
  4. 04Have we measured performance and failure behavior?
  5. 05Can every migration decision be traced to standards and test evidence?

Limits and cautions

What this page does not promise

  • Algorithm standardization does not validate every implementation or protocol composition.
  • NIST work continues; teams must monitor authoritative updates.
  • Qubrisk records evidence and policy but does not provide FIPS module validation.
Local-first discovery

Start with evidence from one representative repository

Run a scoped scan, inspect every result, export the CBOM, and decide whether the evidence is strong enough to support your operating model.

Create a workspace