The post-quantum standards, explained

NIST FIPS 203

FIPS 203 standardizes ML-KEM, the NIST post-quantum key-encapsulation mechanism that replaces classical key exchange (RSA, ECDH). What it is, its parameter sizes, the input checks that trip up implementations, and how to migrate and verify.

NIST FIPS 204

FIPS 204 standardizes ML-DSA, the NIST post-quantum signature scheme that replaces RSA, ECDSA, and EdDSA. What it is, its parameter sets and sizes, the verification behaviour that trips up implementations, and how to migrate and conformance-test.

NIST FIPS 205

FIPS 205 standardizes SLH-DSA, the stateless hash-based signature scheme whose security rests on nothing but the hash function. Why it is the conservative backup signature, its twelve parameter sets and large signatures, where it fits, and how to adopt it.

NSA CNSA 2.0

CNSA 2.0 is the NSA's post-quantum algorithm suite for US national-security systems and their vendors. Which algorithms it selects, the transition timeline that ends in 2033, why it does not require hybrids, and how to plan a compliant migration.

NIST SP 800-208

SP 800-208 approves the stateful hash-based signature schemes LMS/HSS and XMSS/XMSS^MT for post-quantum firmware and software signing. What they are, why they are restricted to bounded-signature settings, the state-reuse hazard that breaks them, and how to deploy and verify them safely.

IETF TLS 1.3 hybrid key exchange · X25519MLKEM768 (0x11EC)

TLS 1.3 hybrid key exchange combines classical (EC)DHE with a post-quantum KEM so the session key survives a break in either. What X25519MLKEM768 is, its codepoint and handshake cost, the middlebox pitfall, and how to migrate, audit, and conformance-test it.

ISO/IEC 27001:2022 Annex A 8.24

Annex A control 8.24 of ISO/IEC 27001:2022 governs how your ISMS uses cryptography: a crypto policy plus key-lifecycle management. It names no algorithms and no post-quantum requirement, but it is the clause under which certification auditors now probe quantum risk. What it requires, why 'AES/RSA' is no longer evidence, and how to satisfy it.

US NSM-10 (2022) + OMB M-23-02

NSM-10 and OMB M-23-02 are the two linked US federal instruments driving post-quantum migration. What each requires, why the prioritized cryptographic inventory is the defining obligation, how the 2035 mitigation goal lines up with NIST's and NSA's timelines, and how to comply.

NIST IR 8547

NIST IR 8547 is NIST's draft roadmap for retiring quantum-vulnerable public-key cryptography: RSA, Diffie–Hellman, ECDSA and EdDSA are deprecated after 2030 and disallowed after 2035. What the timeline says, which PQC standards replace what, and how to plan against it now.

Regulation (EU) 2022/2554

DORA is the EU regulation that makes ICT risk management a directly applicable legal obligation for financial entities (banks, insurers, investment firms, crypto-asset providers, and their critical ICT vendors) from 17 January 2025. It names no PQC deadline of its own, but its risk-management framework demands a cryptographic-controls policy that tracks cryptanalysis. What it requires, and where a cryptographic inventory fits as evidence.

Directive (EU) 2022/2555

NIS2 is the EU directive that raised the cybersecurity baseline for "essential" and "important" entities across critical sectors, with a national transposition deadline of 17 October 2024. Article 21 names policies on the use of cryptography and encryption among the minimum risk-management measures. What the directive requires, what it says about cryptography, and where a PQC readiness assessment fits as evidence.

Cross-mandate timeline

Every post-quantum deadline that binds an organisation, on one axis: NIST IR 8547, CNSA 2.0, NSM-10, NIS2, DORA and ISO 27001, with what each one actually obliges you to do.

NIST FIPS 140-3

What FIPS 140-3 validates, why it is not the same as implementing ML-KEM correctly, and what the 21 September 2026 historical-list date means for a module you already depend on.

PCI DSS v4.0.1

What PCI DSS v4 actually requires about cryptography, why requirement 12.3.3 is crypto-agility in audit language, and why it sets no post-quantum deadline of its own.

OWASP CycloneDX Cryptography Bill of Materials

A CBOM is a Cryptography Bill of Materials, an OWASP CycloneDX extension that inventories algorithms, protocols, certificates, and keys in a structured, diffable form. What it captures, how it is produced and consumed, and how it turns a stale inventory spreadsheet into a living, automatable artifact.

OASIS SARIF 2.1.0

SARIF is the OASIS JSON format for static-analysis and code-scanning output. When a scanner that hunts quantum-vulnerable cryptography emits SARIF, its findings flow into GitHub code scanning, pull-request annotations, and CI gates you already run, with no bespoke report. What SARIF is, how PQC crypto-finding tools use it, and why the format alone proves nothing.

OpenVEX

OpenVEX is a minimal, machine-readable implementation of VEX, a producer's assertion of whether a specific product is actually affected by a given vulnerability. What VEX is, its four statuses, how it cuts false-positive noise from CBOM and scanner output, and why a not_affected claim about quantum risk is only as good as its justification.

IETF Internet-Draft draft-acosta-crypto-agility-manifest

The crypto-agility manifest is a proposed convention (an IETF Internet-Draft, not a ratified standard) for publishing a site or repository's post-quantum posture as a small JSON document at /.well-known/crypto-agility.json. What the manifest contains, how agents and CI consume it, and why a self-published posture summary only becomes trustworthy with signed attestation and continuous regeneration.