Cyber Resilience Act post-quantum cryptography: required?

The link between the Cyber Resilience Act and post-quantum cryptography works like this. Regulation (EU) 2024/2847 does not name quantum-resistant algorithms. It does require manufacturers to encrypt data in transit with state-of-the-art mechanisms and to keep products secure through updates. The EU’s PQC roadmap sets out what “state of the art” is expected to mean for critical infrastructure over the coming years.

For organisations that run operational technology (OT) and connect substations, plants, pumping stations, cloud workloads and remote engineers, this matters in practice. Network and OT equipment bought from late 2027 onward will probably still be in service when the EU expects high-risk systems to have moved to post-quantum protection. This article explains how the CRA, NIS2 and the EU PQC roadmap fit together, and what that means for the encrypted links between your sites.

Does the Cyber Resilience Act require post-quantum cryptography?

Not explicitly. The CRA requires “state of the art” encryption decided through a risk assessment, and over a product’s support period that standard will increasingly mean quantum-resistant key exchange.

The key wording is in CRA Annex I essential cybersecurity requirements, Part I, point 2(e). Products with digital elements must protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms, and by using other technical means. This obligation applies on the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable.

The regulation names no algorithm, so it gives no deadline for switching from classical to post-quantum key exchange. What it does do is tie compliance to a moving target. A VPN gateway or industrial router that used only classical elliptic-curve key exchange might be defensible in 2027. It becomes harder to defend once European authorities have set dates by which critical infrastructure should be protected against quantum attacks.

When do the Cyber Resilience Act obligations apply to network and OT products?

The main CRA obligations apply from 11 December 2027. Vulnerability and incident reporting has applied since 11 September 2026.

The CRA entered into force on 10 December 2024. It will be fully applicable as of 11 December 2027 with some provisions starting to apply earlier: Chapter IV on the notification of conformity assessment bodies will apply from 11 June 2026, whereas reporting obligations set out in Article 14 apply from 11 September 2026.

Industrial equipment is clearly in scope. The EUR-Lex summary lists hardware such as internet-of-things devices, smart home appliances, industrial control systems, microchips. Network security products are treated more strictly. Commission material lists routers and firewalls among “important products” that require application of standards/third-party assessment, and Implementing Regulation (EU) 2025/2392 sets out the technical descriptions of those categories.

Two practical points stand out. First, the reporting deadlines are tight. Manufacturers need to submit an early warning within 24 hours of becoming aware, and a full notification within 72 hours. Second, there is a transition rule for equipment already installed: products with digital elements that have been placed on the market before 11 December 2027 are subject to the CRA only if, from that date, they are subject to a substantial modification. To help manufacturers interpret these rules, the Commission’s non-binding guidance includes 67 practical examples, a range of use cases, flowcharts and graphs.

What does state-of-the-art encryption mean under NIS2 Article 21?

Under Directive (EU) 2022/2555 (NIS2) Article 21, the operator rather than the manufacturer must keep a cryptography policy that is reviewed against the state of the art. Where it is implemented in detail, that policy should include crypto-agility.

Article 21(1) requires essential and important entities to take proportionate measures taking into account the state-of-the-art. Article 21(2)(h) adds policies on cryptography and, where appropriate, encryption. Commission Implementing Regulation (EU) 2024/2690 makes this concrete for digital infrastructure and ICT service providers. Entities must define the protocols or families of protocols to be adopted, as well as cryptographic algorithms, cipher strength, cryptographic solutions and usage practices to be approved and required for use in the relevant entities, following, where appropriate, a cryptographic agility approach. They must also review and, where appropriate, update their policy and procedures at planned intervals, taking into account the state of the art in cryptography.

Energy, water and transport operators are covered through national transposition of NIS2 rather than directly by 2024/2690. Even so, ENISA’s guidance on that regulation is a useful benchmark, and ENISA notes it may provide indications on the technical and the methodological requirements of the cybersecurity risk-management measures of NIS 2 Directive, which may be considered useful by other public or private actors. For OT operators, that means site-to-site, edge-to-cloud and remote-access links should be in the cryptographic inventory, with a planned review of their key exchange.

How does the EU PQC roadmap tie in with the Cyber Resilience Act?

The roadmap sets the timeline for critical infrastructure. The CRA is the product law through which quantum-safe updates are expected to reach the market.

The roadmap goes back to Commission Recommendation (EU) 2024/1101, which calls for deploying PQC into existing public administration systems and critical infrastructures via hybrid schemes that may combine Post-Quantum Cryptography with existing cryptographic approaches or with Quantum Key Distribution. The NIS Cooperation Group PQC workstream is co-chaired by Germany, France and the Netherlands and published the coordinated roadmap in June 2025.

Its milestones, as presented by the European Commission at ENISA:

• By 31 December 2026: PQC roadmaps defined in each Member State, with planning for high- and medium-risk use cases under way.
• By the end of 2030: high-risk use case migrated: critical infrastructure (eg water, energy, health care, finance and transportation) and high-risk domains.
• By the end of 2035: all migrations completed, for every risk level.

The same presentation describes a “strong hook to the Cyber Resilience Act in the Roadmap”. The 2030 milestone expects quantum-safe software and firmware upgrades to be enabled by default. Stakeholder engagement continues: in the 2025 survey, 63 respondents provided feedback on areas of the roadmap seeking further clarification, and the workstream is working on a second deliverable to supplement the EU Roadmap for the Transition to PQC.

Do VPN gateways and OT devices sold after 2027 need to be crypto-agile?

The CRA does not use the word “crypto-agile”. However, its update obligations and the EU roadmap together make it hard to argue that a network product could reach 2030 without being able to change its key-exchange algorithm.

The roadmap treats crypto-agility as a basic design principle. Fabiana Da Pieve, Programme Manager at the European Commission, summarised the definition in a presentation hosted by ENISA: cryptographic “routines and ciphers can be easily upgraded or replaced without having to completely replace the underlying application or device.”

Annex I of the CRA requires that vulnerabilities can be fixed through security updates during the support period. If the weakness is in the cryptography itself, the fix is an algorithm change. A product that can only get one by replacing hardware does poorly on both CRA and NIS2 grounds. ENISA’s Executive Director Juhan Lepassaar explained why this matters for critical sectors: “Vulnerabilities in digital products are often exploited by threat actors to subvert or hamper critical services.”

When procuring VPN gateways, industrial routers and remote-access components for delivery after December 2027, ask manufacturers specific questions:

• Which key exchange is used today, and is a post-quantum component (for example ML-KEM, FIPS 203) already combined with a classical one?
• Can the post-quantum algorithm be replaced by a software update, and who delivers that update during the support period?
• What happens to cryptographic updates if a support contract ends?
• Does the product fall back to weaker or unencrypted modes when a negotiation fails?

The hybrid approach in the last answer area is not just a vendor preference. The EU Rolling Plan reports that French guidance requires PQC algorithms to be hybridized with well-known pre-quantum algorithms and systems must be crypto-agile.

Which harmonised standards will cover cryptography under the CRA?

None has been finalised yet specifically for post-quantum algorithms. The work is being done in CEN-CENELEC JTC 13, including a new working group on cryptography, under the Commission’s CRA standardisation request.

Harmonised standards are important because products with digital elements which are in conformity with harmonised standards, which translate those essential requirements into detailed technical specifications, should therefore be presumed in conformity with the Cyber Resilience Act. The Commission’s request (C(2025) 618) lists 41 European standards. European standards listed as entries 1 to 15 and 39 to 41 in Annex I shall be developed jointly or separately by CEN and Cenelec. European standards listed as entries 16 to 38 in Annex I shall be developed jointly by CEN, Cenelec and ETSI. The request combines horizontal standards for Annex I with vertical standards for important and critical product categories.

For cryptography in particular, the EU Rolling Plan for ICT Standardisation reports that the CEN CENELEC JTC 13 has established a dedicated Special Working Group on Cyber Resilience Act (CEN/CLC/JTC 13/WG 9) and that a new WG10 cryptography has been created to act as mirror of ISO/IEC JTC1/SC27/WG2 and focus on new topics like PQC. For OT, the EN IEC 62443 series adopted through CLC/TC 65X remains the main reference for industrial component security. ENISA’s CRA standards mapping found that its confidentiality requirement is generic and gives no technical detail on algorithms.

In practice, CRA product standards will probably refer to cryptographic requirements rather than define post-quantum algorithms themselves. Until those references are published, NIST FIPS 203 and national agency guidance on hybrid key exchange are the most concrete benchmarks available.

How should OT operators plan quantum-safe links between sites, cloud and remote users?

Start with links that carry long-lived sensitive data over networks you do not control. Then pick architectures that allow algorithm changes without touching OT endpoints.

Most OT controllers cannot run post-quantum cryptography themselves, and many will not receive firmware updates during the roadmap period. A common answer is to protect the path rather than the device: put encryption gateways at each end of a site-to-site, edge-to-cloud or remote-access connection. Then the cryptography can be updated in one place. One example of this approach is Quantum Network’s QPN. It encrypts at Layer 3 between an organisation’s own locations, combines a classical key agreement with ML-KEM in a hybrid scheme, sits alongside existing firewalls and routers, and lets the post-quantum algorithm be changed if necessary. Like any in-transit measure, it protects the data on the link, not the devices behind the gateway.

A workable sequence for critical infrastructure operators:

1. Inventory per link, not per device. Record each inter-site, cloud and remote-access path, the key exchange it uses and how long its data stays sensitive.
2. Rank by exposure. Paths over public internet or third-party carriers come before links inside a single site or an air-gapped segment.
3. Set 2030 as the planning horizon for high-risk links, in line with the NIS Cooperation Group milestone, and record that decision in the Article 21 cryptography policy.
4. Write crypto-agility into procurement for anything delivered after December 2027, including how algorithm updates are delivered and what happens when support ends.
5. Review at planned intervals as CEN-CENELEC JTC 13 WG10 and the NIS Cooperation Group publish further deliverables.

None of these steps depends on knowing exactly when a cryptographically relevant quantum computer will arrive. They depend on dates that are already set: 11 December 2027 for the CRA, and the end of 2030 for high-risk critical infrastructure under the EU roadmap.