# PQC Audit Index > Post-quantum cryptography standards, dates, standards bodies, and the firms that audit them. Compiled by the PQC Audit Index editors (PQC Audit Index). Last reviewed 2026-09-12. Every page has a summary.txt and data.json sibling; site-wide JSON at /api/index.json. ## Algorithms - [ML-KEM (CRYSTALS-Kyber)](https://pqaudit.org/algorithms/ml-kem/): ML-KEM is the NIST-standardized post-quantum key-encapsulation mechanism, published as FIPS 203 on 2024-08-13. It is derived from CRYSTALS-Kyber and is the primary algorithm for quantum-resistant key establishment. - [ML-DSA (CRYSTALS-Dilithium)](https://pqaudit.org/algorithms/ml-dsa/): ML-DSA is the NIST-standardized post-quantum digital signature algorithm, published as FIPS 204 on 2024-08-13. It is derived from CRYSTALS-Dilithium and is NIST's primary recommendation for quantum-resistant signatures. - [SLH-DSA (SPHINCS+)](https://pqaudit.org/algorithms/slh-dsa/): SLH-DSA is the NIST-standardized stateless hash-based signature scheme, published as FIPS 205 on 2024-08-13. It is derived from SPHINCS+ and relies only on the security of hash functions, making it the conservative backup to lattice signatures. - [FN-DSA (Falcon)](https://pqaudit.org/algorithms/fn-dsa/): FN-DSA is NIST's name for Falcon, the fourth post-quantum signature scheme selected in 2022. It will be published as FIPS 206. As of 2026-09 the standard is still in draft; NIST submitted the initial public draft for approval in 2025-08 and a final standard is expected in late 2026 or 2027. - [HQC (Hamming Quasi-Cyclic)](https://pqaudit.org/algorithms/hqc/): HQC is the code-based KEM that NIST selected on 2025-03-11 (NIST IR 8545) as a backup to ML-KEM, so that a break of lattice cryptography does not leave the world without a standardized post-quantum KEM. NIST expects to publish a draft standard, anticipated as FIPS 207, in 2026 and a final standard in 2027. - [LMS / HSS (Leighton-Micali Signatures, Hierarchical Signature System)](https://pqaudit.org/algorithms/lms-hss/): LMS and its multi-tree variant HSS are stateful hash-based signatures specified in RFC 8554 (2019-04) and approved by NIST in SP 800-208 (2020-10). They are the signature schemes CNSA 2.0 requires for firmware and software signing, and are the first post-quantum signatures many hardware roots of trust support. - [XMSS / XMSS^MT (eXtended Merkle Signature Scheme)](https://pqaudit.org/algorithms/xmss/): XMSS and its multi-tree variant XMSS^MT are stateful hash-based signatures specified in RFC 8391 (2018-05) and approved by NIST in SP 800-208 (2020-10). Like LMS, they are permitted under CNSA 2.0 and are used for firmware signing and in some blockchains (for example QRL). - [Hybrid TLS 1.3 key exchange (X25519MLKEM768) (ECDHE-MLKEM)](https://pqaudit.org/algorithms/hybrid-tls-x25519mlkem768/): RFC 10024 (2026-08) standardizes hybrid post-quantum key agreement for TLS 1.3, defining the named groups X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. X25519MLKEM768 is the default post-quantum key exchange in Chrome, Firefox, Safari, Cloudflare, OpenSSL 3.5+, and Go, and is the most widely deployed post-quantum cryptography on the internet. - [Classic McEliece (McEliece (Goppa codes))](https://pqaudit.org/algorithms/classic-mceliece/): Classic McEliece is the oldest post-quantum KEM design (1978) and the most conservative. NIST did not select it in the fourth round (2025-03-11) because of its very large public keys, but Germany's BSI recommends it in TR-02102-1 and it is being standardized through ISO/IEC. It matters for audits because European and defense customers deploy it. - [FrodoKEM (Frodo)](https://pqaudit.org/algorithms/frodokem/): FrodoKEM is a conservative lattice KEM based on unstructured LWE, avoiding the algebraic structure of ML-KEM. NIST did not advance it past Round 3 for performance reasons, but BSI and ANSSI recommend it and it is being standardized under ISO/IEC 18033-2. It is relevant for European regulated deployments. ## Migration timelines - [NIST IR 8547: U.S. federal deprecation timeline](https://pqaudit.org/timelines/nist-ir-8547/): NIST IR 8547 sets the U.S. federal timeline for retiring quantum-vulnerable public-key cryptography: RSA, ECDSA, EdDSA, ECDH, and finite-field DH at 112-bit security are deprecated after 2030 and all quantum-vulnerable public-key algorithms are disallowed after 2035. - [CNSA 2.0: U.S. National Security Systems](https://pqaudit.org/timelines/cnsa-2-0/): CNSA 2.0 is the NSA's required algorithm suite for U.S. National Security Systems. It mandates ML-KEM-1024, ML-DSA-87, LMS/XMSS for firmware signing, AES-256, and SHA-384/512, with a phased timeline that starts in 2025 and ends with exclusive post-quantum use by 2035. From 2027-01-01 all new NSS acquisitions must be CNSA 2.0 compliant. - [EU Coordinated Implementation Roadmap for PQC](https://pqaudit.org/timelines/eu-pqc-roadmap/): The EU's coordinated roadmap, published 2025-06-23, asks all member states to start transitioning by the end of 2026, to secure high-risk systems and critical infrastructure with post-quantum cryptography by the end of 2030, and to complete the transition for all systems by 2035. - [UK NCSC migration timeline](https://pqaudit.org/timelines/uk-ncsc-pqc-timeline/): The UK NCSC's timeline, published 2025-03-20, sets three phases: complete discovery and planning by 2028, complete high-priority migrations by 2031, and complete the migration of all systems, services, and products by 2035. - [U.S. NSM-10 and the Quantum Computing Cybersecurity Preparedness Act](https://pqaudit.org/timelines/us-nsm-10-quantum-act/): NSM-10 directs U.S. federal agencies to inventory quantum-vulnerable cryptography and migrate, with a goal of mitigating quantum risk by 2035. The Quantum Computing Cybersecurity Preparedness Act (2022-12-21) makes the inventory and OMB reporting a legal requirement, and OMB M-23-02 sets the annual inventory process. ## Audit firms (in index order) - [zkSecurity](https://pqaudit.org/auditors/zksecurity/): Cryptography audits: post-quantum, zero-knowledge proofs, MPC, FHE, TEEs - [Trail of Bits](https://pqaudit.org/auditors/trail-of-bits/): Software assurance with a dedicated cryptography practice - [NCC Group (Cryptography Services)](https://pqaudit.org/auditors/ncc-group/): Large security consultancy with a specialist Cryptography Services team - [Cryspen](https://pqaudit.org/auditors/cryspen/): Formally verified cryptography and high-assurance post-quantum implementations - [Kudelski Security](https://pqaudit.org/auditors/kudelski-security/): Cryptography audits and quantum-readiness assessments - [Quarkslab](https://pqaudit.org/auditors/quarkslab/): Reverse engineering, cryptography, and secure implementation research - [Least Authority](https://pqaudit.org/auditors/least-authority/): Security audits of cryptographic protocols and privacy-preserving systems - [Galois](https://pqaudit.org/auditors/galois/): Formal verification of cryptographic code - [atsec information security](https://pqaudit.org/auditors/atsec/): FIPS 140-3 and CAVP validation laboratory - [Riscure (Keysight)](https://pqaudit.org/auditors/riscure/): Side-channel and fault-injection evaluation of hardware implementations - [Cure53](https://pqaudit.org/auditors/cure53/): Penetration testing and code audits of open-source and web software - [X41 D-Sec](https://pqaudit.org/auditors/x41-d-sec/): Source-code audits of open-source security and cryptographic software ## Other - [Audit checklist](https://pqaudit.org/audit-checklist/) - [About and methodology](https://pqaudit.org/about/) - [JSON API](https://pqaudit.org/api/index.json) --- # Full text summaries ML-KEM (CRYSTALS-Kyber): standard, dates, parameters, and audit checklist ========================================================================= ML-KEM is the NIST-standardized post-quantum key-encapsulation mechanism, published as FIPS 203 on 2024-08-13. It is derived from CRYSTALS-Kyber and is the primary algorithm for quantum-resistant key establishment. Standard: FIPS 203 Standardized by: NIST (U.S. National Institute of Standards and Technology) Date: 2024-08-13 Status: Final Family: Lattice (Module-LWE) Parameter sets: ML-KEM-512 (cat 1, pk 800 B, ciphertext 768 B); ML-KEM-768 (cat 3, pk 1184 B, ciphertext 1088 B); ML-KEM-1024 (cat 5, pk 1568 B, ciphertext 1568 B) Audit focus: Timing leaks in compression and division (the KyberSlash class of bugs found in 2023-2024 across many Kyber implementations) | Correct implicit rejection in decapsulation (a rejected ciphertext must return a pseudorandom key, never an error signal) | Input validation required by FIPS 203: modulus check on encapsulation keys, hash check on decapsulation keys, ciphertext length checks | Constant-time NTT, sampling, and polynomial arithmetic; no secret-dependent branches or memory access | Randomness: fresh 32-byte seeds per encapsulation, no reuse of d/z across key generations | Hybrid combiners: shared-secret concatenation order and KDF binding to both ciphertexts, per RFC 10024 and SP 800-227 | Known-answer tests against the FIPS 203 final vectors (not the Round 3 Kyber vectors, which differ) Auditors: zkSecurity, Trail of Bits, NCC Group (Cryptography Services), Cryspen, Kudelski Security, Quarkslab, Least Authority, Galois, atsec information security, Riscure (Keysight), Cure53, X41 D-Sec Sources: https://csrc.nist.gov/pubs/fips/203/final | https://csrc.nist.gov/pubs/sp/800/227/final | https://datatracker.ietf.org/doc/rfc10024/ | https://datatracker.ietf.org/doc/rfc9935/ | https://kyberslash.cr.yp.to/ Source page: https://pqaudit.org/algorithms/ml-kem/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 ML-DSA (CRYSTALS-Dilithium): standard, dates, parameters, and audit checklist ============================================================================= ML-DSA is the NIST-standardized post-quantum digital signature algorithm, published as FIPS 204 on 2024-08-13. It is derived from CRYSTALS-Dilithium and is NIST's primary recommendation for quantum-resistant signatures. Standard: FIPS 204 Standardized by: NIST Date: 2024-08-13 Status: Final Family: Lattice (Module-LWE / Module-SIS) Parameter sets: ML-DSA-44 (cat 2, pk 1312 B, signature 2420 B); ML-DSA-65 (cat 3, pk 1952 B, signature 3309 B); ML-DSA-87 (cat 5, pk 2592 B, signature 4627 B) Audit focus: Rejection-sampling loop must not leak the secret through timing or the number of iterations in a way that correlates with secret data | Hedged (randomized) vs deterministic signing: deterministic mode is more exposed to fault attacks; FIPS 204 defaults to hedged | Correct handling of the context string and the pure vs pre-hash (HashML-DSA) variants; domain separation bytes must match FIPS 204 | External-mu signing interfaces (signing a pre-computed message representative) must not allow cross-protocol confusion | Hint computation, bounds checks on z and h, and the verifier's rejection of malformed signatures | Constant-time NTT, decomposition, and unpacking; no secret-dependent table lookups | Known-answer tests against the FIPS 204 final vectors, which differ from Round 3 Dilithium Auditors: zkSecurity, Trail of Bits, NCC Group (Cryptography Services), Cryspen, Kudelski Security, Quarkslab, Least Authority, Galois, atsec information security, Riscure (Keysight), Cure53, X41 D-Sec Sources: https://csrc.nist.gov/pubs/fips/204/final | https://datatracker.ietf.org/doc/rfc9881/ | https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF Source page: https://pqaudit.org/algorithms/ml-dsa/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 SLH-DSA (SPHINCS+): standard, dates, parameters, and audit checklist ==================================================================== SLH-DSA is the NIST-standardized stateless hash-based signature scheme, published as FIPS 205 on 2024-08-13. It is derived from SPHINCS+ and relies only on the security of hash functions, making it the conservative backup to lattice signatures. Standard: FIPS 205 Standardized by: NIST Date: 2024-08-13 Status: Final Family: Hash-based (stateless) Parameter sets: SLH-DSA-SHA2/SHAKE-128s (cat 1, pk 32 B, signature 7856 B); SLH-DSA-SHA2/SHAKE-128f (cat 1, pk 32 B, signature 17088 B); SLH-DSA-SHA2/SHAKE-192s (cat 3, pk 48 B, signature 16224 B); SLH-DSA-SHA2/SHAKE-192f (cat 3, pk 48 B, signature 35664 B); SLH-DSA-SHA2/SHAKE-256s (cat 5, pk 64 B, signature 29792 B); SLH-DSA-SHA2/SHAKE-256f (cat 5, pk 64 B, signature 49856 B) Audit focus: Fault-injection resistance: a single fault during WOTS+ or FORS signing can leak enough to forge; check for redundant computation or verification-after-signing | Correct ADRS (address) construction and domain separation across the hypertree, FORS, and WOTS+ layers | Pre-hash (HashSLH-DSA) and context-string handling must match FIPS 205 | Randomizer generation (opt_rand) and hedged signing | Denial-of-service surface: signature verification cost and signature size (up to 49,856 bytes) in protocols | Known-answer tests against FIPS 205 final vectors Auditors: zkSecurity, Trail of Bits, NCC Group (Cryptography Services), Cryspen, Kudelski Security, Quarkslab, Least Authority, Galois, atsec information security, Riscure (Keysight), Cure53, X41 D-Sec Sources: https://csrc.nist.gov/pubs/fips/205/final | https://datatracker.ietf.org/doc/rfc9909/ Source page: https://pqaudit.org/algorithms/slh-dsa/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 FN-DSA (Falcon): standard, dates, parameters, and audit checklist ================================================================= FN-DSA is NIST's name for Falcon, the fourth post-quantum signature scheme selected in 2022. It will be published as FIPS 206. As of 2026-09 the standard is still in draft; NIST submitted the initial public draft for approval in 2025-08 and a final standard is expected in late 2026 or 2027. Standard: FIPS 206 (draft) Standardized by: NIST Date: TBD (draft under review; final expected late 2026 or 2027) Status: Draft Family: Lattice (NTRU, fast-Fourier sampling) Parameter sets: FN-DSA-512 (Falcon-512) (cat 1, pk 897 B, signature 666 B); FN-DSA-1024 (Falcon-1024) (cat 5, pk 1793 B, signature 1280 B) Audit focus: The floating-point Gaussian sampler is the hardest part of any post-quantum standard to implement in constant time; audit emulated-FP paths and every platform-specific FPU behavior | Key generation (NTRU solve) correctness and secret-dependent timing | Signature encoding and the variable-length compression format | Reference implementations still change between draft versions; verify against the exact draft the project targets Auditors: zkSecurity, Trail of Bits, NCC Group (Cryptography Services), Cryspen, Kudelski Security, Quarkslab, Least Authority, Galois, atsec information security, Riscure (Keysight), Cure53, X41 D-Sec Sources: https://csrc.nist.gov/projects/post-quantum-cryptography | https://csrc.nist.gov/presentations/2025/fips-206-fn-dsa-falcon | https://falcon-sign.info/ Source page: https://pqaudit.org/algorithms/fn-dsa/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 HQC (Hamming Quasi-Cyclic): standard, dates, parameters, and audit checklist ============================================================================ HQC is the code-based KEM that NIST selected on 2025-03-11 (NIST IR 8545) as a backup to ML-KEM, so that a break of lattice cryptography does not leave the world without a standardized post-quantum KEM. NIST expects to publish a draft standard, anticipated as FIPS 207, in 2026 and a final standard in 2027. Standard: FIPS 207 (expected designation, draft pending) Standardized by: NIST Date: Selected 2025-03-11; draft standard expected 2026, final 2027 Status: Selected, draft pending Family: Code-based (quasi-cyclic codes) Parameter sets: HQC-128 (cat 1, pk 2249 B, ciphertext 4433 B); HQC-192 (cat 3, pk 4522 B, ciphertext 8978 B); HQC-256 (cat 5, pk 7245 B, ciphertext 14421 B) Audit focus: Constant-time decoding of the concatenated Reed-Muller / Reed-Solomon code | Decryption-failure rate and its impact on IND-CCA security | Quarkslab's 2025 work found correctness and security bugs in several HQC implementations; test against the latest specification | Parameter and encoding changes between Round 4 and the draft standard Auditors: zkSecurity, Trail of Bits, NCC Group (Cryptography Services), Cryspen, Kudelski Security, Quarkslab, Least Authority, Galois, atsec information security, Riscure (Keysight), Cure53, X41 D-Sec Sources: https://www.nist.gov/news-events/news/2025/03/nist-selects-hqc-fifth-algorithm-post-quantum-encryption | https://csrc.nist.gov/pubs/ir/8545/final | https://blog.quarkslab.com/finding-bugs-in-implementations-of-hqc-the-fifth-post-quantum-standard.html Source page: https://pqaudit.org/algorithms/hqc/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 LMS / HSS (Leighton-Micali Signatures, Hierarchical Signature System): standard, dates, parameters, and audit checklist ================================================================================ LMS and its multi-tree variant HSS are stateful hash-based signatures specified in RFC 8554 (2019-04) and approved by NIST in SP 800-208 (2020-10). They are the signature schemes CNSA 2.0 requires for firmware and software signing, and are the first post-quantum signatures many hardware roots of trust support. Standard: RFC 8554 and NIST SP 800-208 Standardized by: IETF / IRTF CFRG (RFC 8554) and NIST (SP 800-208) Date: RFC 8554: 2019-04; SP 800-208: 2020-10-30 Status: Final Family: Hash-based (stateful) Parameter sets: LMS_SHA256_M32_H10 (typical) (cat 5, pk 60 B, signature 1456 B); HSS with 2 levels of H10 (typical) (cat 5, pk 60 B, signature 2964 B) Audit focus: State management is the whole game: a one-time key reused once allows forgery. Audit state persistence, atomic updates, backups, HSM cloning, and crash recovery | SP 800-208 restricts key generation and signing to hardware cryptographic modules for FIPS validation | Parameter-set validation on the verifier, including the Winternitz parameter and tree height | Domain separation constants and the exact hash-input layouts of RFC 8554 Auditors: zkSecurity, Trail of Bits, NCC Group (Cryptography Services), Cryspen, Kudelski Security, Quarkslab, Least Authority, Galois, atsec information security, Riscure (Keysight), Cure53, X41 D-Sec Sources: https://datatracker.ietf.org/doc/rfc8554/ | https://csrc.nist.gov/pubs/sp/800/208/final Source page: https://pqaudit.org/algorithms/lms-hss/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 XMSS / XMSS^MT (eXtended Merkle Signature Scheme): standard, dates, parameters, and audit checklist ================================================================================ XMSS and its multi-tree variant XMSS^MT are stateful hash-based signatures specified in RFC 8391 (2018-05) and approved by NIST in SP 800-208 (2020-10). Like LMS, they are permitted under CNSA 2.0 and are used for firmware signing and in some blockchains (for example QRL). Standard: RFC 8391 and NIST SP 800-208 Standardized by: IRTF CFRG (RFC 8391) and NIST (SP 800-208) Date: RFC 8391: 2018-05; SP 800-208: 2020-10-30 Status: Final Family: Hash-based (stateful) Parameter sets: XMSS-SHA2_10_256 (cat 5, pk 64 B, signature 2500 B); XMSS-SHA2_20_256 (cat 5, pk 64 B, signature 2820 B) Audit focus: Same stateful-key risks as LMS: index reuse, state rollback, backup/restore, and multi-instance deployments | Correct WOTS+ chaining and L-tree computation; hash-address (ADRS) construction | Verifier-side parameter validation and bounds on index values Auditors: zkSecurity, Trail of Bits, NCC Group (Cryptography Services), Cryspen, Kudelski Security, Quarkslab, Least Authority, Galois, atsec information security, Riscure (Keysight), Cure53, X41 D-Sec Sources: https://datatracker.ietf.org/doc/rfc8391/ | https://csrc.nist.gov/pubs/sp/800/208/final Source page: https://pqaudit.org/algorithms/xmss/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 Hybrid TLS 1.3 key exchange (X25519MLKEM768) (ECDHE-MLKEM): standard, dates, parameters, and audit checklist ================================================================================ RFC 10024 (2026-08) standardizes hybrid post-quantum key agreement for TLS 1.3, defining the named groups X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. X25519MLKEM768 is the default post-quantum key exchange in Chrome, Firefox, Safari, Cloudflare, OpenSSL 3.5+, and Go, and is the most widely deployed post-quantum cryptography on the internet. Standard: RFC 10024 Standardized by: IETF TLS Working Group Date: 2026-08 Status: Final (Proposed Standard) Family: Hybrid: X25519 or NIST P-curves combined with ML-KEM Parameter sets: X25519MLKEM768 (cat 3, pk 1216 B, server key share 1120 B); SecP256r1MLKEM768 (cat 3, pk 1249 B, server key share 1153 B); SecP384r1MLKEM1024 (cat 5, pk 1665 B, server key share 1665 B) Audit focus: Key-share encoding order: X25519MLKEM768 places the ML-KEM encapsulation key before the X25519 key, the reverse of the P-curve variants. Getting this wrong is a common interop and security bug | Shared-secret concatenation order into the TLS key schedule and that both components are bound | Downgrade behavior when the peer does not support hybrid groups; HelloRetryRequest handling | ML-KEM encapsulation-key validation on the server side (modulus check) and ciphertext length checks | Middlebox and MTU issues from the 1,216-byte client key share (ClientHello now spans multiple TCP segments) Auditors: zkSecurity, Trail of Bits, NCC Group (Cryptography Services), Cryspen, Kudelski Security, Quarkslab, Least Authority, Galois, atsec information security, Riscure (Keysight), Cure53, X41 D-Sec Sources: https://datatracker.ietf.org/doc/rfc10024/ | https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ Source page: https://pqaudit.org/algorithms/hybrid-tls-x25519mlkem768/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 Classic McEliece (McEliece (Goppa codes)): standard, dates, parameters, and audit checklist ================================================================================ Classic McEliece is the oldest post-quantum KEM design (1978) and the most conservative. NIST did not select it in the fourth round (2025-03-11) because of its very large public keys, but Germany's BSI recommends it in TR-02102-1 and it is being standardized through ISO/IEC. It matters for audits because European and defense customers deploy it. Standard: ISO/IEC standardization in progress; not selected by NIST Standardized by: ISO/IEC JTC 1/SC 27 (in progress); recommended by BSI (Germany) TR-02102-1 Date: NIST fourth round concluded 2025-03-11 without selecting it Status: Not a NIST standard; ISO/IEC process ongoing Family: Code-based (binary Goppa codes) Parameter sets: mceliece348864 (cat 1, pk 261120 B, ciphertext 96 B); mceliece460896 (cat 3, pk 524160 B, ciphertext 156 B); mceliece6688128 (cat 5, pk 1044992 B, ciphertext 208 B) Audit focus: Constant-time Goppa decoding (Berlekamp-Massey) and the Benes network for secret permutation | Handling of the ~1 MB public key: memory safety, transport, caching | Key generation failure handling and rejection sampling Auditors: zkSecurity, Trail of Bits, NCC Group (Cryptography Services), Cryspen, Kudelski Security, Quarkslab, Least Authority, Galois, atsec information security, Riscure (Keysight), Cure53, X41 D-Sec Sources: https://classic.mceliece.org/ | https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr02102/tr02102_node.html Source page: https://pqaudit.org/algorithms/classic-mceliece/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 FrodoKEM (Frodo): standard, dates, parameters, and audit checklist ================================================================== FrodoKEM is a conservative lattice KEM based on unstructured LWE, avoiding the algebraic structure of ML-KEM. NIST did not advance it past Round 3 for performance reasons, but BSI and ANSSI recommend it and it is being standardized under ISO/IEC 18033-2. It is relevant for European regulated deployments. Standard: ISO/IEC 18033-2 amendment in progress; not selected by NIST Standardized by: ISO/IEC JTC 1/SC 27 (in progress); recommended by BSI (Germany) and ANSSI (France) Date: Dropped from NIST process after Round 3 (2022-07); ISO/IEC work ongoing Status: Not a NIST standard; ISO/IEC process ongoing Family: Lattice (plain LWE, unstructured) Parameter sets: FrodoKEM-640 (cat 1, pk 9616 B, ciphertext 9720 B); FrodoKEM-976 (cat 3, pk 15632 B, ciphertext 15744 B); FrodoKEM-1344 (cat 5, pk 21520 B, ciphertext 21632 B) Audit focus: Matrix generation from seed (AES vs SHAKE variants) and its performance/side-channel profile | Constant-time sampling from the rounded-Gaussian table | Ephemeral-only (eFrodoKEM) vs static-key variants and the implicit rejection differences between them Auditors: zkSecurity, Trail of Bits, NCC Group (Cryptography Services), Cryspen, Kudelski Security, Quarkslab, Least Authority, Galois, atsec information security, Riscure (Keysight), Cure53, X41 D-Sec Sources: https://frodokem.org/ Source page: https://pqaudit.org/algorithms/frodokem/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 NIST IR 8547: U.S. federal deprecation timeline: dates and requirements ======================================================================= NIST IR 8547 sets the U.S. federal timeline for retiring quantum-vulnerable public-key cryptography: RSA, ECDSA, EdDSA, ECDH, and finite-field DH at 112-bit security are deprecated after 2030 and all quantum-vulnerable public-key algorithms are disallowed after 2035. Issued by: NIST (U.S.) Date: Initial public draft 2024-11-12 Status: Draft (final pending as of 2026-09) Milestones: 2030: Quantum-vulnerable algorithms at 112-bit security (RSA-2048, P-256, and similar) deprecated | 2035: All quantum-vulnerable public-key algorithms disallowed for U.S. federal use Source: https://csrc.nist.gov/pubs/ir/8547/ipd Source page: https://pqaudit.org/timelines/nist-ir-8547/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 CNSA 2.0: U.S. National Security Systems: dates and requirements ================================================================ CNSA 2.0 is the NSA's required algorithm suite for U.S. National Security Systems. It mandates ML-KEM-1024, ML-DSA-87, LMS/XMSS for firmware signing, AES-256, and SHA-384/512, with a phased timeline that starts in 2025 and ends with exclusive post-quantum use by 2035. From 2027-01-01 all new NSS acquisitions must be CNSA 2.0 compliant. Issued by: NSA (U.S. National Security Agency) Date: 2022-09-07 (algorithm list updated 2025-05) Status: In force Milestones: 2025: Software and firmware signing, web browsers, servers, and cloud services: support and prefer CNSA 2.0 | 2026: Traditional networking equipment (VPNs, routers): support and prefer CNSA 2.0 | 2027-01-01: All new National Security System acquisitions must be CNSA 2.0 compliant | 2030: Software/firmware signing and networking equipment: exclusive CNSA 2.0 use | 2033: Operating systems, browsers, servers, cloud services, custom applications: exclusive CNSA 2.0 use | 2035: All National Security Systems quantum-resistant Source: https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF Source page: https://pqaudit.org/timelines/cnsa-2-0/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 EU Coordinated Implementation Roadmap for PQC: dates and requirements ===================================================================== The EU's coordinated roadmap, published 2025-06-23, asks all member states to start transitioning by the end of 2026, to secure high-risk systems and critical infrastructure with post-quantum cryptography by the end of 2030, and to complete the transition for all systems by 2035. Issued by: European Commission / NIS Cooperation Group, with ENISA Date: 2025-06-23 Status: Adopted Milestones: 2026-12-31: National PQC transition roadmaps published and first steps taken | 2030-12-31: High-risk use cases and critical infrastructure migrated | 2035-12-31: Full transition for all systems Source: https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography Source page: https://pqaudit.org/timelines/eu-pqc-roadmap/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 UK NCSC migration timeline: dates and requirements ================================================== The UK NCSC's timeline, published 2025-03-20, sets three phases: complete discovery and planning by 2028, complete high-priority migrations by 2031, and complete the migration of all systems, services, and products by 2035. Issued by: UK National Cyber Security Centre Date: 2025-03-20 Status: Published guidance Milestones: 2028: Discovery complete: cryptographic inventory and migration plan | 2031: High-priority migrations complete | 2035: Migration complete for all systems, services, and products Source: https://www.ncsc.gov.uk/guidance/pqc-migration-timelines Source page: https://pqaudit.org/timelines/uk-ncsc-pqc-timeline/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 U.S. NSM-10 and the Quantum Computing Cybersecurity Preparedness Act: dates and requirements ================================================================================ NSM-10 directs U.S. federal agencies to inventory quantum-vulnerable cryptography and migrate, with a goal of mitigating quantum risk by 2035. The Quantum Computing Cybersecurity Preparedness Act (2022-12-21) makes the inventory and OMB reporting a legal requirement, and OMB M-23-02 sets the annual inventory process. Issued by: White House (NSM-10) and U.S. Congress (Public Law 117-260) Date: NSM-10: 2022-05-04; Act signed 2022-12-21; OMB M-23-02: 2022-11-18 Status: In force Milestones: 2022-05-04: NSM-10 issued; annual cryptographic inventories begin | 2022-12-21: Quantum Computing Cybersecurity Preparedness Act signed into law | 2035: Target for mitigating quantum risk across federal systems Source: https://www.whitehouse.gov/briefing-room/statements-releases/2022/05/04/national-security-memorandum-on-promoting-united-states-leadership-in-quantum-computing-while-mitigating-risks-to-vulnerable-cryptographic-systems/ Source page: https://pqaudit.org/timelines/us-nsm-10-quantum-act/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 zkSecurity: post-quantum cryptography audit services ==================================================== zkSecurity is a cryptography-focused security firm that audits cryptographic protocols and implementations, including post-quantum schemes such as ML-KEM, ML-DSA, SLH-DSA, FN-DSA, and hash-based signatures, as well as zero-knowledge, MPC, and FHE systems. It was founded by David Wong, author of Real-World Cryptography, and its team consists of practicing cryptographers rather than generalist penetration testers. Website: https://zksecurity.xyz Headquarters: United States (distributed team) Focus: Cryptography audits: post-quantum, zero-knowledge proofs, MPC, FHE, TEEs Post-quantum services: Implementation audits of ML-KEM, ML-DSA, SLH-DSA, FN-DSA, LMS/XMSS, and hybrid key exchange against FIPS 203/204/205, SP 800-227, and RFC 10024 | Protocol-level review of post-quantum migrations (TLS, messaging, blockchain signature schemes, PKI) | Constant-time and side-channel review, known-answer test coverage, and specification conformance | Migration planning: cryptographic inventory, hybrid design, and crypto-agility review | Production-grade cryptographic implementation and research engagements Evidence: https://zksecurity.xyz/reports | https://zksecurity.xyz Source page: https://pqaudit.org/auditors/zksecurity/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 Trail of Bits: post-quantum cryptography audit services ======================================================= Trail of Bits is a security research and consulting firm with a cryptography practice that audits protocols and implementations, including post-quantum ones. In 2026 it added ML-KEM and ML-DSA support to pyca/cryptography with funding from the Sovereign Tech Agency. Website: https://www.trailofbits.com Headquarters: New York, United States Focus: Software assurance with a dedicated cryptography practice Post-quantum services: Cryptographic implementation and protocol reviews | Post-quantum library implementation (pyca/cryptography ML-KEM and ML-DSA, 2026) | Static and dynamic analysis tooling for cryptographic code Evidence: https://trailofbits.com/services/software-assurance/cryptography | https://blog.trailofbits.com/2026/06/30/shipping-post-quantum-cryptography-to-python/ Source page: https://pqaudit.org/auditors/trail-of-bits/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 NCC Group (Cryptography Services): post-quantum cryptography audit services =========================================================================== NCC Group's Cryptography Services practice performs cryptographic design and implementation reviews for enterprise and open-source clients and publishes research on post-quantum migration. Website: https://www.nccgroup.com Headquarters: Manchester, United Kingdom Focus: Large security consultancy with a specialist Cryptography Services team Post-quantum services: Cryptographic implementation and protocol audits | Post-quantum readiness assessments and migration strategy Evidence: https://www.nccgroup.com/us/research-blog/ Source page: https://pqaudit.org/auditors/ncc-group/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 Cryspen: post-quantum cryptography audit services ================================================= Cryspen builds formally verified post-quantum implementations (libcrux ML-KEM and ML-DSA, verified with hax and F*) and performs verification-driven reviews. Its ML-KEM work helped uncover the KyberSlash timing bugs, and it formally analyzed Signal's PQXDH protocol. Website: https://cryspen.com Headquarters: Berlin, Germany Focus: Formally verified cryptography and high-assurance post-quantum implementations Post-quantum services: Formally verified ML-KEM and ML-DSA implementations (Rust and C) | Protocol verification (Signal PQXDH, post-quantum MLS) | High-assurance code review Evidence: https://cryspen.com/post/ml-kem-implementation/ | https://cryspen.com/post/fospqc/ Source page: https://pqaudit.org/auditors/cryspen/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 Kudelski Security: post-quantum cryptography audit services =========================================================== Kudelski Security runs a cryptography audit practice and a Quantum Computing Security Assessment service that inventories an organization's cryptography and delivers a NIST-aligned migration roadmap. Website: https://kudelskisecurity.com Headquarters: Cheseaux-sur-Lausanne, Switzerland Focus: Cryptography audits and quantum-readiness assessments Post-quantum services: Cryptographic protocol and implementation audits | Quantum computing security assessments and migration roadmaps Evidence: https://kudelskisecurity.com/services/ai-emerging-technology/quantum-computing-security Source page: https://pqaudit.org/auditors/kudelski-security/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 Quarkslab: post-quantum cryptography audit services =================================================== Quarkslab is a French security research firm whose cryptography team has published implementation bug-hunting work on HQC and analysis of Signal's post-quantum Triple Ratchet, and performs cryptographic audits for vendors and open-source projects. Website: https://www.quarkslab.com Headquarters: Paris, France Focus: Reverse engineering, cryptography, and secure implementation research Post-quantum services: Cryptographic implementation audits, including post-quantum KEMs and signatures | Automated conformance testing of post-quantum implementations Evidence: https://blog.quarkslab.com/finding-bugs-in-implementations-of-hqc-the-fifth-post-quantum-standard.html | https://blog.quarkslab.com/triple-threat-signals-ratchet-goes-post-quantum.html Source page: https://pqaudit.org/auditors/quarkslab/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 Least Authority: post-quantum cryptography audit services ========================================================= Least Authority performs security audits of cryptographic protocols, wallets, and privacy systems and publishes its audit reports publicly. Website: https://leastauthority.com Headquarters: Berlin, Germany Focus: Security audits of cryptographic protocols and privacy-preserving systems Post-quantum services: Cryptographic protocol and implementation audits | Public audit reports Evidence: https://leastauthority.com/security-consulting/published-audits/ Source page: https://pqaudit.org/auditors/least-authority/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 Galois: post-quantum cryptography audit services ================================================ Galois specializes in formal methods and builds the Cryptol and SAW tools used to prove cryptographic implementations equivalent to their specifications. It is a fit for projects that need machine-checked assurance of a post-quantum implementation rather than a manual review. Website: https://galois.com Headquarters: Portland, Oregon, United States Focus: Formal verification of cryptographic code Post-quantum services: Formal verification of cryptographic implementations against specifications | Cryptol specifications of NIST post-quantum algorithms Evidence: https://cryptol.net/ Source page: https://pqaudit.org/auditors/galois/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 atsec information security: post-quantum cryptography audit services ==================================================================== atsec is an accredited FIPS 140-3 testing laboratory. Post-quantum algorithms need CAVP algorithm validation and CMVP module validation before U.S. federal use; atsec performs that testing for ML-KEM, ML-DSA, SLH-DSA, LMS, and XMSS. Website: https://www.atsec.com Headquarters: Austin, Texas, United States Focus: FIPS 140-3 and CAVP validation laboratory Post-quantum services: CAVP algorithm testing for FIPS 203/204/205 and SP 800-208 algorithms | FIPS 140-3 module validation | Common Criteria evaluation Evidence: https://www.atsec.com/fips-140-3/ Source page: https://pqaudit.org/auditors/atsec/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 Riscure (Keysight): post-quantum cryptography audit services ============================================================ Riscure, now part of Keysight, evaluates hardware and embedded implementations against power, electromagnetic, and fault-injection attacks. Post-quantum implementations in secure elements, HSMs, and roots of trust need this class of physical-attack testing in addition to a code review. Website: https://www.riscure.com Headquarters: Delft, Netherlands Focus: Side-channel and fault-injection evaluation of hardware implementations Post-quantum services: Side-channel analysis of ML-KEM, ML-DSA, and hash-based signature implementations in hardware | Fault-injection testing (particularly relevant to SLH-DSA and deterministic ML-DSA) | Certification support (Common Criteria, EMVCo) Evidence: https://www.riscure.com Source page: https://pqaudit.org/auditors/riscure/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 Cure53: post-quantum cryptography audit services ================================================ Cure53 audits open-source software, browsers, and messaging clients, and publishes its reports. It is frequently used for end-to-end reviews of applications that embed post-quantum libraries. Website: https://cure53.de Headquarters: Berlin, Germany Focus: Penetration testing and code audits of open-source and web software Post-quantum services: Application-level audits of software that integrates post-quantum libraries | Public audit reports Evidence: https://cure53.de/#publications Source page: https://pqaudit.org/auditors/cure53/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 X41 D-Sec: post-quantum cryptography audit services =================================================== X41 D-Sec performs source-code audits of open-source software, including cryptographic libraries, often funded by open-source security programs, and publishes its reports. Website: https://x41-dsec.de Headquarters: Aachen, Germany Focus: Source-code audits of open-source security and cryptographic software Post-quantum services: Source-code audits of cryptographic libraries and protocol implementations | Public audit reports Evidence: https://x41-dsec.de/security/research/ Source page: https://pqaudit.org/auditors/x41-d-sec/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12 Post-quantum cryptography audit checklist (ML-KEM, ML-DSA, SLH-DSA, FN-DSA, LMS/XMSS) ================================================================================ What a post-quantum cryptography audit must cover: specification conformance to FIPS 203/204/205, input validation, constant-time behavior, hedged signing, hybrid combiners, stateful-signature state management, and crypto-agility. Specification conformance: Implements the final FIPS 203/204/205 (2024-08-13) or SP 800-208, not a pre-standard round submission | Passes the NIST ACVP / CAVP known-answer tests for every parameter set shipped | Domain-separation bytes, context strings, and pre-hash variants match the standard exactly Input validation: ML-KEM: modulus check on encapsulation keys, hash check on decapsulation keys, length checks on ciphertexts | ML-DSA / SLH-DSA: bounds checks on all decoded signature components; reject malformed encodings before any secret operation | Stateful signatures: verifier validates parameter identifiers and index ranges Side channels: No secret-dependent branches, memory accesses, or variable-time arithmetic (division, modular reduction, floating point) | Rejection-sampling loops do not leak secret-correlated information | Verified with tooling (for example ctgrind, dudect, or formal methods), not by inspection alone Randomness and hedging: Fresh seeds from an approved DRBG for every key generation and encapsulation | ML-DSA and SLH-DSA use hedged signing unless there is a documented reason for deterministic mode | Fault-attack countermeasures where deterministic signing or hash-based signing is used Protocol integration: Hybrid combiners bind both shared secrets and both ciphertexts (RFC 10024, SP 800-227) | Key-share encoding order matches the named group definition | Downgrade and negotiation paths cannot silently drop the post-quantum component | Stateful signature state is persisted atomically, never cloned, and survives crash and restore Crypto-agility and operations: Algorithm identifiers are negotiated or versioned so a future switch (for example to HQC or FN-DSA) does not require a protocol redesign | Key and signature sizes are accounted for in storage, MTU, and DoS budgets | Documented migration plan aligned to the NIST IR 8547, CNSA 2.0, EU, or UK NCSC timeline that applies Source page: https://pqaudit.org/audit-checklist/ Compiled by: PQC Audit Index editors (https://pqaudit.org/about/) Last reviewed: 2026-09-12