How we maintain this page
- Primary sources only. Every row links to the publisher: NIST, the IETF or RFC Editor, the European Commission, ENISA, ETSI or a national agency. We do not cite vendor blogs or news coverage.
- Draft is not final. A NIST draft, an Internet-Draft or a Commission proposal can still change. We label them as such and do not present them as requirements.
- Statuses: Final = published standard or specification; Approved, RFC pending = approved by the IESG, waiting for an RFC number; Draft = published for comment; Selected = algorithm chosen, no draft yet; In development = no public draft; Guidance = official recommendation, position or report, not a standard; Proposal = legislative proposal, not law.
- The “what it means” column is our reading for a regulated EU organisation, not legal advice. When a source changes, we update the row and the verification date.
Tables scroll sideways on small screens.
NIST (United States): algorithm standards and transition guidance8 entries
| Publication | What it covers | Status | Date | What it means for an EU enterprise | Primary source |
|---|---|---|---|---|---|
| FIPS 203: ML-KEMNIST | Module-lattice key-encapsulation mechanism (from CRYSTALS-Kyber) for key establishment. | Final | The reference post-quantum KEM. EU agencies expect it in hybrid mode with a classical algorithm during the transition.Our ML-KEM guide → | csrc.nist.gov | |
| FIPS 204: ML-DSANIST | Module-lattice digital signature (from CRYSTALS-Dilithium) for general-purpose signing. | Final | The default post-quantum signature for certificates, code signing and documents. Plan PKI changes around it.Our ML-DSA guide → | csrc.nist.gov | |
| FIPS 205: SLH-DSANIST | Stateless hash-based digital signature (from SPHINCS+). | Final | A conservative signature with large signatures; suited to long-lived roots of trust and firmware rather than high-volume TLS.Our SLH-DSA guide → | csrc.nist.gov | |
| FIPS 206: FN-DSA (Falcon)NIST | Lattice-based signature with smaller signatures than ML-DSA, derived from Falcon. | In developmentInitial public draft not yet published. NIST posted a revised plan (fixed-point arithmetic, single signing procedure) on 28 Sep 2026. | Not usable for compliance yet. Do not design around FN-DSA; use ML-DSA and keep algorithm choice configurable. | csrc.nist.gov NIST pqc-forum |
|
| HQC (future FIPS)NIST | Code-based KEM chosen as a backup to ML-KEM, based on different mathematics. | SelectedSelected 11 Mar 2025. No draft standard published for comment yet; NIST expects a final standard in 2027. | Nothing to deploy. It is a reason to keep systems crypto-agile so a second KEM can be added later.Our crypto-agility guide → | nist.gov | |
| SP 800-227: Recommendations for KEMsNIST | How to implement and use key-encapsulation mechanisms securely, including guidance on hybrid key establishment. | Final | Useful engineering reference when reviewing a vendor’s ML-KEM or hybrid implementation. | csrc.nist.gov | |
| IR 8547: Transition to PQC StandardsNIST | Proposed US timeline: quantum-vulnerable algorithms at 112-bit security deprecated after 2030; all quantum-vulnerable public-key algorithms disallowed after 2035. | DraftInitial public draft only; no final version published. | The 2030/2035 dates match the EU roadmap, but they are proposals. Cite them as a draft, not a NIST requirement.Our FIPS 203/204/205 migration guide → | csrc.nist.gov | |
| Additional signature schemes (on-ramp)NIST | Second NIST competition for signatures not based on structured lattices. | In developmentRound 3 candidates announced 14 May 2026. | No action now. Years from a standard. | csrc.nist.gov |
IETF: protocols and certificate formats (TLS, X.509, CMS, IKEv2)10 entries
| Publication | What it covers | Status | Date | What it means for an EU enterprise | Primary source |
|---|---|---|---|---|---|
| RFC 10024: Hybrid ECDHE-MLKEM key agreement for TLS 1.3IETF (TLS WG) | Defines the hybrid groups X25519MLKEM768 (recommended), SecP256r1MLKEM768 and SecP384r1MLKEM1024. Proposed Standard. | Final | The hybrid TLS key exchange to ask of browsers, load balancers, CDNs and libraries. Fits ANSSI and BSI expectations on hybridisation.Our ML-KEM guide → | rfc-editor.org | |
| RFC 9954: Hybrid key exchange in TLS 1.3IETF (TLS WG) | The general design for combining two key exchanges in TLS 1.3. Informational. | Final | Background for RFC 10024; read it to understand how hybrid TLS works, not as a compliance target. | rfc-editor.org | |
| ML-KEM-only key agreement for TLS 1.3 (draft-ietf-tls-mlkem)IETF (TLS WG) | Pure post-quantum ML-KEM groups for TLS 1.3, without a classical component. Intended as Informational. | Approved, RFC pendingApproved by the IESG; in the RFC Editor queue. No RFC number yet. | ANSSI and BSI currently recommend hybrid, not standalone ML-KEM. In the EU, prefer the hybrid groups of RFC 10024. | IETF Datatracker | |
| RFC 9881: ML-DSA in X.509IETF (LAMPS WG) | Algorithm identifiers for ML-DSA keys and signatures in X.509 certificates and CRLs. Proposed Standard. | Final | Post-quantum certificates now have a stable format. Ask your PKI and HSM vendors for support dates.Our ML-DSA guide → | rfc-editor.org | |
| RFC 9935: ML-KEM in X.509IETF (LAMPS WG) | Algorithm identifiers for ML-KEM public keys in X.509 certificates. Proposed Standard. | Final | Needed where certificates carry encryption keys (for example S/MIME). Less relevant for TLS server certificates. | rfc-editor.org | |
| RFC 9909: SLH-DSA in X.509IETF (LAMPS WG) | Algorithm identifiers for SLH-DSA in X.509 certificates and CRLs. Proposed Standard. | Final | Relevant for long-lived root CAs that choose hash-based signatures.Our SLH-DSA guide → | rfc-editor.org | |
| Composite ML-DSA for X.509 (draft-ietf-lamps-pq-composite-sigs)IETF (LAMPS WG) | One key and one signature combining ML-DSA with a classical algorithm (RSA, ECDSA or EdDSA). Intended as Proposed Standard. | Approved, RFC pendingApproved by the IESG; in the RFC Editor queue. No RFC number yet. | The main route to hybrid certificates, which matters where ANSSI or BSI expect hybrid signatures. Track the RFC before procurement.Our ML-DSA guide → | IETF Datatracker | |
| Composite ML-KEM for X.509 (draft-ietf-lamps-pq-composite-kem)IETF (LAMPS WG) | Hybrid KEM keys combining ML-KEM with a classical algorithm in one certificate. Intended as Proposed Standard. | Approved, RFC pendingApproved by the IESG; in the RFC Editor queue. No RFC number yet. | Relevant to hybrid encrypted email and messaging. Track it; do not build on the draft text. | IETF Datatracker | |
| CMS: RFC 9629, RFC 9814, RFC 9882, RFC 9936IETF (LAMPS WG) | KEMs in CMS (9629, Aug 2024); SLH-DSA in CMS (9814, Jul 2025); ML-DSA in CMS (9882, Oct 2025); ML-KEM in CMS (9936, Mar 2026). All Proposed Standard. | Final | Covers S/MIME, signed documents and firmware packages. Check that signing and archiving tools support them. | RFC 9629 RFC 9814 RFC 9882 RFC 9936 |
|
| ML-KEM in IKEv2 (draft-ietf-ipsecme-ikev2-mlkem)IETF (IPsecME WG) | Post-quantum key exchange with ML-KEM for IPsec VPNs (IKEv2). Intended as Proposed Standard. | Approved, RFC pendingApproved by the IESG; in the RFC Editor queue. No RFC number yet. | Site-to-site VPNs are a typical high-risk use case. Ask VPN vendors for their roadmap; ANSSI has a dedicated IPsec sheet. | IETF Datatracker |
European Union, ENISA and ETSI9 entries
| Publication | What it covers | Status | Date | What it means for an EU enterprise | Primary source |
|---|---|---|---|---|---|
| Recommendation (EU) 2024/1101 on a coordinated PQC roadmapEuropean Commission | Asks Member States to coordinate the transition to PQC and produce a common roadmap. | GuidanceCommission Recommendation (not binding). | The policy basis for the EU timeline below.Our EU roadmap guide → | digital-strategy.ec.europa.eu | |
| Coordinated Implementation Roadmap for the Transition to PQCNIS Cooperation Group, with the European Commission | Milestones: by 31 Dec 2026, first steps, national roadmaps and pilots; by 31 Dec 2030, high-risk use cases migrated; by 31 Dec 2035, medium-risk done and low-risk as far as feasible. | GuidanceVersion 1.1; not binding. | The EU reference timeline. Expect national authorities and supervisors to align with 2026, 2030 and 2035.Our EU roadmap guide → | digital-strategy.ec.europa.eu | |
| EU PQC roadmap: survey feedback and FAQNIS Cooperation Group | Results of the 2025 stakeholder survey (97 submissions) and a FAQ on risk estimation, milestones, prioritisation and hybrid schemes. | Guidance | Clarifies the roadmap; does not change its dates. | digital-strategy.ec.europa.eu | |
| Proposal to amend NIS2: COM(2026) 13European Commission | Would add Article 7(2)(k): national cybersecurity strategies must include policies for the transition to PQC, in line with Union timelines. | ProposalCommission proposal in the legislative procedure; not adopted at our last check. | Targets Member States, not companies directly, but would make national PQC policies a NIS2 requirement.Our NIS2 Article 21 guide → | digital-strategy.ec.europa.eu | |
| ECCG Agreed Cryptographic Mechanisms v2 (EUCC)ECCG sub-group on cryptography, published by ENISA | Agreed algorithms for EU cybersecurity certification, including ML-KEM, FrodoKEM, ML-DSA and SLH-DSA. Lattice-based schemes should not be used standalone. | FinalApplicable under EUCC since 6 May 2025. | The EU-level algorithm list for certified products (smartcards, HSMs). Hybrid is expected for lattice-based KEMs and signatures. | certification.enisa.europa.eu | |
| ECCG Agreed Cryptographic Mechanisms v3ECCG sub-group on cryptography, published by ENISA | Revised version of the agreed mechanisms, published with a change log for public review. | DraftDraft for public review (review ran to end of July 2026). | Version 2 still applies. Read the change log before a certification project. | certification.enisa.europa.eu | |
| Hybridization of traditional cryptographic mechanisms with PQC: standardisation statusENISA | Maps IETF hybrid key agreement and signature work against ACM v2. ENISA states it is not a recommendation. | GuidanceReport (not a recommendation). | A good map of which hybrid constructions are standardised, for architects choosing between them. | certification.enisa.europa.eu | |
| ENISA post-quantum studiesENISA | “Current state and quantum mitigation” (May 2021) and “Integration study” (Oct 2022). | GuidanceReports. | Background reading; they predate the NIST standards. | enisa.europa.eu (2021) enisa.europa.eu (2022) |
|
| ETSI TS 103 744 V1.2.2: Quantum-safe hybrid key establishmentETSI TC CYBER (QSC) | Methods (CatKDF, CasKDF) for deriving keys from a classical ECDH secret and a post-quantum KEM secret. | FinalTechnical Specification. | A European reference for hybrid key combiners, useful for protocols outside TLS and IKEv2. | etsi.org |
National agencies: ANSSI, BSI, NCSC, NSA (and joint statements)8 entries
| Publication | What it covers | Status | Date | What it means for an EU enterprise | Primary source |
|---|---|---|---|---|---|
| ANSSI position on the PQC transitionANSSI (France) | 2022 position paper and 2023 follow-up: hybridisation required during the transition; PQC obligations for product qualification from 2027; buying products without PQC after 2030 “not reasonable”. | Guidance | For French OIV, OSE and NIS2 entities, treat hybrid PQC as a purchasing criterion now, especially for VPNs, HSMs and PKI.Our ANSSI guide (in French) → | cyber.gouv.fr | |
| ANSSI technical sheets: PQ transition of TLS 1.3, SSHv2 and IPsecANSSI (France) | ANSSI-FT-115 (TLS 1.3), FT-116 (SSHv2) and FT-117 (IPsec): how to add post-quantum security to each protocol, with hybridisation as the preferred method. | GuidanceVersion 1.0. In French. | Practical protocol-level guidance for network and security teams.Our ANSSI guide (in French) → | TLS 1.3 SSHv2 IPsec |
|
| ANSSI views on crypto-agilityANSSI (France) | ANSSI’s position on designing systems so algorithms can be changed. | Guidance | Supports asking vendors how fast they can swap algorithms, not only whether they support ML-KEM today.Our crypto-agility guide → | cyber.gouv.fr | |
| BSI TR-02102-1, version 2026-01BSI (Germany) | Recommended mechanisms and key lengths. PQC in hybrid form; classical-only key agreement recommended only until end-2031 (end-2030 for very high protection needs); classical signatures until end-2035. | FinalTechnical Guideline, updated yearly. | The most precise national dates in the EU. A good benchmark for policy even outside Germany.Our BSI, ENISA, NCSC and ANSSI comparison → | bsi.bund.de | |
| Joint statement “Securing Tomorrow, Today”BSI, ANSSI, NLNCSA and partner agencies | Protect the most sensitive use cases by end-2030 at the latest; use PQC in hybrid form. First issued Nov 2024 (18 EU Member States); updated 27 Jun 2025 (21 European states). | Guidance | The source of the 2030 date for high-risk use cases that the EU roadmap adopted.Our EU roadmap guide → | bsi.bund.de | |
| NCSC timelines for migration to PQCNCSC (United Kingdom) | By 2028: goals, full discovery and an initial plan. By 2031: highest-priority migrations carried out, plan refined. By 2035: migration complete. | Guidance | Relevant for UK operations and suppliers. Its 2028 discovery milestone is later than the EU’s end-2026 start.Our BSI, ENISA, NCSC and ANSSI comparison → | ncsc.gov.uk | |
| CNSA 2.0NSA (United States) | Algorithms for US national security systems (ML-KEM-1024, ML-DSA-87, LMS/XMSS). Exclusive use by 2030 for software signing and networking equipment, by 2033 for browsers, cloud and operating systems; new acquisitions compliant from 1 Jan 2027. | FinalAdvisory (Sep 2022) and FAQ v2.1 (Dec 2024). Binding only for US national security systems. | Not an EU requirement. It matters if you supply US defence customers, and vendor roadmaps often follow it. | media.defense.gov | |
| Preparing for the Post-Quantum Era: A Call to ActionG7 Cybersecurity Working Group (published by ANSSI) | Calls on organisations to start now: phased, risk-based plans, cryptographic inventories, dependency mapping and buying PQC-capable products. | GuidanceNo new deadlines; defers to national timelines. | Confirms that inventory and planning are the expected first steps across G7 countries. | cyber.gouv.fr |
Related guides
Which of these apply to your systems? A cryptographic inventory shows where RSA and elliptic curves are used today, and which standard each one should move to.
Request a demo → Free readiness assessment