Survey - EU Roadmap on Post-Quantum Cryptography

[John Mattsson]

Hi,

Following the publication of the “Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography (PQC)” [1], the NIS Cooperation Group has launched a survey [2] to ask for feedback on the recently published roadmap and the next steps.

I think it is very positive that the NIS Cooperation Group is inviting public feedback on the next steps well advance of publishing its technical recommendations on PQC, which are expected May 2026 [3]. I think a lot of people in the IETF and on the NIST PQC list might have a lot of good feedback.

Cheers,
John

[1] A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography (PQC)
https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography

[2] Survey - EU Roadmap on Post-Quantum Cryptography
https://digital-strategy.ec.europa.eu/en/news/survey-eu-roadmap-post-quantum-cryptography

[3] PQC Dialogue with Government Stakeholders
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/5_WPq6mFi68/m/bnW6vJbeEgAJ

[John Mattsson]

Hi,

 

Ericsson just provided the following comments to the NIS Coorporation Group

https://emanjon.github.io/EU-comments/2025%20-%20EU%20Roadmap%20on%20PQC.pdf

 

We appreciate that the milestones align well with the international ecosystem, that the importance of early migration to quantum-safe software and firmware upgrades is emphasized, and that the challenges of long transition periods, such as those faced by public-key infrastructures (PKIs) and long-lived devices, are clearly described. We also appreciate the definition that hybrids should not degrade the security properties.

 

Ericsson’s suggested improvement or clarifications include:

 

- We believe the roadmap should be updated to more clearly state that the timelines apply to deployments. The timelines for different stakeholders in the ecosystem, such as standards development organizations (SDOs), equipment vendors, and operators deploying the systems, are inherently different. Standards bodies need to finalize specifications early, vendors need sufficient lead time to implement, test, and certify solutions, and only then can large-scale deployments take place.

- Specify that only public-key algorithms are threatened by CRQCs. The idea that symmetric algorithms with 128-bit keys are practically

threatened by CRQCs is now considered a misconception. As explained in the keynote at CHES 2024, a quantum computer breaking a single AES-128 key would require qubits covering the surface area of the Moon. Any focus on increasing symmetric key lengths diverts attention and resources from the urgent priority: migrating to post-quantum public-key algorithms.

- Clearly emphasize that quantum key distribution (QKD) is not a solution. As government experts correctly state, QKD is not mature for any real-world application and, at best, could serve as defense-in-depth only in 20 years. Any discussion of QKD risks diverting attention and resources from the urgent priority: migrating to PQC. Such a distraction would be both costly and dangerous. Europe is already behind the US in adopting PQC, which is essential for European cybersecurity, and a misguided focus on QKD projects has been one contributing factor. Quantum communication should be treated as basic research, with no practical use for cybersecurity.

- We believe the roadmap should be updated to fully embrace ML-KEM, ML-DSA, and SLH-DSA. These are global standards that represent years of collaborative research by leading cryptographers from around the world. Importantly, the vast majority of the authors of Kyber, Dilithium, and SPHINCS⁺ are European researchers, many of them supported by European universities, institutes, and companies. Research funding from EU Member States and the European Commission has been instrumental in making this possible. These investments have helped Europe play a central role in securing the world’s digital infrastructure against future threats. This is an achievement that the NIS Cooperation Group should explicitly acknowledge and celebrate in its report.

- Explain that organizations that are only now starting to compile their inventories should do their inventory creation in parallel with the planning, testing, and implementation of ML-KEM, ML-DSA, and SLH-DSA.

- Explain that hybrid ML-KEM has already seen massive deployment. In TLS, X25519MLKEM768 is the default in OpenSSL, Firefox, Chrome, Edge, Go, etc. Cloudflare reports that 40% of all HTTPS requests use PQC. OpenSSL 3.5 LTS supports ML-KEM, ML-DSA, and SLH-DSA. OpenSSH is now using mlkem768x25519 as the default key exchange, and many IKEv2 implementations support ML-KEM. The availability of well-tested and interoperable implementations is an essential factor for industry adoption, as it enables cost-effective and reliable deployments.

- While hybridized ML-KEM has been specified by the IETF and adopted in real-world deployments, hybrid signatures have not achieved the same level of standardization or implementation maturity. As a result, hybrid signatures will, for the majority of use cases, not be ready in time to meet the EU roadmap timelines.

- Highlight the need to protect availability. While availability is partially a consequence of integrity protection, it is important for readers to understand that PQC migration also contributes to safeguarding the availability of critical infrastructure.

 

Ericsson’s feedback to guide the next steps, include:

 

- We think the technical recommendations should fully embrace ML-KEM, ML- DSA, and SLH-DSA. These global standards, largely developed by European cryptographers generously funded by Member States and the European Commission, are now endorsed with the highest level of confidence by European government agencies. Many European companies are already deeply engaged in developing and integrating these algorithms to meet the ambitious 2030–2035 PQC deployment timelines. Hybridized ML-KEM, standalone ML-KEM, standalone ML-DSA, and, to some extent, standalone SLH-DSA have already achieved broad implementation support and deployments. At present, they are the only realistic migration paths for European industry. The availability of well-tested, interoperable implementations is a key factor for industry adoption, enabling cost-effective and reliable deployments.

- We believe that technical recommendations should minimize exemptions from NIST specifications such as FIPS 180, 197, and 202–205. Diverging from these international standards introduces unnecessary cost and complexity for European industry, reducing competitiveness. NIST standards already strike a good balance: all approved options in FIPS 180, 197, and 202–205 provide adequate long-term protection for industrial use cases. Any profiling should be left to industry-led standardization bodies, which have the expertise to assess how cryptographic algorithms are used in their systems, the required protection lifetimes, the value of protected assets, system upgrade cycles, and the availability of backup algorithms. For example, 3GPP profiles for X.509, IPsec, and TLS are far stricter than their IETF counterparts, an appropriate approach for critical infrastructure such as 5G. This kind of industry-driven, standards-based process is vastly preferable to top-down regulation and better supports both technical innovation and economic growth.

- We do not believe the technical recommendations should be based on the ECCG Agreed Cryptographic Mechanisms, which appears primarily intended for national security systems and does not meet industrial requirements. Applying ECCG ACM as general guidance for European industry would impose significant costs, reduce the competitiveness of European companies and their products, and provide no practical security benefits. We strongly encourage ECCG to request public comments on the ACM document.

- It is noteworthy that the US government engages with European industry both more extensively and at a much earlier stage during the standardization process than European government organizations do. It is very positive that the NIS Cooperation Group is inviting feedback on the next steps well in advance of publishing its technical recommendations on PQC. We would encourage the Group to build on this openness by following NIST’s example of releasing an Initial Public Draft (IPD) and actively engaging industry, academia, and international government agencies in the review process.

 

Cheers,

John Preuß Mattsson

 

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/GVXPR07MB967822FE1DC1F1BA40611691893BA%40GVXPR07MB9678.eurprd07.prod.outlook.com.