The Cyber Resilience Act, formally Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements, is the European Union's first horizontal cybersecurity regulation for digital products. It applies to manufacturers, importers, and distributors of products that contain software or hardware with computing capability and that are placed on the EU market.
The CRA was published in the Official Journal of the European Union on 20 November 2024. It entered into force on 10 December 2024. Most obligations apply from 11 December 2027, though the vulnerability notification obligations under Article 14 apply from 11 September 2026, and the standards-setting and conformity assessment infrastructure has been building up through 2025 and 2026.
For cryptography teams, the CRA matters in three ways. First, Annex I sets essential cybersecurity requirements that include cryptographic obligations. Second, Annex III defines "important products" and "critical products" with stricter conformity assessment regimes, including categories that depend heavily on cryptography. Third, the migration to post-quantum cryptography is implicit in the Annex I "state of the art" requirement and explicit in the harmonised standards being developed by ETSI and CEN-CENELEC.
This article explains the structure of the CRA, the cryptographic obligations in Annex I, the categorisation of products, and the post-quantum implications for manufacturers and integrators.
The Scope of the CRA
Article 2 of the CRA sets the scope: products with digital elements made available on the EU market. A "product with digital elements" is defined in Article 3(1) as a software or hardware product (and its remote data processing solutions) where the absence of components or remote data processing would prevent it from performing its functions.
Excluded categories include products covered by Regulation (EU) 2017/745 (medical devices), Regulation (EU) 2017/746 (in-vitro diagnostic medical devices), Regulation (EU) 2018/1139 (civil aviation), Regulation (EU) 2019/2144 (motor vehicles), and other sector-specific regulations that already impose cybersecurity requirements.
Free and open source software developed or supplied outside the course of a commercial activity is excluded from most obligations under Article 2(7), although there are reporting obligations for "open source software stewards" under Article 24.
The practical effect: nearly every commercial software, firmware, and hardware product placed on the EU market that contains a network interface, computing capability, or remote data processing comes within scope.
Annex I: Essential Cybersecurity Requirements
Annex I of the CRA contains the essential cybersecurity requirements. These apply to all products with digital elements unless explicitly excluded.
Section 1 of Annex I sets out cybersecurity requirements relating to the properties of products with digital elements. Manufacturers must ensure that:
(1) products are designed, developed, and produced to ensure an appropriate level of cybersecurity based on the risks; (2) products are made available without known exploitable vulnerabilities; (3) the security configuration is set securely by default; (4) products ensure protection from unauthorised access through appropriate control mechanisms; (5) products ensure protection of the confidentiality of data, "by encrypting relevant data at rest or in transit by state-of-the-art mechanisms"; (6) products ensure protection of the integrity of data; (7) products process only data that is adequate, relevant, and limited to what is necessary; (8) products protect availability of essential and basic functions; (9) products minimise their negative impact on the availability of services provided by other devices and networks; (10) products are designed, developed, and produced to limit attack surfaces; (11) products are designed, developed, and produced to reduce the impact of incidents using appropriate exploitation mitigation mechanisms and techniques; (12) products provide security-related information by recording and monitoring relevant internal activity; (13) products allow users to securely remove all data and settings.
Item (5) is the explicit cryptography obligation. The phrase "state-of-the-art mechanisms" mirrors NIS2 and GDPR Article 32. The interpretation will rely on harmonised standards under Article 27 of the CRA and on ENISA technical guidance.
Section 2 of Annex I sets out vulnerability handling requirements. These include identifying and documenting vulnerabilities, addressing vulnerabilities without delay, applying effective and regular tests, sharing information about fixed vulnerabilities, and disclosing vulnerabilities responsibly.
Annex III: Important and Critical Products
Annex III categorises products into "important" and "critical" classes, with stricter conformity assessment for the latter.
Important products under Class I include identity management systems, browsers, password managers, software that searches for vulnerabilities, products with security functions, network management systems, configuration management software, network traffic monitoring tools, telecommunications devices, microcontrollers, smart card readers, and operating systems for non-consumer use.
Important products under Class II include hypervisors, container engines, public key infrastructure software, firewalls, intrusion detection and prevention systems, microcontrollers with security functions, hardware-based devices with security boxes, and smart meter gateways.
Critical products under Annex IV are subject to mandatory European cybersecurity certification under the Cybersecurity Act framework. The first set is expected to include hardware security modules (HSMs), smart cards, and secure cryptoprocessors.
For cryptography, this categorisation is consequential. PKI software, HSMs, password managers, and identity management systems all contain or rely on cryptographic primitives. The conformity assessment for Class II important products requires third-party assessment by a notified body or compliance with harmonised standards.
Conformity Assessment
Article 32 of the CRA sets out the conformity assessment procedures. Default products can use module A (internal control), based on conformity to harmonised standards. Important Class I products can use module A only if compliant with applicable harmonised standards; otherwise they need module B+C, B+D, or H. Important Class II products require module B+C, B+D, or H. Critical products require certification under the EU cybersecurity certification scheme.
The CE marking is affixed to products that complete conformity assessment. Products without CE marking cannot be placed on the EU market.
For cryptographic products, the harmonised standards effort is being led by CEN-CENELEC Joint Technical Committee 13 and ETSI. The harmonised standards are expected to reference NIST FIPS 203, FIPS 204, FIPS 205, ETSI quantum-safe specifications, and existing standards including ISO/IEC 19790 (security requirements for cryptographic modules) and FIPS 140-3.
Vulnerability Notification
Article 14 of the CRA requires manufacturers to notify ENISA of any actively exploited vulnerability contained in their product. The notification timeline is:
- early warning: 24 hours after the manufacturer becomes aware;
- notification: 72 hours;
- final report: 14 days after a corrective or mitigating measure is available.
Manufacturers must also notify ENISA of any severe incident having impact on the security of the product.
For cryptographic products, this means that exploitation of a cryptographic vulnerability triggers the reporting timeline. A buffer overflow in a TLS implementation, a side-channel attack on an HSM, a key leakage in a password manager, or an authentication bypass in a PKI product would all trigger Article 14 obligations.
Post-Quantum Cryptography Implications
The CRA does not name specific algorithms in its essential requirements. The "state of the art" language requires manufacturers to track the evolving consensus on cryptographic baselines.
For products with long support periods, post-quantum readiness becomes a manufacturing decision today. A network appliance with a 10-year support window, placed on the EU market in 2027, will still be in service in 2037. The CRA Article 13 obligation to provide security updates throughout the support period means that the manufacturer must address cryptographic deprecations as they occur.
The CNSA 2.0 timeline, published by the NSA in September 2022, expects post-quantum cryptography in national security systems by 2030 and full transition by 2035. The NIST PQC standards (FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA) were finalised in August 2024. The ETSI TC CYBER QSC working group has published TS 103 692 and other quantum-safe specifications.
For a CRA-covered manufacturer, the practical implication is that products placed on the market in 2027 should support, or be capable of being upgraded to support, post-quantum cryptography. Products that cannot are likely to fail the "state of the art" requirement during their support period.
For an integrator (a manufacturer using third-party cryptographic libraries or modules), the implication is that supplier selection should include post-quantum readiness as a criterion.
For a PKI product specifically, the obligation is to support hybrid certificate issuance and post-quantum certificate issuance, with crypto-agility as a core architectural property. The IETF PKIX and LAMPS working groups have draft standards for hybrid certificates and PQ algorithms in X.509 (see IETF PQC Internet Drafts).
Support Period and Updates
Article 13 of the CRA requires manufacturers to define a support period during which they will provide security updates. The support period must be at least five years, or longer if the product is reasonably expected to be in use for longer.
This obligation has significant implications for cryptographic agility. A product placed on the market in 2027 with a 10-year support period must be capable of receiving security updates that address cryptographic deprecations (RSA-2048 deprecation, classical ECDSA deprecation, post-quantum migration) through to 2037.
Manufacturers that cannot deliver such updates face withdrawal from the market and potential financial penalties.
Penalties
Article 64 of the CRA sets penalty levels:
- non-compliance with essential cybersecurity requirements (Annex I) and vulnerability handling: up to EUR 15 million or 2.5 percent of total worldwide annual turnover, whichever is higher;
- other non-compliance: up to EUR 10 million or 2 percent;
- supplying incorrect or incomplete information to a notified body or market surveillance authority: up to EUR 5 million or 1 percent.
These penalties apply to manufacturers, importers, and distributors. Member State market surveillance authorities can also order corrective actions, recall products, or withdraw products from the market.
Practical Compliance Roadmap
Inventory of cryptographic dependencies. For each product, document the cryptographic algorithms, libraries, and modules used.
Crypto-agility design. Architect new products to support algorithm replacement without architectural changes. Hybrid mode (classical + post-quantum) is a strong architectural pattern.
Vulnerability handling process. Implement a process that meets the Article 14 notification timelines. Cryptographic vulnerabilities require specialised assessment.
Support period planning. Decide and document the support period for each product. Ensure the cryptographic stack can be updated through the support period.
Conformity assessment preparation. For Class I and Class II products, identify the appropriate module and the relevant harmonised standards or notified body.
Software bill of materials. Annex I Section 2 paragraph 1 requires manufacturers to identify and document vulnerabilities. An SBOM is the practical mechanism. Cryptographic libraries are first-class SBOM components.
For more on planning, see Hybrid Migration Strategy Step by Step. For implementation, see Hybrid Encryption.
FAQ
Does the CRA apply to my SaaS product? The CRA applies to products with digital elements, including remote data processing solutions necessary for those products. Pure SaaS without a client-side product element is generally outside the CRA scope but may be covered by NIS2 or DORA.
Does the CRA apply to free and open source software? Article 2(7) excludes FOSS developed or supplied outside the course of a commercial activity. Article 24 imposes lighter obligations on "open source software stewards." Commercial distributions of FOSS are within scope.
When do the obligations apply? Most obligations apply from 11 December 2027. Vulnerability notification obligations under Article 14 apply from 11 September 2026.
Is post-quantum cryptography mandated by the CRA? Not by name. The Annex I "state of the art" requirement and the Article 13 support period requirement effectively mandate post-quantum readiness for products with long support periods.
What is "state of the art"? ENISA, BSI, ANSSI, and harmonised standards under Article 27 will define this in practice. As of 2026, this means AES-256, hybrid post-quantum KEM and signatures for new long-term systems, and crypto-agility as an architectural property.
Sources
- Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), https://eur-lex.europa.eu/eli/reg/2024/2847/oj
- ENISA, Post-Quantum Cryptography: Current state and quantum mitigation, https://www.enisa.europa.eu/publications/post-quantum-cryptography-current-state-and-quantum-mitigation
- NIST FIPS 203, FIPS 204, FIPS 205, https://csrc.nist.gov/projects/post-quantum-cryptography
- ETSI TC CYBER Quantum-Safe Cryptography (QSC) standards, https://www.etsi.org/committee/cyber
- Regulation (EU) 2019/881 (Cybersecurity Act), https://eur-lex.europa.eu/eli/reg/2019/881/oj
Related Articles
- ENISA Threat Landscape
- NIS2 Directive Cryptography
- Hybrid Encryption
- NIST FIPS Guide
- IETF PQC Internet Drafts
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.