The PQC standards landscape

The post-quantum standards landscape looks sprawling from the outside — a dozen documents from NIST, the NSA, the White House, and several standards bodies, published over three years and still arriving. It is easier to navigate once you see that the pieces fall into three layers that answer three different questions. The algorithm standards tell you what to deploy: the specific quantum-resistant primitives that replace RSA and elliptic-curve cryptography. The policy and deployment layer tells you when: the deadlines and mandates that turn a technical option into a compliance requirement. And the interchange formats tell you where you stand today: the machine-readable inventories and findings that let you measure the gap between the two. The urgency underneath all three is harvest-now, decrypt-later — traffic and data an adversary can record today and decrypt once a cryptographically-relevant quantum computer exists — which is why migration cannot wait for that computer to arrive.

Algorithms: what to deploy

NIST finalized the first three post-quantum standards on 13 August 2024, after an eight-year public competition. Two are lattice-based and general-purpose; one is a hash-based backstop that rests on more conservative assumptions; and an older special-purpose standard covers firmware and code signing. Together they replace every classical public-key primitive in common use.

• FIPS 203 (ML-KEM) — the key-encapsulation mechanism that replaces RSA key transport and (EC)DH key exchange. This is the first thing to migrate, because key exchange is the surface most exposed to harvest-now-decrypt-later.
• FIPS 204 (ML-DSA) — the primary digital-signature standard (lattice-based, ex-Dilithium) for authentication, certificates, and general signing.
• FIPS 205 (SLH-DSA) — a stateless hash-based signature scheme whose security rests only on the hash function, making it the conservative hedge if a lattice weakness is ever found.
• NIST SP 800-208 (LMS/XMSS) — stateful hash-based signatures, the right tool for firmware and code signing where the signing state can be managed carefully.

Deployment & policy: when to move

The algorithms are optional until policy makes them mandatory — and it now has. Overlapping mandates from the NSA, the White House, and NIST set the deadlines that drive real migration programs, while the TLS hybrid standard defines how the new algorithms actually protect traffic on the wire. Read these to know which clock applies to you and when it runs out.

• CNSA 2.0 — the NSA suite for National Security Systems: ML-KEM and ML-DSA exclusively by 2033, with no hybrid requirement (national-security systems accept the pure post-quantum algorithms).
• NSM-10 & OMB M-23-02 — the US federal mandate to build a cryptographic inventory and migrate, with a 2035 mitigation target for high-value systems.
• NIST IR 8547 — the deprecation timeline: quantum-vulnerable algorithms deprecated after 2030 and disallowed after 2035, the schedule most commercial programs plan their migration roadmap against.
• TLS hybrid key exchange — X25519MLKEM768, already the deployed default in major browsers and servers, protecting the connection even if either the lattice or the classical half is broken.

Interchange & tooling: where you stand

You cannot manage what you cannot measure, and a migration this large is unmanageable without machine-readable evidence. Three formats let inventory, scanning, and risk assessment flow between tools instead of living in spreadsheets — the raw material for crypto-agility and for tracking progress against the deadlines above.

• CycloneDX CBOM — the Cryptography Bill of Materials, a machine-readable inventory of the algorithms, keys, and certificates in your systems.
• SARIF — the OASIS interchange format for static-analysis findings, so cryptography-detection results from many scanners land in one normalized view.
• OpenVEX — Vulnerability Exploitability eXchange assertions, letting you record which quantum-vulnerable findings actually apply in context and which are already mitigated.

How quantakrypto helps

Those three layers map directly onto the four things we do. We turn the tooling layer into a real picture of your exposure — building the CBOM inventory and ranking harvest-now-decrypt-later risk (audit). We take the algorithm and policy layers and execute the transition to ML-KEM, ML-DSA, and hybrid key exchange without breaking production (migration). We prove the implementation you ship actually conforms to FIPS 203/204/205 — not merely that it passes the known-answer vectors (certification). And we get your engineers fluent in the standards and deadlines so the program outlives any single project (training). Start with whichever layer is most urgent for you; each page below goes deeper, and each routes back here.