Governments · agencies
National guidance
Post-quantum migration and TLS guidance published by national cyber security agencies and governments: the algorithms they name, their position on hybrid key exchange, and their deadlines. Each statement carries the document and section it comes from. Last verified 28 Oct 2026.
Timeline
Dated milestones in each jurisdiction's guidance. A bare year means by the end of that year. The shaded area is the past, up to the day the page was last verified.
Milestones
The same dates as a list, earliest first.
| Date | Jurisdiction | Milestone | Applies to |
|---|---|---|---|
| 2025 | France | Phase 2 security visas anssi-2022, roadmap; anssi-2023, Sec. 4 (p. 6) | Products: hybrid PQC with claimed quantum resistance in security visas; phase 2 "not earlier than 2025", first phase-2 visas expected around 2024 to 2025. |
| Apr 2026 | Canada | Departmental migration plans itsm-40-001, Sec. 4 | Federal departments and agencies: initial departmental PQC migration plan; annual progress reports from April 2026. |
| 22 Oct 2026 | United States | Agency migration plans due m-26-15, Sec. 3 (p. 4): "no later than 120 days from the date of this memorandum" | Each agency submits a PQC migration plan to OMB and ONCD within 120 days of M-26-15 (date computed from 2026-06-24). |
| 31 Dec 2026 | European Union | First steps, national roadmaps nis-roadmap, Sec. 4.1 timeline (p. 7) | All member states: First Steps implemented, initial national PQC transition roadmaps, planning and pilots for high- and medium-risk use cases started. |
| 2026 | Australia | Refined transition plan au-planning, Transition milestones (p. 3): "By end of 2026: Organisations should have a refined plan for their transition to PQC." | All organisations applying the ISM: a refined plan for their transition to PQC. |
| 2026 | Japan | Government roadmap drafted jp-interim, Sec. 4(1) (p. 4) | Relevant ministries draw up the roadmap for government agencies in fiscal 2026 (April 2026 to March 2027). |
| 1 Jan 2027 | United States NSS | New acquisitions use CNSA 2.0 cnsa2-faq, Timeframe (p. 17): "by January 1, 2027, CNSA 2.0 algorithms will be required in all new acquisitions for NSS" | CNSA 2.0 algorithms required in all new NSS acquisitions (CNSSP 15). |
| 31 Mar 2027 | Singapore | CII migration plans due sg-handbook, p. 25: "By 31 Mar 2027: Submission of CII owner's quantum-safe migration plan to CSA." | Critical Information Infrastructure owners submit a quantum-safe migration plan to CSA. |
| 31 Dec 2027 | United States | NIST pilot complete eo-14412, Sec. 4: "to be completed no later than December 31, 2027" | NIST pilot of PQC migration on a subset of its own systems. |
| 1 Jan 2028 | Singapore | New CII systems quantum-safe sg-handbook, p. 25 | New CII computer systems procured and implemented should support quantum-safe algorithms or be quantum-safe ready. |
| 2028 | Australia | Transition under way au-planning, Transition milestones (p. 3): "By end of 2028: Organisations should have commenced their transition to PQC" | Transition commenced, starting with critical systems and data, highly sensitive or long-lived data, and systems hard to update. |
| 2028 | United Kingdom | Discovery and plan complete ncsc-timelines, Executive summary | All organisations: define migration goals, complete discovery and assessment, build an initial migration plan. |
| 2 Jan 2030 | United States | TLS 1.3 supported m-26-15, Appendix A Sec. 4 | Federal agencies support TLS 1.3 or a successor. |
| 31 Dec 2030 | European Union | High-risk use cases migrated nis-roadmap, Sec. 4.1 (pp. 6 to 7) | High-risk use cases transitioned; quantum-vulnerable public-key mechanisms not used stand-alone after end of 2030; quantum-safe software and firmware upgrades enabled by default. |
| 31 Dec 2030 | United States | PQC key establishment eo-14412, Sec. 4: "transition all HVAs and high impact systems to use PQC for key establishment by December 31, 2030"; Sec. 6(c), covered contractors "comply by December 31, 2030, with NIST's FIPS" | High value assets and high impact systems, excluding national security systems; also covered contractors to comply with PQC FIPS (proposed FAR rule). |
| 31 Dec 2030 | United States NSS | Non-CNSA 2.0 equipment phased out cnsa2-faq, Timeframe (p. 17) | NSS equipment and services that cannot support CNSA 2.0 are phased out unless granted an exception. |
| 2030 | Australia | PQC transition complete au-planning, Transition timeline (p. 2) and Transition milestones (p. 3): "By end of 2030: Organisations should have completed their PQC transition." | Transition to PQC completed; traditional asymmetric cryptography (RSA, DH, ECDH, ECDSA) no longer used. |
| 2030 | Australia | New products support ML-KEM-1024 au-ism, ISM-1917 (p. 215): "by no later than 2030" | Development and procurement of new cryptographic equipment, applications and libraries ensures support for ML-DSA-87, ML-KEM-1024, SHA-384, SHA-512 and AES-256. |
| 2030 | Australia | Traditional asymmetric algorithms unapproved au-ism, Using Diffie-Hellman, Using Elliptic Curve Diffie-Hellman, Using the Elliptic Curve Digital Signature Algorithm, Using Rivest-Shamir-Adleman (pp. 211-214) | DH, ECDH, ECDSA and RSA are not approved beyond 2030, "taking into account projected technological advances in quantum computing". |
| 2030 | Australia | Smaller parameter sets unapproved au-ism, pp. 213-215 and 218 | ML-KEM-768, ML-DSA-65, SHA-224, SHA-256, AES-128, AES-192 and HMAC-SHA256 are not approved beyond 2030, for interoperability and maintainability reasons. |
| 2030 | Canada | Weak classical parameters out itsp-40-111, Sec. 5, 6, 7 | RSA and FFC below 3072 bits, P-224, binary curves, DSA, SHA-224 phased out by end of 2030. |
| 2030 | France | Optional standalone PQC anssi-2022, roadmap | Phase 3, "probably not earlier than 2030": standalone post-quantum cryptography becomes optional. Phase 2 "should last until at least 2030". |
| 2030 | Germany | Very high protection: PQ bsi-tr-02102-1, Sec. 2.1 (p. 28) | Applications with very high protection requirements: transition to quantum-safe key agreement by end of 2030. |
| 2030 | South Korea | PQC technology self-reliance kr-msit-2605, closing statement: "2030년까지 PQC 전주기 기술 자립을 완성함으로써" (by completing full-lifecycle PQC technology self-reliance by 2030) | MSIT goal: complete domestic technology self-reliance across the whole PQC lifecycle; stated by an MSIT director-general, not set as a requirement. |
| 2030 | South Korea | Transition R&D programme ends kr-msit-2605, R&D section: "올해부터 2030년까지 총 5년간 범국가 PQC 전환 핵심기술 개발(R&D) 사업을 본격 추진한다" (from this year to 2030, five years in total, MSIT pursues the national PQC transition core technology R&D programme) | Five-year national PQC transition core technology R&D programme run by MSIT and IITP, 2026 to 2030. |
| 2030 | South Korea | Hybrid infrastructure reference deployments kr-msit-2509, vice minister's statement: "2030년까지 국가 핵심 기반시설(인프라)에 양자보안 기술을 결합한 혼합 모형(하이브리드 모델)의 구축 모범사례를 확보" | MSIT aim: best-practice deployments of hybrid models combining quantum security technologies (PQC and QKD) in national critical infrastructure. |
| 2030 | United States | Classical public-key deprecated ir-8547, Sec. 4 (p. 13) | Quantum-vulnerable public-key algorithms deprecated after 2030 under NIST standards. |
| 31 Dec 2031 | Singapore | CII migration complete sg-handbook, p. 25: "vulnerable cryptography should no longer be used" | Quantum-safe migration completed across CII computer systems; vulnerable cryptography no longer used. |
| 31 Dec 2031 | United States | PQC digital signatures eo-14412, Sec. 4: "to use PQC for digital signatures by December 31, 2031" | High value assets and high impact systems, excluding national security systems. |
| 31 Dec 2031 | United States NSS | CNSA 2.0 mandated cnsa2-faq, Timeframe (p. 17): "By December 31, 2031, CNSA 2.0 algorithms are mandated for use" | CNSA 2.0 algorithms mandated for use across NSS, unless otherwise noted. |
| 2031 | Canada | High priority systems migrated itsm-40-001, Sec. 4 | Federal departments: end of 2031, PQC migration of high priority systems complete (quantum-vulnerable algorithms disabled, isolated or tunnelled). |
| 2031 | Germany | Classical key agreement ends bsi-tr-02102-1, Sec. 2.1 (p. 28); bsi-tr-02102-2, Sec. 3.2 | Sole use of classical key agreement, and TLS 1.2, recommended only until end of 2031. |
| 2031 | United Kingdom | Priority migration complete ncsc-timelines, Executive summary | All organisations: early, highest-priority migration activities done; plan refined for full migration. |
| 31 Dec 2035 | European Union | Medium-risk use cases migrated nis-roadmap, Sec. 4.1 timeline (p. 7) | Medium-risk use cases transitioned; low-risk use cases as far as feasible. |
| 2035 | Canada | All systems migrated itsm-40-001, Sec. 4; itsp-40-111, Sec. 5, 6 | Federal departments: end of 2035 for remaining systems; RSA, ECC and FFC without a post-quantum scheme phased out (ITSP.40.111 applies to UNCLASSIFIED, PROTECTED A and B). |
| 2035 | Germany | Classical signatures end bsi-tr-02102-1, Sec. 2.1 (p. 28) | Classical signature mechanisms recommended only until end of 2035. |
| 2035 | Japan | Government agencies migrated jp-interim, annex Sec. 4(1) (p. 6): "原則として、2035年を目処に、耐量子計算機暗号（PQC）へ移行を行うこととする" | Government agencies and their information systems under the unified standards: migrate to PQC by around 2035 in principle; earlier for particularly sensitive or long-protected information. |
| 2035 | United Kingdom | Migration complete ncsc-timelines, Executive summary | All organisations: "Complete migration to PQC of all your systems, services and products"; a small set of rarely used technologies may take longer. |
| 2035 | United States | Classical public-key disallowed ir-8547, Sec. 4 (p. 13); m-26-15, Phase 5 (p. 5) | Quantum-vulnerable public-key algorithms disallowed after 2035; full federal migration target. |
| 2035 | United States NSS | NSM-10 goal cnsa2-faq, Timeframe (p. 17) | Quantum resistance goal under NSM-10; NSA intends NSS to be quantum-resistant well ahead of it. |
Click Date or Jurisdiction to sort.
Algorithms
The parameter sets each jurisdiction names. The first line is what it recommends; the lines after it are what it also accepts, what it deprecates, and any qualification.
| Jurisdiction | Key establishment | Signatures | Symmetric and hash |
|---|---|---|---|
| Australia | ML-KEM-1024also ML-KEM-768 (until the end of 2030)deprecated: ML-KEM-512 (not approved), DH (after 2030), ECDH (after 2030), RSA key transport (after 2030)ML-KEM-768 and ML-KEM-1024 are approved, preferably ML-KEM-1024; ML-KEM-768 is not approved beyond 2030. DH, ECDH and RSA remain approved until then. FIPS 140-3 validation of ML-KEM modules is preferred, not required.au-ism, Using the Module-Lattice-Based Key Encapsulation Mechanism (pp. 213-214) ISM-1995; Using Diffie-Hellman, Using Elliptic Curve Diffie-Hellman, Using Rivest-Shamir-Adleman (pp. 211-214); ISM-1990 (p. 213) | ML-DSA-87also ML-DSA-65 (until the end of 2030)deprecated: ML-DSA-44 (not approved), ECDSA (after 2030), RSA (after 2030)ML-DSA-65 and ML-DSA-87 are approved, preferably ML-DSA-87; the hedged variant is used whenever possible, and pre-hashed variants only when the default variants perform unacceptably, with at least SHA-384 (ML-DSA-65) or SHA-512 (ML-DSA-87). LMS, XMSS and SLH-DSA are not among the approved algorithms.au-ism, Cryptographic algorithms (p. 210, list of approved asymmetric algorithms); Using the Module-Lattice-Based Digital Signature Algorithm (p. 213) ISM-1991; ISM-1992, ISM-1993, ISM-1994 | AES is the only approved symmetric algorithm and SHA-2 the only general-purpose hash; SHA-3 and SHAKE are approved only inside ML-DSA and ML-KEM. AES-256 and SHA-384 or SHA-512 are preferred. AES-128, AES-192, SHA-224, SHA-256 and HMAC-SHA256 are not approved beyond 2030. New equipment, applications and libraries support SHA-384, SHA-512 and AES-256 by 2030.au-ism, Cryptographic algorithms (p. 210); Using Secure Hashing Algorithms (p. 214); Using symmetric cryptographic algorithms (p. 215), ISM-1769; ISM-1917 (p. 215) |
| Canada | ML-KEM-512, ML-KEM-768, ML-KEM-1024deprecated: RSA, FFC DH, FFC MQV, ECC CDH, ECC MQVThe three ML-KEM parameter sets are recommended without a preference; RSA, finite-field and elliptic-curve key establishment used without a post-quantum scheme should be phased out by the end of 2035.itsp-40-111, Sec. 5.4; Sec. 5.1 to 5.3 | ML-DSA-44, ML-DSA-65, ML-DSA-87, SLH-DSA-SHA2-128s, SLH-DSA-SHAKE-128s, SLH-DSA-SHA2-128f, SLH-DSA-SHAKE-128f, SLH-DSA-SHA2-192s, SLH-DSA-SHAKE-192s, SLH-DSA-SHA2-192f, SLH-DSA-SHAKE-192f, SLH-DSA-SHA2-256s, SLH-DSA-SHAKE-256s, SLH-DSA-SHA2-256f, SLH-DSA-SHAKE-256falso LMS, HSS, XMSS, XMSS^MTdeprecated: RSA, ECDSA, EdDSA, DSAML-DSA is the general-purpose scheme; stateful LMS and XMSS can still be used where the signer need not sign rapidly and can protect key state. RSA, ECDSA and EdDSA without a post-quantum scheme are phased out by the end of 2035, DSA by the end of 2030.itsp-40-111, Sec. 6.5, 6.6, 6.7; Sec. 6.1 to 6.4 | AES with 128, 192 or 256-bit keys; SHA-256, SHA-384, SHA-512 and SHA-3 family hashes (SHA-224 and SHA3-224 phased out by the end of 2030).itsp-40-111, Sec. 3.1, Sec. 7 |
| European Union | The NIS Cooperation Group names no algorithms and will not recommend specific ones beyond referring to existing standards; quantum-vulnerable mechanisms such as RSA and discrete-logarithm schemes are to be replaced.nis-faq, 5.3 (p. 10); nis-roadmap, Sec. 4.1 (p. 6) | No algorithms named. Hybrid signatures are harder to get right than hybrid KEMs and are outside the roadmap's scope.nis-faq, 3.3 (p. 7) | Out of scope of the roadmap, which prioritises public-key migration; attacks on AES do not seem practical in the foreseeable future, even with 128-bit keys.nis-faq, 2.3 (p. 5) |
| France | ML-KEMalso FrodoKEMANSSI gives no closed list; ML-KEM at the highest NIST level possible, preferably level 5 or level 3, with ephemeral keys; FrodoKEM encouraged as a valid conservative option.anssi-2023, Sec. 2 (pp. 2 to 3) | ML-DSAalso FN-DSA, SLH-DSA, XMSS, LMSML-DSA preferably at level 5 or level 3; FN-DSA (Falcon) preferably at level 5 with attention to side channels; XMSS and LMS where signature counts are limited and state can be stored, as for software updates; SLH-DSA a relevant conservative option.anssi-2023, Sec. 2 (pp. 3 to 4): Falcon; XMSS/LMS; SPHINCS+ | At least the security level of AES-256 for block ciphers and of SHA2-384 for hash functions.anssi-2023, Sec. 1 (p. 2) |
| Germany | ML-KEM-768, ML-KEM-1024, FrodoKEM-976, FrodoKEM-1344deprecated: Classic McElieceOnly in hybrid use; ML-KEM-512 is not listed; parameters follow NIST categories 3 and 5. HQC is to be added after its standard is published. Classic McEliece, recommended since 2020 and still in TR-02102-1 Table 2.6, should no longer be used in new developments after cryptanalytic progress in 2026; the next TR-02102-1, expected early 2027, will revise it. Classical key agreement alone is recommended only until the end of 2031.bsi-tr-02102-1, Sec. 2.4, Tables 2.5 to 2.7 (pp. 37 to 38); Sec. 2.4.4 (pp. 38 to 39); Sec. 2.1 (p. 28); bsi-mceliece, p. 1 | ML-DSA-65, ML-DSA-87, SLH-DSA-SHA2-192s, SLH-DSA-SHAKE-192s, SLH-DSA-SHA2-192f, SLH-DSA-SHAKE-192f, SLH-DSA-SHA2-256s, SLH-DSA-SHAKE-256s, SLH-DSA-SHA2-256f, SLH-DSA-SHAKE-256f, LMS/HSS, XMSS/XMSS^MTdeprecated: DSAML-DSA and SLH-DSA in the hedged variant; quantum-safe signatures only in combination with a classical signature, though hash-based signatures may in principle be used alone; LMS/HSS and XMSS only where state management is guaranteed, for example software and firmware updates. Classical signatures alone recommended until the end of 2035; DSA until 2029.bsi-tr-02102-1, Table 5.3 (p. 51), Sec. 5.3.4 (p. 54); Tables 5.6 to 5.8 (pp. 55 to 56) | AES-128, AES-192 and AES-256; target security level 120 bits, with a uniform level of at least 128 bits suggested for long-lived systems.bsi-tr-02102-1, Table 3.1; Sec. 1.1; Sec. 1.6 (p. 23) |
| Japan | Algorithms follow the CRYPTREC list; CRYPTREC is evaluating FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for listing. Public-key cryptography is the main migration target.jp-interim, Sec. 2(3) (p. 3); annex Sec. 3 and note (p. 6) | No signature algorithms named; ML-DSA and SLH-DSA are under CRYPTREC evaluation.jp-interim, Sec. 2(3) (p. 3) | Symmetric ciphers and hash functions at the 128-bit level now mainly in use should be considered for a change to longer, stronger keys.jp-interim, Sec. 2(1) (p. 2); annex Sec. 3(1) (p. 6) |
| Netherlands | ML-KEM-1024also ML-KEM-768, FrodoKEM, Classic McEliecedeprecated: ECDH, RSAML-KEM, FrodoKEM and Classic McEliece are to be deployed in hybrid with ECDH. FrodoKEM and Classic McEliece are acceptable until standardised, at security level 5 or 3. ECDH and RSA are listed as deprecated but can be part of a hybrid scheme. The handbook predates the 2026 cryptanalysis of Classic McEliece, after which the German BSI advises against it in new developments; the Netherlands has not revised its position.nl-handbook, Table 4.1 (p. 57), Table 4.2 (p. 58), Sec. 4.2.1 (pp. 58-59); bsi-mceliece, p. 1, p. 3 | ML-DSA-87, SLH-DSA-(SHA2/SHAKE)-256(s/f), SLH-DSA-(SHA2/SHAKE)-192(s/f), XMSS, LMS, HSSalso ML-DSA-65, SLH-DSA-(SHA2/SHAKE)-128(s/f), FN-DSAdeprecated: ECDSA, EdDSA, RSAML-DSA and FN-DSA are to be deployed in hybrid with ECDSA or EdDSA; SLH-DSA does not need a hybrid. Stateful XMSS, LMS and HSS only where state can be managed.nl-handbook, Table 4.1 (p. 57), Table 4.2 (p. 58), Sec. 4.2.1-4.2.2 (p. 58-59) | AES-256 recommended, AES-128 acceptable. SHA-256, SHA-384, SHA-512 and SHA-3-256/384/512 recommended; SHA-224 and SHA-3-224 acceptable. Increase symmetric key lengths only after asymmetric primitives are migrated.nl-handbook, Table 4.2 (p. 58); Sec. 4.2.3 (p. 59) |
| Singapore | ML-KEMdeprecated: RSA, DH, ECC (all key sizes)No parameter sets named. For key establishment, a 256-bit pre-shared symmetric key or QKD are the other quantum-safe options; ML-KEM is the practical choice where pre-shared key distribution at scale is impractical.sg-handbook, p. 26 algorithm table deprecated, recommended; p. 28 Key Establishment | ML-DSA, SLH-DSA, LMS (firmware signing only), XMSS (firmware signing only)deprecated: RSA, DH, ECC (all key sizes)No parameter sets named. XMSS and LMS are described as hard to implement securely and not expected to be widely adopted.sg-handbook, p. 26 table; p. 29 Digital Signatures | AES-256 recommended; AES below 128-bit deprecated. Hash functions of 256 bits or more recommended; below 256 bits (e.g. SHA-224) deprecated. Organisations should migrate to AES-256.sg-handbook, p. 26 table; p. 29 |
| South Korea | NTRU+, SMAUG-TNTRU+ and SMAUG-T are the two public-key encryption and key establishment algorithms selected in the NIS national PQC competition (KpqC). No parameter sets are named. Korean Industrial Standard (KS) proposals for both have been submitted, and the algorithms may change during standardisation. Government pilot transitions also used ML-KEM; no document reached says whether ML-KEM is approved for government use. No algorithm is named as deprecated.kr-kpqc-final (B. public-key encryption / key establishment); kr-kpqc-std (KS proposals for the two KEMs, NTRU+ and SMAUG-T, have been submitted), (as the algorithms may change during standardisation); kr-msit-2512, footnote (four domestic, three foreign) | AIMer, HAETAEAIMer and HAETAE are the two digital signature algorithms selected in the KpqC competition. No parameter sets are named. They are under review for a later KS proposal. Government pilot transitions also used ML-DSA and SLH-DSA; no document reached states their status. No algorithm is named as deprecated.kr-kpqc-final (A. digital signatures); kr-kpqc-std (the two signature algorithms, AIMer and HAETAE, are under review for a later standard proposal); kr-msit-2512, footnote | Not statedkr-kpqc-final, kr-kpqc-std, kr-msit-2605, kr-msit-2512, kr-msit-2509, kr-kipo-2602 (whole documents checked) |
| United Kingdom | ML-KEM-768also ML-KEM-512, ML-KEM-1024All ML-KEM parameter sets are acceptable for OFFICIAL-tier information; ML-KEM-768 is recommended for most use cases, the highest level for long-lived keys or long-lived sensitive data, smaller sets for constrained devices.ncsc-next-steps, Choosing algorithms and parameters | ML-DSA-65also ML-DSA-44, ML-DSA-87, SLH-DSA, LMS, XMSSML-DSA is for general purpose use; SLH-DSA, LMS and XMSS suit firmware and software signing, and LMS and XMSS only where state can be managed in a trusted manner.ncsc-next-steps, Choosing algorithms and parameters (table): SLH-DSA, LMS, XMSS | Existing symmetric algorithms with at least 128-bit keys, such as AES, and hash functions such as SHA-256 can continue to be used. The recommended TLS 1.3 profiles use TLS_AES_128_GCM_SHA256.ncsc-next-steps,; ncsc-tls, Recommended post-quantum cryptography profiles for TLS 1.3 |
| United States | ML-KEM-768also ML-KEM-512, ML-KEM-1024deprecated: Finite field DH and MQV, Elliptic curve DH and MQV, RSA key establishmentML-KEM-768 is the default parameter set; others may be used when it is impractical or higher security is needed. HQC will also be approved once published. Quantum-vulnerable schemes are deprecated after 2030 and disallowed after 2035.ir-8547, Sec. 4.1.2, Table 4 and Table 5 (pp. 16-17) | also ML-DSA-44, ML-DSA-65, ML-DSA-87, SLH-DSA-SHA2-128[s/f], SLH-DSA-SHAKE-128[s/f], SLH-DSA-SHA2-192[s/f], SLH-DSA-SHAKE-192[s/f], SLH-DSA-SHA2-256[s/f], SLH-DSA-SHAKE-256[s/f], LMS, HSS, XMSS, XMSSMTdeprecated: ECDSA, EdDSA, RSATable 3 lists approved post-quantum signatures without a preferred one. ECDSA, EdDSA and RSA are deprecated after 2030 and disallowed after 2035; for high value assets and high impact systems the earlier EO 14412 deadlines apply.ir-8547, Sec. 4.1.1, Table 2 (p. 15) and Table 3 (p. 16) | Approved symmetric primitives with at least 128 bits of classical security meet at least Category 1. 112-bit symmetric standards are disallowed in 2030. SHA-1 is disallowed in FIPS-validated modules after 2030.ir-8547, Sec. 4.1.3 (p. 18) |
| United States NSS | ML-KEM-1024ML-KEM-1024 for all classification levels; no other KEM is in CNSA 2.0. Non-CNSA 2.0 equipment is phased out by 2030-12-31.cnsa2-faq, CNSA 2.0 table (p. 7) | ML-DSA-87, LMS SHA-256/192 (firmware and software signing)also LMS, all SP 800-208 parameters (firmware and software signing), XMSS, all SP 800-208 parameters (firmware and software signing)deprecated: HSS, XMSSMTML-DSA-87 for all use cases, including firmware and software signing. HSS and XMSSMT are not allowed. HashML-DSA is not allowed at present.cnsa2-faq, CNSA 2.0 table (pp. 7-8); p. 11; p. 15 | AES with 256-bit keys; SHA-384 or SHA-512 for all classification levels. SHA3-384 or SHA3-512 only for specific applications such as hardware integrity.cnsa2-faq, CNSA 2.0 table (pp. 7-8) |
Click Jurisdiction to sort. A dash means the listed documents do not state a value. A source link opens the copy, at the cited page where the copy's pages are numbered.
Hybrid and certificates
Whether a post-quantum algorithm is to be combined with a classical one, and what is said about certificates and the PKI.
| Jurisdiction | Hybrid | Certificates |
|---|---|---|
| Australia | not required Post-quantum traditional hybrid schemes are not recommended but not prohibited; organisations may consider one for interoperability and resiliency. If used, at least one component is an ASD-approved algorithm. All organisations should expect to move to purely post-quantum algorithms.au-ism, Post-quantum traditional hybrid schemes (pp. 215-216); au-planning, Post-quantum/traditional hybrid schemes (p. 6) ISM-1996 | Not stated for post-quantum certificates. TLS connections use SHA-2-based certificates; ECDSA and RSA, the approved traditional signature algorithms, are not approved beyond 2030.au-ism, Transport Layer Security, ISM-1374 (p. 222); Using the Elliptic Curve Digital Signature Algorithm (p. 212), Using Rivest-Shamir-Adleman (p. 214) |
| Canada | not stated The documents do not recommend or require hybrids; the phase-out wording covers classical algorithms used "without a post-quantum" scheme, so a classical algorithm combined with a post-quantum one is not phased out.itsp-40-111, Sec. 5.1 to 5.3, 6.1 to 6.4 (phase-out sentences); no mention of hybrid in itsp-40-111, itsm-40-001 or itsp-40-062 | Not stated. ITSP.40.062 asks for X.509 v3 certificates and defers post-quantum protocol configuration until protocol standards are final.itsp-40-062, Sec. 2 and Sec. 9 |
| European Union | recommended Standardised and tested hybrid solutions are recommended whenever feasible and suitable; the 18-agency statement strongly recommends hybrids for most use cases; no guidance on whether hybrids are short or long term.nis-roadmap, Sec. 4.1 (p. 6); joint-2024, PDF p. 3; nis-faq, 3.2 (p. 6) | PKIs are named as long-migration systems. Where a full PKI transition is not feasible by the end of 2030, a new PQC PKI may be introduced alongside the old quantum-vulnerable one before that deadline; detailed PKI transition plans are recommended by the end of 2030.nis-faq, 2.4 (p. 5); joint-2024, PDF p. 4 |
| France | required Hybridation is recommended for TLS key exchange and signature authentication, and is mandatory in evaluated end products that include post-quantum mitigation, except where the mitigation relies only on hash-based signatures; standalone PQC is foreseen only in phase 3, probably not before 2030.anssi-ft-115, Sec. 4 (p. 11); anssi-2023, Sec. 4 (p. 6) | Hybrid signature authentication in TLS 1.3 needs hybrid certificates and certificate chains, for example two separate certificates or one certificate over concatenated keys; no standard exists yet, and ANSSI has not identified a well-defined hybrid certificate design.anssi-ft-115, Sec. 3.2.2 (p. 9); anssi-2023, Sec. 3.2 (p. 6) |
| Germany | recommended Quantum-safe mechanisms should be used in hybrid form with a classical method, for key agreement (CatKDF or KeyCombine) and for signatures (concatenation, valid only if all are valid); hash-based signatures may be used alone.bsi-tr-02102-1, Sec. 2.1 (p. 28)hybrid; Sec. 2.2, Table 2.1 (p. 29); Sec. 5.3.4 (p. 54) | All recommended signature schemes, including ML-DSA, SLH-DSA and stateful hash-based schemes, may be used for issuing certificates. A long migration is expected for signatures within a PKI, and products with a lifetime beyond 2030 should be upgradable, with post-quantum signatures in their update mechanism. In TLS 1.3, the recommended certificate signature algorithms are still RSA and ECDSA; PKCS #1 v1.5 certificate signatures only until 2025.bsi-tr-02102-1, Sec. 5.3 (p. 51); Sec. 5.3 (p. 52); bsi-tr-02102-2, Sec. 3.4.3, Table 12 (p. 13) |
| Japan | optional Depending on the environment, combined use of PQC and current cryptography may be adopted instead of full migration.jp-interim, Sec. 5 (p. 5) | Not statedjp-interim (whole document checked) |
| Netherlands | recommended Hybrid in the hybrid-AND form is recommended unless a system meets all conditions for pre-shared keys. Externally facing systems may only manage hybrid-OR.nl-handbook, Sec. 4.1 (pp. 55-56) | All X.509 scenarios should consider hybrid certificates: ITU-T X.509 Sec. 9.8 (catalyst) or IETF composite certificates. A policy should state when to move from hybrid to fully post-quantum.nl-handbook, Sec. 4.3, X.509 (p. 64) |
| Singapore | optional Hybrid classical-PQC implementations are a viable option during or beyond the transition period.sg-handbook, p. 32; p. 30-31 describes hybrid key exchange, signatures and certificates | Plan for PQC-enabled certificates, dual-key usage and key management across trust chains. In the worked scenario, PKI is updated to support ML-KEM and ML-DSA with updated X.509 certificate profiles.sg-handbook, p. 30 (key lifecycle management); p. 34 (worked scenario) |
| South Korea | not stated No stance on PQ/T hybrid key establishment or signatures. MSIT uses "hybrid" for combining PQC with quantum key distribution (QKD): an R&D project builds a PQC-QKD hybrid system, and MSIT aims for reference deployments of such hybrid models in national critical infrastructure by 2030.kr-msit-2605, R&D section (implements a hybrid security system combining PQC and QKD in parallel mode); kr-msit-2509, vice minister's statement (secure best-practice deployments of hybrid models combining quantum security technologies in national core infrastructure by 2030) | Not statedkr-kpqc-final, kr-kpqc-std, kr-msit-2605, kr-msit-2512, kr-msit-2509, kr-kipo-2602 (whole documents checked) |
| United Kingdom | recommended Hybrid schemes are recommended as an interim measure for TLS key exchange, and pure MLKEM768 and MLKEM1024 are acceptable; a single move to a fully post-quantum PKI is preferred over an intermediate hybrid PKI.ncsc-tls, Post-quantum key exchange in TLS; ncsc-next-steps, Recommendations on PQ/T hybrid schemes | Keep issuing ECDSA P-256 or RSA-2048 certificates until post-quantum authentication for TLS is standardised, and avoid validity periods that extend past the planned end of migration. A single migration to a fully post-quantum PKI is preferred to an intermediate hybrid PKI. Enterprise PKIs need a new PQC root of trust, run in parallel or cross-signing the old one; authentication is not quantum-secure until traditional certificates have expired or been revoked. Private PKIs may adopt post-quantum authentication sooner than the Web PKI.ncsc-tls, Using Certificates with TLS, Planning for PQC; ncsc-next-steps, Additional considerations for PQ/T hybrid schemes; ncsc-timelines, PQC migration for enterprise PKI |
| United States | optional Agencies may implement hybrid architectures based on their own risk assessments. NIST accepts hybrid key establishment in FIPS 140 validation when one input comes from an approved scheme, and expects hybrids to be temporary.m-26-15, Appendix A Sec. 3 (Appendix p. 3); ir-8547, Sec. 3.2 (pp. 10-11), after Table 5 (pp. 17-18) | PKI components must be updated to issue certificates that use PQC algorithms and to sign certificates and revocation information with PQC algorithms, possibly including hybrid signature schemes.ir-8547, Sec. 2.2.4 (p. 6) |
| United States NSS | not required NSA will not require hybrid products for security purposes. Where NSA gives public guidance for a hybrid in a protocol (for example IKEv2), only that hybrid is CNSA 2.0 compliant. The TLS profile uses ML-KEM-1024 alone.cnsa2-faq, Hybrids and composites (pp. 28-29) | TLS certificates must be signed with ML-DSA-87 and follow the CNSA 2.0 certificate and CRL profile; X.509 server authentication is required.cnsa2-tls, Sec. 8 and 8.4 |
TLS
Protocol versions and post-quantum key exchange in TLS.
| Jurisdiction | Versions | Post-quantum key exchange |
|---|---|---|
| Australia | Only the latest version, TLS 1.3; SSL and TLS 1.2 and earlier are no longer suitable as an approved protocol. | Ephemeral DH or ECDH (ISM-1372, revised September 2026); no post-quantum or hybrid TLS key exchange is named. ECDH preferably on NIST P-384. AES-GCM for encryption.au-ism, Transport Layer Security (p. 222) ISM-1139 ISM-1372; ISM-1369; ISM-0474 (p. 212) |
| Canada | TLS 1.3 recommended; TLS 1.2 sufficient where needed for compatibility, audit or monitoring; phase out older TLS and all SSL. | No post-quantum TLS configuration yet; recommendations to follow once protocol standards are finalized. TLS 1.3 suites: TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, TLS_AES_128_CCM_SHA256 recommended.itsp-40-062, Sec. 3 (), List 1, Sec. 9 |
| European Union | not stated | not statednis-roadmap and nis-faq contain no protocol-level guidance (nis-roadmap, Sec. 4.1) |
| France | TLS 1.3 (the technical sheet covers TLS 1.3 only). | Hybrid key exchange combining a classical exchange such as ECDH with a post-quantum KEM such as ML-KEM; pre-shared keys are possible but temporary, and hybridation must be implemented eventually.anssi-ft-115, Sec. 3.2.1 (p. 8) and Sec. 4 (p. 11) |
| Germany | TLS 1.3 preferred (use up to 2032+); TLS 1.2 only until the end of 2031; TLS 1.0, 1.1 and SSL not recommended. | TLS 1.3 groups are classical (secp256r1/384r1/521r1, Brainpool, ffdhe3072/4096), alone only until the end of 2031; BSI intends to recommend SecP256r1MLKEM768 and SecP384r1MLKEM1024 once the RFC is adopted. Quantum-safe mechanisms in TLS will be recommended in hybrid use only.bsi-tr-02102-2, Sec. 3.1.3 (p. 6), Sec. 3.2 Table 2 (pp. 6 to 7), Sec. 3.4.2 Table 10 (p. 12) |
| Japan | not stated | not statedjp-interim (whole document checked) |
| Netherlands | TLS 1.3 where the hardware supports it | Hybrid key exchange following the IETF hybrid design draft, or pre-shared keys of at least 256 bits; include AES-256-GCM or ChaCha20-Poly1305 in cipher suitesnl-handbook, Sec. 4.3, TLS (pp. 60-61) |
| Singapore | Only TLS 1.3 can support post-quantum key exchange (stated in a worked scenario, not as a version recommendation) | not stated as a recommendation; notes IETF hybrid design work and deployed X25519 + MLKEM768 under TLS 1.3sg-handbook, p. 17; p. 31 |
| South Korea | Not stated | Not statedkr-kpqc-final, kr-kpqc-std, kr-msit-2605, kr-msit-2512, kr-msit-2509, kr-kipo-2602 (whole documents checked) |
| United Kingdom | TLS 1.3 for quantum protection; plan migration from TLS 1.2; disable TLS 1.0 and 1.1; all SSL versions must be disabled. | Recommended profiles: X25519MLKEM768 or SecP256r1MLKEM768 (hybrid), or MLKEM768 (pure post-quantum); all post-quantum key exchange algorithms specified by the IETF for TLS 1.3, including SecP384r1MLKEM1024 and MLKEM1024, are acceptable. Clients offer key shares for X25519MLKEM768 and secp256r1. Authentication stays ecdsa_secp256r1_sha256 or RSA-PSS.ncsc-tls, Key recommendations; Post-quantum key exchange in TLS; Recommended post-quantum cryptography profiles for TLS 1.3; Client configuration for TLS 1.3 |
| United States | TLS 1.3 or a successor by 2030-01-02 (M-26-15). SP 800-52 Rev. 2: TLS 1.2 shall be configured, TLS 1.3 support required from 2024-01-01; SSL 2.0 and 3.0 not used; TLS 1.0 not used on government-only servers. | Hybrid key exchange combining ML-KEM with classical algorithms described as the near-term path; guidance to come in the next revision of SP 800-52m-26-15, Appendix A Sec. 4 (Appendix p. 3); ir-8547, Sec. 4.2 (p. 20); sp-800-52r2, Sec. 3.1 |
| United States NSS | TLS 1.3 only in CNSA-compliant mode; TLS 1.2 during transition follows RFC 9151 | ML-KEM-1024 only, with TLS_AES_256_GCM_SHA384 and ML-DSA-87 signaturescnsa2-tls, Sec. 1, 6, 7.1, 7.2.1, 8.1 |
Australia
Australian Signals Directorate (ASD), Australian Cyber Security Centre
Documents
- Information security manual (ISM), Guidelines for cryptography ASD · September 2026 · Sep 2026 copy 28 Oct 2026, from the publisher
- Planning for post-quantum cryptography ASD · September 2025 · Sep 2025 copy 28 Oct 2026, from the publisher
What they say
- In the ISM, ASD recommends ceasing the use of traditional asymmetric cryptography by the end of 2030. au-planning, Transition timeline, p. 2
- Taking into account projected technological advances in quantum computing, RSA will not be approved beyond 2030. au-ism, Using Rivest-Shamir-Adleman, p. 214
- The development and procurement of new cryptographic equipment, applications and libraries ensures support for the use of ML-DSA-87, ML-KEM-1024, SHA-384, SHA-512 and AES-256 by no later than 2030. au-ism, ISM-1917, p. 215
- A post-quantum cryptography transition plan is developed, implemented and maintained. au-ism, ISM-2073, p. 215
- The use of post-quantum traditional hybrid schemes is not recommended; however, it is not prohibited. au-ism, Post-quantum traditional hybrid schemes, p. 216
- Only the latest version of TLS is used for TLS connections. au-ism, ISM-1139, p. 222
Canada
Canadian Centre for Cyber Security (Cyber Centre)
Documents
- Roadmap for the migration to post-quantum cryptography for the Government of Canada (ITSM.40.001) Cyber Centre · first release · 23 Jun 2025 copy 28 Oct 2026, printed from the publisher's page
- Cryptographic algorithms for UNCLASSIFIED, PROTECTED A, and PROTECTED B information (ITSP.40.111) Cyber Centre · 5 · 29 May 2026 copy 28 Oct 2026, printed from the publisher's page
- Guidance on securely configuring network protocols (ITSP.40.062) Cyber Centre · 3 · Jan 2025 copy 28 Oct 2026, printed from the publisher's page
What they say
- End of 2031: Completion of PQC migration of high priority systems itsm-40-001, Sec. 4
- These milestones for the completion of migrations implies that quantum-vulnerable algorithms are disabled, isolated or tunnelled. itsm-40-001, Sec. 4
- The use of RSA without a post-quantum key establishment scheme should be phased out by the end of 2035. itsp-40-111, Sec. 5.1
- We expect to include recommendations for the configuration of post-quantum cryptography in an update to this publication once the protocol standards are finalized. itsp-40-062, Sec. 9
European Union
European Commission; NIS Cooperation Group work stream on PQC; agencies of 18 member states
Documents
- Commission Recommendation on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography, C(2024) 2393 European Commission · final · 11 Apr 2024 copy 28 Oct 2026, from the publisher
- A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, Part 1 NIS Cooperation Group · 1.1 · 11 Jun 2025 copy 28 Oct 2026, from the publisher
- EU Roadmap on PQC: Frequently Asked Questions NIS Cooperation Group · 15 Apr 2026 copy 28 Oct 2026, from the publisher
- Securing Tomorrow, Today: Transitioning to Post-Quantum Cryptography Joint statement, agencies of 18 EU member states · 27 Nov 2024 copy 28 Oct 2026, from the publisher
What they say
- it is recommended to use standardised and tested hybrid solutions, whenever feasible and suitable nis-roadmap, Sec. 4.1, p. 6
- For high-risk use cases, quantum-vulnerable public-key mechanisms shall not be used stand-alone after the end of 2030, analogously after the end of 2035 for medium-risk use cases. nis-roadmap, Sec. 4.1, p. 6
- we currently strongly recommend to deploy PQC in hybrid solutions for most use-cases joint-2024, PDF p. 3
- Currently, there is no clear guidance on whether hybrid cryptographic schemes are considered a long-term or short-term strategy. nis-faq, 3.2, p. 6
France
National Cybersecurity Agency of France (ANSSI)
Documents
- Transition post-quantique de TLS 1.3 (ANSSI-FT-115) ANSSI · 1.0 · 2 Feb 2026 copy 28 Oct 2026, from the publisher
- ANSSI views on the Post-Quantum Cryptography transition (2023 follow up) ANSSI · 21 Dec 2023 copy 28 Oct 2026, from the publisher
- ANSSI views on the post-quantum cryptography transition ANSSI · 4 Jan 2022 copy 28 Oct 2026, printed from the publisher's page
What they say
- L'ANSSI recommande d'utiliser l'hybridation pour les échanges de clés et l'authentification par signature. anssi-ft-115, Sec. 4, p. 11
- any product that includes post-quantum mitigation shall implement hybridation except if the quantum mitigation only relies on hash-based signatures like XMSS, LMS or SPHINCS+ anssi-2023, Sec. 4, p. 6
- preferably level-5 (i.e. equivalent to AES-256) or level-3 (i.e. equivalent to AES-192) anssi-2023, Sec. 2, p. 3
- Phase 3 (probably not earlier than 2030): optional standalone post-quantum cryptography. anssi-2022, roadmap
Germany
Federal Office for Information Security (BSI)
Documents
- TR-02102-1, Cryptographic Mechanisms: Recommendations and Key Lengths BSI · 2026-01 · 23 Jan 2026 copy 28 Oct 2026, from the publisher
- TR-02102-2, Use of Transport Layer Security (TLS) BSI · 2026-01 · 27 Jan 2026 copy 28 Oct 2026, from the publisher
- Notes on recent developments concerning Classic McEliece BSI · 29 Sep 2026 copy 28 Oct 2026, from the publisher
What they say
- Classic McEliece should currently no longer be used in new developments or when planning new cryptographic applications. For key agreement, it is advised to use FrodoKEM, ML-KEM or HQC (once the corresponding standard has been published) in accordance with the recommendations of TR-02102-1. bsi-mceliece, p. 1
- So far, the results do not enable a practical attack on Classic McEliece with the parameter sets recommended in TR-02102-1. bsi-mceliece, p. 3
- The sole use of classic key agreement mechanisms is only recommended until the end of 2031 bsi-tr-02102-1, Sec. 2.1, p. 28
- the use of classic signature mechanisms is therefore only recommended until the end of 2035. bsi-tr-02102-1, Sec. 2.1, p. 28
- This Technical Guideline recommends the use of a quantum-safe signature scheme only in combination with a classic signature scheme. bsi-tr-02102-1, Sec. 5.3.4, p. 54
- TLS 1.2 is only recommended until the end of 2031, since, based on current knowledge, no quantum-safe key agreement mechanisms will be standardized for TLS 1.2. bsi-tr-02102-2, Sec. 3.2
- as soon as the corresponding RFC has been adopted. bsi-tr-02102-2, Sec. 3.4.2, p. 12 (SecP256r1MLKEM768, SecP384r1MLKEM1024)
Japan
Cabinet Secretariat; liaison council of ministries on PQC use by government agencies
Documents
- 政府機関等における耐量子計算機暗号（PQC）への移行について（中間とりまとめ） (Migration of government agencies to post-quantum cryptography, interim report) Liaison council of ministries on PQC use by government agencies · interim report · Nov 2025 copy 28 Oct 2026, from the publisher
What they say
- 原則として、2035年を目処に、耐量子計算機暗号（PQC）へ移行を行うこととする。 (In principle, migrate to post-quantum cryptography (PQC) by around 2035.) jp-interim, annex Sec. 4(1), p. 6
- 2026年度に工程表（ロードマップ）を策定し (draw up a roadmap in fiscal 2026) jp-interim, Sec. 4(1), p. 4
- 耐量子計算機暗号（PQC）と現在主流の暗号技術との併用を採用することや (adopting the combined use of PQC and the cryptography in use today) jp-interim, Sec. 5, p. 5
Netherlands
AIVD (General Intelligence and Security Service) with CWI and TNO
Documents
- The PQC Migration Handbook: Guidelines for migrating to post-quantum cryptography AIVD, CWI, TNO · Revised and extended second edition · Dec 2024 copy 28 Oct 2026, from the publisher
What they say
- We recommend initialising the primitives with the strongest parameter set, security level 5, when possible, and consider security level 3 an acceptable alternative nl-handbook, Sec. 4.2.1, p. 58
- It is therefore recommended to use the hybrid approach , unless the system satisfies all of the following requirements nl-handbook, Sec. 4.1, p. 56
Singapore
Cyber Security Agency of Singapore (CSA), with GovTech and IMDA
Documents
- Quantum-Safe Migration Handbook CSA, GovTech, IMDA · 1 · 16 Jul 2026 copy 28 Oct 2026, from the publisher
What they say
- This document is intended for informational purposes only and is not mandatory, prescriptive or exhaustive. sg-handbook, Disclaimer, p. 3
- Hybrid classical-PQC implementations are a viable option during or beyond the transition period. sg-handbook, p. 32
- Singapore is aligning with this momentum with requirements for Critical Information Infrastructure (CII) owners as part of their quantum-safe migration planning sg-handbook, p. 25
South Korea
National Intelligence Service (NIS) and Ministry of Science and ICT (MSIT)
Documents
- 양자내성암호 국가공모전 2라운드(최종) 결과 발표 (national PQC competition, final round results) KpqC research group (양자내성암호연구단), for the NIS competition · Notice no. 9 · 16 Jan 2025 copy 28 Oct 2026, printed from the publisher's page
- KpqC 알고리즘 표준화 관련 안내 (KpqC algorithm standardisation notice) KpqC research group (양자내성암호연구단) · Notice no. 12 · 22 Apr 2026 copy 28 Oct 2026, printed from the publisher's page
- 양자 보안, 더 이상 선택이 아닌 필수, 양자 내성 암호 실증 확대 및 핵심기술 개발 본격 착수 (press release: PQC pilots expanded, core technology R&D launched) MSIT · Press release, embargo 2026-05-06 12:00 · 6 May 2026 copy 28 Oct 2026, from the publisher
- 국가 주요 산업에 양자내성암호를 적용하여 미래 보안 체계로의 전환 발판을 마련하다 (press release: 2025 PQC pilot transition results) MSIT and KISA · Press release, embargo 2025-12-03 13:30 · 3 Dec 2025 copy 28 Oct 2026, from the publisher
- 류제명 과기정통부 제2차관, 양자보안 혁신을 위한 현장 간담회 개최 (press release: vice minister's quantum security meeting) MSIT · Press release, embargo 2025-09-03 15:30 · 3 Sep 2025 copy 28 Oct 2026, from the publisher
- 지식재산처, 정부 최초로 온라인시스템에 한국형 양자내성암호 실증적용 추진 (press release: first government online system to apply KpqC) Korean Intellectual Property Office (지식재산처) · Press release, 2026-02-03 11:30 · 3 Feb 2026 copy 28 Oct 2026, from the publisher
What they say
- 「양자내성암호 국가공모전」의 2라운드(최종) 알고리즘 4종을 아래와 같이 발표합니다. (국가정보원 홈페이지 공지사항 참조) (The four final-round algorithms of the national PQC competition are announced as below. See the notices on the NIS website.) kr-kpqc-final
- KEM 2종(NTRU+, SMAUG-T)의 KS 제정 제안이 제출되었으며, Signature 알고리즘 2종(AIMer, HAETAE)은 추후 표준 제정 제안을 위해 검토가 이루어지고 있습니다. (KS proposals for the two KEMs, NTRU+ and SMAUG-T, have been submitted; the two signature algorithms, AIMer and HAETAE, are under review for a later standard proposal.) kr-kpqc-std
- ｢범국가 양자내성암호 전환 마스터플랜(’23.7)｣, ｢범국가 양자내성 암호체계 전환 종합 추진계획(’25.9)｣ ... 등에 따라 국가 암호체계의 패러다임 전환을 지원해 오고 있다. (Under the national PQC transition master plan (July 2023), the comprehensive national plan for transitioning the cryptographic system to PQC (September 2025) and other plans, MSIT has been supporting the paradigm shift of the national cryptographic system.) kr-msit-2605, background paragraph
- 국정원은 ’21년부터 국가보안기술연구소, 양자내성암호연구단과 협업하여 ‘양자내성암호 국가공모전’을 통해 한국형 양자내성암호(KpqC) 알고리즘 선정 (Since 2021 the NIS, working with the National Security Research Institute and the KpqC research group, has selected Korean PQC (KpqC) algorithms through the national PQC competition.) kr-kipo-2602, footnote on PQC
- 2030년까지 PQC 전주기 기술 자립을 완성함으로써 대한민국을 세계 최고 수준의 ‘양자 보안 강국’으로 도약시키겠다 (By completing full-lifecycle PQC technology self-reliance by 2030, we will make Korea a world-leading quantum security power.) kr-msit-2605, statement of the MSIT director-general for information protection and network policy
United Kingdom
National Cyber Security Centre (NCSC)
Documents
- Using TLS to protect data NCSC · 1.2 · 15 Oct 2026 copy 28 Oct 2026, printed from the publisher's page
- Timelines for migration to post-quantum cryptography NCSC · 1.0 · 20 Mar 2025 copy 28 Oct 2026, printed from the publisher's page
- Next steps in preparing for post-quantum cryptography NCSC · 2.0 · 14 Aug 2024 copy 28 Oct 2026, printed from the publisher's page
What they say
- Only TLS 1.3 provides protection against quantum attacks when configured correctly. ncsc-tls, Key recommendations
- The NCSC recommends using hybrid schemes as an interim measure when migrating to PQC. ncsc-tls, Post-quantum key exchange in TLS
- The NCSC considers these algorithms acceptable for use in TLS ncsc-tls, Post-quantum key exchange in TLS (MLKEM768 and MLKEM1024)
- The NCSC recommends ML-KEM-768 and ML-DSA-65 as providing appropriate levels of security and efficiency for most use cases. ncsc-next-steps, Choosing algorithms and parameters
- a single migration to a fully post-quantum PKI is preferred to adopting an intermediate PQ/T hybrid PKI. ncsc-next-steps, Additional considerations for PQ/T hybrid schemes
- Until those standards are available, you should continue using ECDSA and RSA. ncsc-tls, Using Certificates with TLS, Planning for PQC
United States
Executive Office of the President (OMB) and NIST, for federal civilian systems
Documents
- Executive Order 14412: Securing the Nation Against Advanced Cryptographic Attacks The White House · 22 Jun 2026 copy 28 Oct 2026, from the publisher
- M-26-15: Execution of the Migration to Post-Quantum Cryptography Office of Management and Budget · 24 Jun 2026 copy 28 Oct 2026, from the publisher
- NIST IR 8547: Transition to Post-Quantum Cryptography Standards NIST · Final · Oct 2026 copy 28 Oct 2026, from the publisher
- SP 800-52 Rev. 2: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations NIST · Rev. 2 · Aug 2019 copy 28 Oct 2026, from the publisher
What they say
- NIST will deprecate quantum-vulnerable public-key cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035. ir-8547, Sec. 4, p. 13
- NIST recommends using ML-KEM-768 as the default parameter set, as it provides a large security margin at a reasonable performance cost. ir-8547, Sec. 4.1.2, p. 17
- Agencies may choose to implement hybrid architectures based on their own risk assessments and technical requirements. m-26-15, Appendix A Sec. 3
United States NSS
National Security Agency (NSA), for national security systems
Documents
- Commercial National Security Algorithm Suite 2.0 and Quantum Computing Frequently Asked Questions NSA · 2.2 · Oct 2026 copy 28 Oct 2026, from the publisher
- Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for TLS 1.3 (draft-becker-cnsa2-tls-profile-05) NSA (A. Becker, M. Jenkins), Internet-Draft · -05 · 19 Jul 2026 copy 28 Oct 2026, from the publisher
What they say
- NSA has confidence in CNSA 2.0 algorithms and will not require NSS developers to use hybrid certified products for security purposes. cnsa2-faq, p. 28
- All appropriate system components should be configured to prefer CNSA 2.0 algorithms. As products mature, those components should be configured to accept only CNSA 2.0 algorithms. cnsa2-faq, p. 17
- CNSA TLS clients and servers MUST negotiate TLS version 1.3 cnsa2-tls, Sec. 6