What the EU Cyber Resilience Act Means for Quantum-Vulnerable Products

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) was published in the Official Journal on 20 November 2024. Its main conformity assessment obligations apply from December 2027, 36 months from entry into force under Article 71. That date is closer than it sounds for manufacturers whose products include quantum-vulnerable cryptographic components, and whose vulnerability handling architecture may not support the firmware update path the Regulation requires.

The CRA does not mention quantum computing. It does not name RSA, ECDH, or any cryptographic algorithm. What it does is impose an obligation to use "state-of-the-art mechanisms" for encryption, and the state of the art for asymmetric cryptography shifted on 13 August 2024, when NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) as final standards. NIST IR 8547 (November 2024) then formally initiated the deprecation of RSA, ECDH, and ECDSA. The regulation uses a dynamic standard; the standard has moved.

This article addresses product security managers, importers, and compliance teams working on CRA conformity. It does not address operators of critical infrastructure, that is the NIS2 obligation. The CRA addresses manufacturers.

Jurisdiction note for UK readers. The CRA is an EU Regulation. It does not apply in the UK. UK organisations are not directly subject to the CRA. However, any organisation that manufactures or imports products with digital elements for sale in EU member states is within scope. UK manufacturers selling into the EU market carry the same conformity obligations as EU-based manufacturers. UK domestic obligations derive from the Product Security and Telecommunications Infrastructure Act 2022 (for consumer IoT devices) and the Cyber Security and Resilience Bill (in consultation as of 2025), which are distinct regimes.

What the EU Cyber Resilience Act Covers and Who It Applies To

The CRA applies to any "product with digital elements" placed on the EU internal market, defined in Article 3(1) as hardware or software products and their remote data processing solutions that directly or indirectly connect to a device or network. The scope is deliberately broad. Industrial control systems, enterprise networking appliances, consumer IoT devices, embedded firmware products, SaaS platforms with a device component, and medical devices with network connectivity may all fall within it.

Several categories are explicitly excluded: products already subject to the Medical Device Regulation, the Machinery Regulation, and a short list of other sectoral instruments. Defence and national security products are excluded. Pure B2B components developed exclusively for integration by another manufacturer into their own product are also excluded under Article 2(2), but the exclusion is narrow. A B2B network appliance sold to enterprises that then deploy it in production is in scope; the exclusion applies where the purchaser integrates the product into their own product before resale, not where they deploy it as a standalone product in their operations.

The CRA establishes product classes beyond the default. Annex III lists "Important Products" in two classes: Class I products (including network infrastructure hardware, smart metering, and industrial IoT components) require a third-party audit only where the manufacturer has not applied harmonised standards; Class II products (including HSMs, cryptographic tokens, industrial automation systems, and SCADA components) require EU-type examination by a notified body regardless of harmonised standard application. Annex IV lists "Critical Products," which require assessment by a notified body under the highest scrutiny tier. If your product appears in Annex III or Annex IV, the conformity obligations are more demanding and the notified body's scrutiny of technical documentation will be more rigorous. [ASSUMED: CRA Annex III and IV product classifications as published in OJ L 2024/2847; verify the final Annex text for any post-publication implementing acts that may adjust classifications.]

The CRA applies to manufacturers outside the EU. A US or UK manufacturer whose routers, HSMs, encrypted storage devices, or industrial control components are sold in EU member states is within scope. Article 18 requires importers to verify that the manufacturer has completed a conformity assessment; Article 19 requires distributors to verify CE marking before placing products on the market. The manufacturer's quantum vulnerability exposure translates directly to the importer's and distributor's compliance obligations.

Key timeline: reporting obligations for actively exploited vulnerabilities and severe incidents apply from 21 months after entry into force, September 2026. The main conformity assessment obligations apply from December 2027.

Where Quantum Vulnerability Appears in the Essential Requirements

CRA Annex I sets out the essential cybersecurity requirements. These are the substantive obligations that products must meet to bear CE marking. Requirement 1 in Part I states products must be "designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks." Requirement 3 specifies that products must be able to "protect the confidentiality of stored, transmitted or otherwise processed data, for instance by encrypting relevant data at rest or in transit using state-of-the-art mechanisms."

"State-of-the-art mechanisms" carries consistent meaning in EU product law. It refers to the technically advanced level achievable with available methods and knowledge at the time of market placement. The standard is not fixed at the date of the Regulation's entry into force, it is assessed at the point when the product is placed on the market. A product shipped in December 2027 is assessed against what state of the art means in December 2027.

Following NIST FIPS 203/204/205 finalisation in August 2024 and NIST IR 8547's formal initiation of RSA, ECDH, and ECDSA deprecation in November 2024, a product shipped after December 2027 that relies exclusively on RSA or ECC key exchange faces a credible conformity challenge: quantum-resistant alternatives are published, standardised, and implementable. The "state of the art" argument for quantum-safe cryptography does not require an EU enforcement decision to have been issued. It requires that the technical standards exist and are usable, which they are. [INFERRED: the conformity challenge rests on the standard EU product law interpretation of "state of the art" as a dynamic, point-of-placement standard; no CRA enforcement decision on cryptographic obsolescence exists as of knowledge cutoff August 2025, and notified body practice on this question is untested.]

Requirement 3 also covers protection against "access, manipulation or destruction of data" and minimisation of incident impact. The harvest-now-decrypt-later (HNDL) threat is a foreseeable threat for any product handling sensitive credentials or long-lived confidential data, not a theoretical future one. A PLC shipped today will be in service in 2035. A smart meter installed in 2027 will be reading and transmitting energy data until the late 2030s. Data those devices generate today may be captured by HNDL-capable adversaries and become decryptable when a CRQC arrives in the 2033 to 2035 probability window. Requirement 3's language covers this: "protect the confidentiality of data" in a product with a 10-year deployment lifetime in a threat environment that includes HNDL adversaries.

Annex I Part II addresses vulnerability handling, the manufacturer's obligations after market placement. Requirement 1 requires manufacturers to address vulnerabilities without undue delay. Requirement 3 requires products to be capable of receiving security updates. Algorithm obsolescence induced by a CRQC is a vulnerability class under the CRA's broad definition in Article 3(14): "a weakness, susceptibility or flaw of a product with digital elements." A manufacturer whose product uses only RSA or ECDH for key exchange and whose firmware cannot be updated has a documented limitation that affects its ability to meet the Part II vulnerability handling obligation once algorithm deprecation becomes effective. [INFERRED: classification of cryptographic algorithm obsolescence as a CRA Article 3(14) vulnerability; this inference follows from the definition's broad language but has not been confirmed by a supervisory authority or notified body guidance document as of knowledge cutoff August 2025.]

Conformity Assessment and Article 13: The Manufacturer's Obligations

Article 13 sets out the general obligations of manufacturers. Article 13(2) requires manufacturers to perform a cybersecurity risk assessment and ensure it is taken into account throughout the product's lifecycle, from design through maintenance. The risk assessment must identify the threats the product faces and document the security properties that address them.

A risk assessment for a product with a 5- to 15-year market lifetime that does not consider the quantum threat is incomplete under Article 13(2). This is not a strict interpretation of a borderline obligation, it is what the Article requires. The threat is documented in multiple public sources (NSA 2021 advisory, NIST IR 8547, ENISA Threat Landscape reports). A risk assessment that omits a documented, public threat affecting the product's primary security function is a gap in the Article 13(2) compliance position.

Article 13(5) requires manufacturers to prepare technical documentation before market placement. The technical documentation must demonstrate compliance with the essential requirements in Annex I. Where the essential requirement is state-of-the-art encryption, the technical documentation must identify what cryptographic algorithms are used, explain why they meet the current state-of-the-art standard, and address how the product can be updated when the standard changes. A manufacturer documenting RSA-2048 or ECDH P-256 as the primary key exchange mechanism for a product shipped after December 2027 will need to justify that choice against the published NIST PQC standards. That justification is harder to sustain with each month that passes.

CE marking under Article 28 is the manufacturer's public assertion that all essential requirements are met. For Important Products (Annex III), a notified body or EU-type examination is required. Notified bodies assessing CRA conformity in the cybersecurity product sector will develop assessment criteria drawing on available harmonised standards. ETSI EN 303 645 (consumer IoT security) is an existing reference for that category. ETSI EN 17927 is the harmonised standard in development for the CRA essential requirements more broadly. When published, it will be the primary reference for notified body assessment. Manufacturers should track its development. [ASSUMED: ETSI EN 17927 development stage and expected publication; verify current position in ETSI work programme before publication.]

Which Products Are Most Exposed

Six product categories face the highest quantum vulnerability exposure under the CRA framework, based on typical product lifetimes and cryptographic usage patterns.

Network infrastructure products (routers, switches, firewalls, VPN appliances) use TLS or IPsec for data in transit, with RSA or ECDH key exchange as the standard. Firmware update cycles are typically 5 to 10 years; products shipped today will still be in service when the NIST deprecation milestones arrive.

Hardware security modules (HSMs) and cryptographic tokens have RSA and ECC as their core function. Migration requires hardware replacement in most architectures, there is no firmware path to replace the cryptographic engine. These are Priority 1 under any quantum risk framework, and they appear in CRA Annex III.

Industrial control systems and PLCs have deployment lifetimes of 15 to 25 years. The confidentiality and integrity of OT credentials and process data are the exposure points; the migration complexity is extreme because of operational downtime constraints and vendor-dependent update paths.

Smart metering and energy management systems have 10- to 15-year typical deployment periods. DLMS/COSEM encryption and the meter authentication PKI are the primary quantum exposure surfaces.

Medical devices with network connectivity combine 10- to 20-year deployment lifetimes with patient data confidentiality requirements of comparable or longer duration. The CRA Annex I Part II vulnerability handling obligations are particularly acute here: a medical device manufacturer whose device cannot receive cryptographic updates faces a documented compliance gap if algorithm deprecation becomes effective during the device's service life.

Encrypted storage and data transfer hardware (hardware encrypted drives, secure USB products, encrypted backup appliances) have data confidentiality as their core function. AES-256 symmetric encryption for data at rest survives Grover's algorithm with a 128-bit effective security margin (per NIST SP 800-57 Part 1 Rev. 5): this is computationally secure. The quantum vulnerability is in the key exchange and key wrapping layer. Products using RSA or ECDH to establish or wrap the AES key are vulnerable even if the AES layer itself is quantum-safe. Manufacturers of encrypted storage products should distinguish these cases in their technical documentation: a product using AES-256 with pre-shared symmetric keys and no asymmetric layer has a substantially different quantum risk profile from one using RSA key wrapping.

What to Do Before December 2027

A quantum vulnerability assessment for CRA conformity has four components. First: a cryptographic inventory of the product, covering every asymmetric algorithm, key exchange mechanism, and digital signature implementation, mapped to the data it protects. Second: a product lifetime assessment: what is the expected market lifetime and the confidentiality duration of the data the product handles? Third: an HNDL exposure analysis: is the product generating or transmitting data today that could be captured and decrypted by a CRQC in the 2033 to 2035 window? Fourth: a cryptographic agility assessment: can the product's algorithms be updated via firmware or software, or does migration require hardware replacement?

For products whose firmware can be updated: the immediate mitigation for HNDL risk is hybrid key exchange. For TLS 1.3, this means X25519+ML-KEM-768 per IETF draft-ietf-tls-hybrid-design: deploying ML-KEM (NIST FIPS 203) alongside X25519 in a combined key exchange, preserving backward compatibility while adding quantum resistance. For IKEv2/IPsec, RFC 9370 ("Additional KEM Combinations for Use in IKEv2," May 2023) assigns code points for ML-KEM combinations. A hybrid migration update deployed before December 2027 demonstrates proactive compliance with the state-of-the-art standard and provides HNDL protection from the point of deployment. [ASSUMED: RFC 9370 ML-KEM implementation status in commercial IKEv2 stacks; verify current implementation coverage in major platforms before citing as a routine migration step.]

For products that cannot be updated via firmware: the risk assessment must document the limitation, the resulting quantum vulnerability, and the compensating controls available: network segmentation, data minimisation, shorter session lifetimes to reduce the HNDL capture window, and accelerated end-of-life planning. This documentation does not constitute a CRA violation in itself. It constitutes an honest technical file, and provides the basis for end-of-life planning before the December 2027 conformity date. A product with a documented, unmitigable quantum vulnerability in its key exchange layer will also face commercial pressure from enterprise buyers whose own PQC programmes require supplier cryptographic conformity, independently of regulatory timelines.

NIST NCCoE SP 1800-38B provides the reference methodology for the cryptographic inventory (the first component above) and migration planning templates. It is the most authoritative publicly available guide for this work.

The CRA in the Broader EU Regulatory Stack

The CRA applies to manufacturers and importers. NIS2 (Directive 2022/2555) applies to operators of essential services (energy, transport, financial market infrastructure, health, and digital infrastructure). The EU AI Act (Regulation (EU) 2024/1689) applies to providers and deployers of high-risk AI systems. A manufacturer of a network-connected industrial control product that incorporates an AI-based anomaly detection component and is deployed by an energy operator may be subject to all three instruments simultaneously: as manufacturer (CRA), and indirectly through its customer's NIS2 and AI Act obligations.

The quantum vulnerability is a thread running through all three. CRA Annex I Part I Requirement 3 requires state-of-the-art encryption for the product itself. NIS2 Article 21(2)(h) requires the operator using the product to implement appropriate cryptographic measures as part of its security obligations. The EU AI Act Article 15 requires AI systems to achieve appropriate cybersecurity against exploitation of vulnerabilities. The compliance argument for post-quantum cryptography is consistent across all three frameworks because they all use the same "state of the art" standard, and the state of the art has shifted.

For the NIS2 obligations of operators of essential services and the quantum risk dimension, see NIS2 and post-quantum cryptography: what essential entities must address. For the EU AI Act dimension, see EU AI Act and quantum security for critical infrastructure operators.