Post Quantum Crypto Standards

Post-quantum migration standards

Criteria verified as of August 2026. Re-verify on the web before committing to anything (§8).

1. Scope and triggers

Applies to the transition: deciding what to migrate, in what order, on what deadline and with what evidence. Covers: the harvest now, decrypt later (HNDL) threat model and prioritisation by data lifetime, cryptographic inventory and CBOM, choice of PQC algorithm and parameters, deployment of hybrids in TLS, SSH and IKEv2/IPsec, the specific problem of signatures (size, certificate chains, firmware, secure boot), crypto-agility as a design requirement, regulatory timelines (NIST IR 8547, SP 800-131A, CNSA 2.0) and their translation into a multi-year budgeted plan.

Triggers: ML-KEM/ML-DSA/SLH-DSA/FN-DSA/HQC, Kyber/Dilithium/Falcon/SPHINCS+, FIPS 203/204/205/206, X25519MLKEM768, 0x11EC, mlkem768x25519-sha256, sntrup761x25519-sha512@openssh.com, ke1_mlkem768, RFC 9370, RFC 8784, liboqs, oqsprovider, PQCSecretKey, CBOM, "quantum-safe", "crypto-agility", "Q-day", CNSA 2.0, NIST IR 8547.

Not applicable: see cryptography-pki-standards (mother skill and hard boundary: the choice of classical algorithm, AEAD modes, password hashing, randomness, the whole PKI — CA hierarchy, nameConstraints, ACME, certificate lifecycle and revocation—, key custody in HSM/KMS, mTLS and pinning, and the ban on rolling your own crypto. Here only the transition: what gets replaced, when, in what order and how it is proven. If the question is "which CA and with which keys", it is theirs; if it is "when do I stop being able to use that key and why do I replace it", it belongs here), secrets-management-standards (custody and rotation of the already-generated secret), networking-standards and load-balancing-standards (TLS termination at the edge and its configuration), vpn-standards (the tunnel as a service: wg0.conf, swanctl.conf, IKEv2 proposals, the concentrator and its operation — here only which PQC key exchange to require and on what deadline), identity-access-management-standards (JOSE/JWT, tokens and federation), cicd-standards (artifact signing and runner OIDC inside the pipeline), kubernetes-standards (cert-manager and admission-time verification), vulnerability-management-standards (CVE triage and patching SLA: "quantum risk" is not a CVE and does not enter their queue), grc-compliance-standards (formal acceptance of residual risk and audit evidence), opensource-licensing-standards (licence of the PQC libraries you introduce), solidity-standards (chain signature primitives), assembly-standards (constant-time implementation), mlsecops-standards and ai-governance-standards (nothing to do with this: "quantum" in AI marketing is not this).

2. Default decisions

No datum in this table gets written from memory into a deliverable. Dates and states of FIPS, IR 8547 and CNSA 2.0 are re-verified before committing to a plan (§8).

3. HNDL: urgency is set by the data, not the system

• Harvest now, decrypt later: the adversary captures encrypted traffic today and decrypts it when a capable machine exists. That is why the deadline is not "when the quantum computer arrives": it is today minus the data's lifetime.
• Mosca's rule, and it is the only arithmetic needed: if X = years the data must stay secret, Y = years it takes you to migrate and Z = years until a CRQC (cryptanalytically relevant quantum computer) exists, you have a problem if X + Y > Z. Nobody knows Z; you do know X and Y, and they are the only ones you can change.
• Prioritise by data type, not by system criticality: medical records, genetic data, identity, trade secrets, classified material, legal files and PKI and firmware root keys have decade-long lifetimes. An encrypted shopping cart has a lifetime of minutes and is not urgent. A "critical" system that only moves perishable data is less urgent than an archived backup of personal data.
• Real HNDL surfaces: VPNs and interconnections (the traffic is interceptable and archivable), off-site backups and replication, encrypted messaging and mail, traffic towards cloud providers, and anything crossing a network you do not control.
• Signatures do not suffer HNDL. A signature only matters while it is being verified: forging it in 2035 does not help whoever captured it in 2026. That is why encryption is more urgent than signature — with one exception that is urgent: the root of trust that cannot be updated (firmware, secure boot, field devices with a 15-20 year life). There the signature is decided today because there will be no second chance.

4. Inventory and CBOM: the first real step

• Without an inventory there is no migration, there is burnt budget. Before touching a single handshake: where crypto is used, with what algorithm, with what key size, with what library and version, who owns it and how long the data it protects lives.
• Sources that must be cross-referenced, because none is enough alone:
  1. Static: code and dependency scanning, grep for primitives, binary analysis. Finds what is written, not what runs.
  2. Dynamic: what is actually negotiated on the wire (TLS version, group, suite, certificate signature algorithm). Finds reality, not intent.
  3. Certificate and key inventory: internal CAs, stores, HSM/KMS, SSH keys, code- and firmware-signing keys. That is where the surprises live.
  4. Third parties: SaaS, suppliers, embedded devices and everything you cannot recompile. Here migration is contractual, not technical: put it in the clauses and in the supplier review now, not in 2032.
• CBOM: CycloneDX 1.6 (also published as ECMA-424) introduced cryptographic assets; 1.7 refines them. Verify the current version and the exact schema (§8). It is generated in CI, not as an annual export: it is the living work list of the migration and the evidence the audit will ask for.
• Inventory output: each asset with data class, lifetime, current algorithm, who changes it and in what window. Without those five columns it is not an inventory, it is a list.

5. How it is deployed today (real, verifiable state)

Published and pending standards

• Published on 13 Aug 2024, effective 14 Aug 2024 (Federal Register, 89 FR / issuance announcement): FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM, from CRYSTALS-Kyber), FIPS 204 — Module-Lattice-Based Digital Signature Standard (ML-DSA, from CRYSTALS-Dilithium) and FIPS 205 — Stateless Hash-Based Digital Signature Standard (SLH-DSA, from SPHINCS+). The same day the CMVP updated SP 800-140C (FIPS 204/205 as approved signature methods) and SP 800-140D (FIPS 203 as an approved KEM) — a datum that matters if you have a FIPS 140-3 requirement.
• FIPS 206 (FN-DSA, from FALCON): still not a final standard as of August 2026. NIST submitted the draft for approval on 28 Aug 2025 and at the PQC standardisation conference of Sep 2025 it was listed as "still under development"; final is expected between late 2026 and
  2027. Reason for the delay: the signature's floating-point Gaussian sampling is hard to implement in constant time. Do not pin it in a design until the final exists.
• HQC: selected on 11 Mar 2025 as a diversification KEM (code-based, not lattice-based), as plan B if lattices fall. FIPS expected around 2027. It is not a replacement for ML-KEM nor a reason to wait.
• Names: always use the FIPS names (ML-KEM, ML-DSA, SLH-DSA). "Kyber" and "Dilithium" designate the pre-standard versions, incompatible on the wire with the final ones — the TLS code point change from 0x6399 to 0x11EC exists for exactly that reason.

TLS

• The de facto hybrid is X25519MLKEM768, IANA code point 4588 = 0x11EC (draft-ietf-tls-ecdhe-mlkem), over TLS 1.3. It replaced X25519Kyber768Draft00 (0x6399), which is retired — if your inventory finds it, that is debt, not PQC.
• Real client deployment, verified: Chrome 124 (Apr 2024) enabled the pre-standard by default and Chrome 131 (Nov 2024) switched to X25519MLKEM768; Edge followed via Chromium; Firefox 132 by default on HTTPS and 135 on QUIC/HTTP-3; Apple added it in macOS Tahoe 26 / iOS 26 (autumn 2025). Go retired x25519Kyber768Draft00 and uses X25519MLKEM768 by default in crypto/tls.
• Adoption measured at Cloudflare: ~2 % in early 2024 → ~38 % in Mar 2025 → >50 % of human traffic in Oct 2025 → >60 % of PQ-capable client traffic in Feb 2026 (Cloudflare Radar); a 2026 study measures 57.4 % of browser-initiated connections with a X25519MLKEM768 key share — the difference is the measurement base, not a contradiction. Cite the source and the date or do not use the figure (§8).
• The origin lags far behind: ~10 % on the origin server side in early 2026, after Akamai turned it on by default in Jan 2026. Operational conclusion: the browser is no longer your problem; your origin, your load balancers and your internal services are.
• A side effect to know about before "fixing it": the ~1,088-1,216-byte key share is already used as a bot detection signal. A client claiming to be a modern browser that does not offer X25519MLKEM768 stands out. If you disable PQC "for compatibility", you are changing your fingerprint.

SSH, IKEv2/IPsec and the rest

• SSH: OpenSSH negotiates hybrid by default since 10.0 (mlkem768x25519-sha256; 9.9 introduced it; 10.1 warns when the KEX is not post-quantum). Pin KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com where both ends can reach it. Verify versions before pinning them (§8).
• IKEv2/IPsec: RFC 9370 (additional key exchanges, ke1..ke7) allows adding a PQC KEM on top of the classical DH — a ke1_mlkem768-style proposal in strongSwan. Interim measure when the other end cannot get there: RFC 8784 (post-quantum preshared key mixed into the derivation). Tunnel operation and its config belong to vpn-standards.
• WireGuard does not negotiate: its optional PSK (PresharedKey) gives symmetric HNDL resistance; its own PQC path is external layers such as Rosenpass. Verify status before promising.
• Files and backups: age added hybrid mlkem768x25519 recipients in the 1.1.x series — verify version and recipient compatibility before encrypting with them anything you have to decrypt ten years from now.
• KMS/HSM: AWS KMS offers ML-DSA in validated HSMs (GA since 2025-06-13), Google Cloud KMS took ML-DSA, SLH-DSA and ML-KEM to GA, and Azure Key Vault/Managed HSM was lagging in 2026. Availability by region and by service tier: verify it before designing (§8).

6. Signatures: size, chains and why it hurts differently

• Encryption is migrated by changing a group in the handshake; the signature changes the format of everything signed. A certificate, a chain, a firmware image and a token all grow at once.

• Sizes, verbatim from the official tables (FIPS 203 Table 3, FIPS 204 Table 2, FIPS 205 Table 2), in bytes. Compare them with the 32 B of an X25519 key and the 64 B of an Ed25519 signature:

  Parameter	Public key	Private key	Ciphertext / Signature
  ML-KEM-512	800	1,632	768 (ct)
  ML-KEM-768	1,184	2,400	1,088 (ct)
  ML-KEM-1024	1,568	3,168	1,568 (ct)
  ML-DSA-44	1,312	2,560	2,420 (sig)
  ML-DSA-65	1,952	4,032	3,309 (sig)
  ML-DSA-87	2,592	4,896	4,627 (sig)
  SLH-DSA-128s / 128f	32	—	7,856 / 17,088 (sig)
  SLH-DSA-192s / 192f	48	—	16,224 / 35,664 (sig)
  SLH-DSA-256s / 256f	64	—	29,792 / 49,856 (sig)

  Reading: ML-KEM adds ~1 KB per side to the handshake and is bearable; ML-DSA multiplies the signature by ~30-50× versus Ed25519; SLH-DSA reaches ~50 KB per signature — tiny public key, huge signature and slow signing, in exchange for resting on hashes alone. The s variant optimises size and f speed: choosing wrong doubles the problem.

• Concrete consequences to size up before migrating:

  • Certificate chain: a PQC chain can go from ~4 KB to tens of KB. The ClientHello/ServerHello stops fitting in the initial packets, extra round trips appear and amplification in QUIC. Measure real latency, not just bytes.
  • Firmware and boot: devices with scarce flash and RAM, and with a large public key burnt into ROM that cannot be changed. If the root of trust is not updatable, the signature decision is taken now and for the whole life of the product — and that is why this is the only front where the signature comes before encryption.
  • Tokens and JOSE/COSE: an ML-DSA signature in a cookie or header can blow up size limits of proxies and browsers. Verify the limit beforehand, not in production.

• Crypto-agility is the real deliverable. Design as if the algorithm were going to change twice more:

  • Algorithm identifier and key version as metadata alongside the data/artifact, never implicit.
  • All crypto behind your own interface; no calling the primitive from 40 places. The measure of agility is: how many files do I touch to change algorithm?
  • Negotiation, not a fixed algorithm in the protocol; and the ability to disable an algorithm by configuration without recompiling or redeploying.
  • Test agility by exercising it: an algorithm rotation drill, just like a restore drill. An unrehearsed agility does not exist.

7. Timeline, sustainability and prohibitions

• NIST IR 8547 — "Transition to Post-Quantum Cryptography Standards": as of August 2026 it was still an initial public draft (IPD, 12 Nov 2024), with the comment period closed on 10 Jan 2025 and a planning note of 21 Jan 2025 — there is no confirmed final version; do not cite it as settled law. Its proposed timeline: RSA, ECDSA, ECDH, DSA and FFDH deprecated after 2030 and disallowed after 2035, including the large sizes (RSA-3072, P-384). Correct reading: 2030 is not a migration end date, it is the date from which continuing to use them requires risk analysis and documented justification from the data owner; 2035 removes that option. Hybrid modes do not fall under the 2035 prohibition — that is what makes the phased approach viable. AES-256, SHA-2 and SHA-3 are not on that timeline.

• SP 800-131A: the current final revision is Rev. 2 (2019); Rev. 3 is in initial public draft (Oct 2024), raises the minimum from 112 to 128 bits of strength and merges the asymmetric transition with the post-quantum one. Verify whether it has been finalised (§8).

• CNSA 2.0 (NSA, for National Security Systems only) — timeline by category, cross-checked in agreeing secondary sources; I could not download the original NSA PDF (403 from media.defense.gov): declared gap in §8, verify it against the original before committing to it in a contract:

  Category	Support and prefer	Exclusively use
  Software and firmware signing	2025 (start immediately)	2030
  Web browsers/servers and cloud services	2025	2033
  Traditional networking equipment (VPN, routers)	2026	2030
  Operating systems	2027	2033
  Niche equipment (constrained devices, large PKIs)	2030	2033
  Custom applications and legacy equipment	—	Update or replace by 2033

  CNSA 2.0 algorithms: ML-KEM-1024, ML-DSA-87, AES-256, SHA-384/SHA-512 and LMS or XMSS (SP 800-208) for software and firmware signing. The date that really bites is not any of those in the table: from 1 Jan 2027 every new NSS acquisition is expected to be CNSA 2.0 compliant. FAQ v2.1 (Dec 2024) excludes SLH-DSA from use in NSS, forbids HashML-DSA, excludes HSS and XMSS^MT and rules out FN-DSA — verify it against the original document: it is exactly the kind of detail that gets misquoted. And note: CNSA 2.0 does not apply to anyone who does not operate NSS; using it as an excuse to demand ML-KEM-1024 on a commercial website is over-engineering.

• Public CAs and the CA/Browser Forum — the asymmetry that defines 2026: key exchange is already post-quantum on most traffic, but the server certificate is still ECDSA P-256 or RSA-2048. State verified as of August 2026:

  • S/MIME first: ballot SMC013 (Jul 2025) introduced ML-DSA and ML-KEM into the S/MIME Baseline Requirements, with non-hybrid PQC certificates, for experimentation.
  • TLS not yet: the Server Certificate WG keeps a PQC ballot tracker and a proposal "SC0XX: Allow ML-DSA", but as of May 2026 there was no baseline requirement permitting ML-DSA in publicly trusted certificates (SCWG minutes of 21 May 2026: disagreement on whether traditional X.509 should be part of the transition, doubts about the CT logs, ballot pending a rewrite). Microsoft maintains a pilot of ML-DSA roots for testing only; Chrome announced support for ML-DSA anchors for private PKI in TLS 1.3 from Chrome 150. No public ML-DSA root chains to the stores of Mozilla, Apple, Microsoft or Chrome, and a Jun 2026 study of 32,011 domains measured 0 % adoption of post-quantum hybrid certificates.
  • The chosen path is not changing the signature, it is changing the format: Merkle Tree Certificates (MTC). Let's Encrypt published its roadmap on 3 Jun 2026 (staging environment issuing MTC by late 2026, production in 2027), Chrome declared them its preferred route for the public web and Cloudflare runs an experiment with real traffic; the work is in the IETF PLANTS WG. Reason: a naive signature change would push the HTTPS handshake above 10 KB, which breaks on the order of 5 % of connections on real networks. Collateral pressure: SC-081 cuts the maximum certificate validity in phases, which favours amortising a PQ signature across many certificates (the SC-081 timeline is set by cryptography-pki-standards; verify the current phase).
  • Available today for private PKI: ML-DSA in DigiCert Private CA, AWS Private CA (GA since Nov 2025) and OpenSSL 3.5 with the OQS provider. Planning consequence: your internal PKI can migrate signatures now; your public chain does not depend on you.

• Cadence: review the PQC plan every six months for as long as the transition lasts and regenerate the CBOM on every release. Every exception (a third party that cannot get there, a device that cannot be updated) carries an exit date, an owner and a ticket.

FORBIDDEN

• ❌ Writing a deprecation or prohibition date from memory. A misquoted year shifts a multi-year plan and a budget.
• ❌ Citing NIST IR 8547 as a final standard while it remains a draft, or presenting 2030 as a "migration deadline".
• ❌ Deploying ML-KEM without a classical component in production during the transition: if a lattice weakness appears, the hybrid saves you and the pure one does not.
• ❌ Pinning FN-DSA/FIPS 206 or HQC in a design before the final standard exists.
• ❌ Using Kyber/X25519Kyber768Draft00 (0x6399) or any pre-standard variant in production, or treating them as equivalent to the final ones.
• ❌ Implementing a PQC algorithm yourself. The rule from cryptography-pki-standards still holds: FORBIDDEN to implement your own primitives, and here more so, because side-channel attacks on lattices are an active field.
• ❌ Migrating without an inventory or CBOM, or prioritising by system instead of by data lifetime.
• ❌ Stateful keys (LMS/XMSS) without strict index control: reusing an index breaks the scheme, it does not degrade it.
• ❌ Selling "quantum-safe" or "quantum-proof" without saying which concrete surface is migrated and measured. It is the most inflated claim in the industry.
• ❌ Buying QKD or "quantum crypto" as a substitute for PQC: they are different things, and several national agencies advise against QKD for general use — verify their current position before spending (§8).
• ❌ Demanding CNSA 2.0 parameters on systems that are not National Security Systems "just in case".

8. Mandatory web verification

Before pinning an algorithm, date, figure or state in a deliverable:

1. NIST's CSRC, publication by publication: FIPS 203/204/205 (final), FIPS 206 (still a draft?), HQC (is there a FIPS yet?), IR 8547 (IPD or final? exact dates of deprecated/disallowed), SP 800-131A (Rev. 2 or Rev. 3 final?) and SP 800-208. Transition tables are quoted verbatim.
2. CNSA 2.0: the NSA's current advisory and FAQ, with their version number and date. Timeline and exclusions (SLH-DSA, HashML-DSA, HSS/XMSS^MT, FN-DSA) verbatim.
3. Sizes of key, ciphertext and signature (§6): taken verbatim from FIPS 203 Table 3, FIPS 204 Table 2 and FIPS 205 Table 2 in this revision; re-check if the edition changes.
4. TLS deployment state: code point and exact group name, support by browser and by server, and measured adoption with source and date (Cloudflare Radar or another). Never a figure without an origin.
5. Versions: OpenSSH (hybrid KEX by default and non-PQ KEX warning), OpenSSL/AWS-LC/ BoringSSL, strongSwan, Go, age, liboqs/oqsprovider and their open CVEs.
6. PQC in your KMS/HSM: algorithms, regions and FIPS 140-3 validation of the specific module in the CMVP, not the press release.
7. Public CAs and the CA/Browser Forum: state of the ML-DSA ballot in the TLS Baseline Requirements, progress of Merkle Tree Certificates (PLANTS WG, Let's Encrypt, Chrome) and what your CA supports today.
8. CycloneDX/CBOM: current version of the cryptographic assets schema.
9. European regulators: PQC roadmap from the Commission and from ENISA, and the guidance from ANSSI, BSI and CCN — they impose their own deadlines in public procurement.

Declared gaps in this version (close them before using the document in a real plan):

• The original CNSA 2.0 PDF and the NSA FAQ could not be downloaded (403 from media.defense.gov): the timeline and the exclusions come from agreeing secondary sources, not from a verbatim quote of the original.
• Final state of FIPS 206, of HQC and of SP 800-131A Rev. 3: verified as pending as of August 2026 via secondary sources; confirm against CSRC.
• The versions of OpenSSH, age, AWS/Google/Azure KMS in §5 are inherited from cryptography-pki-standards (verified there); re-confirm them before pinning them.

Already closed in this revision (do not repeat the work): FIPS 203/204/205 sizes taken verbatim from the official tables, and the state of the CA/Browser Forum and of Merkle Tree Certificates.

If the web contradicts this document, the web wins — flag the discrepancy.