The European Cyber Resilience Act (EU CRA) is a law by the European Commission aimed at products with digital components. The Cyber Resilience Act was adopted as Regulation (EU) 2024/2847 of the European Parliament and of the Council on 23 October 2024. It is directly applicable in all Member States without the need for national transposition.
The Regulation entered into force on 10 December 2024. Its obligations apply in a staged manner:
- The vulnerability and incident notification obligations under Article 14 apply from 11 September 2026.
- The remainder of the Regulation, including the essential cybersecurity requirements set out in Annex I, applies from 11 December 2027.
From that date forward, compliance with the CRA becomes a legal precondition for placing in-scope products on the European Union market and for affixing the CE marking.
Legal context
The CRA forms part of a broader EU cybersecurity strategy. Its function is distinct from, yet complementary to:
- NIS2 Directive, which imposes cybersecurity risk management and incident reporting obligations at the level of essential and important entities;
- Cybersecurity Act, which establishes EU cybersecurity certification schemes;
- Sector-specific regulatory regimes (e.g., medical devices, automotive type approval, aviation safety), which contain their own cybersecurity provisions.
The critical distinction is that the CRA regulates products, not organisations. It introduces horizontal mandatory cybersecurity requirements applicable to products with digital elements intended for the EU market and attaches obligations directly to economic operators, particularly manufacturers.
In doing so, it converts cybersecurity from a voluntary quality feature into a legally enforceable product safety requirement.
This article explains what the CRA requires in practice, with particular focus on its technical cybersecurity measures.
Which products are affected by the EU Cyber Resilience Act?
Products with Digital Elements
Article 3 defines a “product with digital elements” as any software or hardware product and its remote data processing solutions, the intended or reasonably foreseeable use of which involves a direct or indirect logical or physical data connection to a device or network.
The definition is deliberately technology-neutral and function-based. It captures:
- Consumer IoT devices
- Embedded systems
- Stand-alone software
- Industrial control components
- Network infrastructure equipment
- Security products
- Hybrid hardware-software systems
The Regulation applies to products placed on the EU market, irrespective of the manufacturer’s geographic location.
Exclusions
The CRA does not apply to products already subject to equivalent cybersecurity requirements under specific Union legislation, including medical devices, motor vehicles, aviation systems, and certain defence products. The exclusion mechanism is designed to prevent regulatory overlap where sectoral frameworks already address cybersecurity risks comprehensively.
Pure SaaS models are generally outside scope unless delivered as part of, or inseparable from, a product with digital elements.
Classification of Products
The CRA establishes a risk-based categorisation framework, dividing products into three groups.
Products not listed in Annex III fall within the default category and are subject to internal conformity assessment procedures.
Products listed in Annex III, Part I (Class I – Critical Products) and Annex III, Part II (Class II – Highly Critical Products) are subject to stricter conformity assessment procedures reflecting their systemic impact or security function.
Class I products include, among others:
- Identity management systems
- Password managers
- Browsers
- Antivirus software
- SIEM systems
- Microcontrollers
- Routers
Class II products include:
- Operating systems
- Hypervisors
- Hardware Security Modules (HSMs)
- CPUs
- Smartcards and secure elements
For Class I products, manufacturers may rely on harmonised standards or undergo third-party assessment (Article 25). For Class II products, involvement of a notified body through EU-type examination is mandatory.
The Commission retains the power to amend Annex III via delegated acts, enabling dynamic adaptation of the critical product list.
What are the Essential Cybersecurity Requirements of the Cyber Resilience Act?
The core substantive CRA requirements are set out in Annex I, which is divided into two parts:
- Part I: Security requirements relating to product properties
- Part II: Vulnerability handling requirements
These obligations apply horizontally to all products in scope, irrespective of classification.
1. SECURITY REQUIREMENTS RELATING TO THE PROPERTIES OF PRODUCTS WITH DIGITAL ELEMENTS
Article 10 establishes the obligation that products with digital elements be designed, developed, and produced in accordance with a cybersecurity risk assessment. The risk assessment must identify and analyse relevant risks and must inform design, development, production, and maintenance decisions. It must also form part of the technical documentation required under Article 31.
Annex I, Part I, requires that products:
- Be placed on the market without known exploitable vulnerabilities
- Be designed to reduce attack surfaces, including external interfaces
- Be delivered with secure-by-default configurations
- Provide mechanisms to protect against unauthorised access (including authentication and access control)
- Protect confidentiality of stored and transmitted data (e.g., through encryption)
- Protect integrity of data, commands, and configurations
- Ensure resilience and availability, including protection against denial-of-service attacks
- Minimise data processing to what is necessary for intended use
- Record and/or monitor relevant security events
- Include secure update mechanisms
- Reduce the impact of incidents through appropriate mitigation techniques.
The requirement that products be placed on the market without known exploitable vulnerabilities materially alters pre-release expectations. It effectively mandates structured vulnerability identification during development and testing phases and limits tolerance for deferred remediation.
In practical terms, compliance presupposes implementation of a Secure Software Development Lifecycle (SSDLC), formal threat modelling, secure coding standards, and documented validation processes.
2. VULNERABILITY HANDLING REQUIREMENTS
Article 14 introduces binding post-market obligations. These requirements apply from 11 September 2026.
Manufacturers must establish and maintain structured processes to identify, document, and remediate vulnerabilities. This includes:
- Maintaining a Software Bill of Materials (SBOM) in a commonly used and machine-readable format
- Regularly testing and reviewing product security
- Addressing vulnerabilities without undue delay
- Providing security updates free of charge
- Ensuring secure distribution mechanisms for updates
- Publicly disclosing information on fixed vulnerabilities
- Providing users with necessary remediation guidance
- Establishing and enforcing a coordinated vulnerability disclosure (CVD) policy
- Providing a contact point for vulnerability reporting
- Notifying ENISA(The European Union Agency for Cybersecurity) of actively exploited vulnerabilities and severe incidents.
These provisions shift cybersecurity from a static compliance exercise to a lifecycle obligation. The manufacturer’s responsibility continues for the duration of the support period.
Conformity Assessment, Technical Documentation, and CE Marking
Prior to placing a product on the market, manufacturers must complete the applicable conformity assessment procedure (Articles 24–25), compile technical documentation (Article 31), draw up an EU Declaration of Conformity (Article 30), and affix the CE marking (Article 28).
The technical documentation must demonstrate compliance with Annex I and include, at a minimum:
- The cybersecurity risk assessment
- A description of design and development processes
- Documentation of vulnerability handling procedures
- Evidence of testing and validation.
For Class II products, third-party assessment by a notified body is mandatory.
EU CRA conformity assessment type according to the class of products
Open Source Software
The Regulation clarifies that free and open-source software (FOSS) developed outside the course of commercial activity falls outside scope. However, when such software is integrated into commercial products placed on the EU market, responsibility for compliance rests with the economic operator placing such products on the market.
The CRA therefore regulates commercial deployment rather than volunteer development.
Penalties for non-compliance with EU Cyber Resilience Act
Enforcement of the Cyber Resilience Act is carried out by the Member States through their designated market surveillance authorities. Each Member State is responsible for establishing rules on penalties applicable to infringements of the Regulation and for ensuring their implementation.
Administrative fines may reach up to €15 million or 2.5% of the total worldwide annual turnover of the preceding financial year, whichever is higher, for non-compliance with the essential cybersecurity requirements set out in Annex I and the related obligations imposed on manufacturers.
Market surveillance authorities are empowered to take corrective measures where non-compliance is identified. These measures may include requiring the economic operator to bring the product into conformity, restricting or prohibiting its availability on the market, or ordering its withdrawal or recall in accordance with the applicable market surveillance framework.
How can manufacturers prepare for the new law?
The following framework may be used as a structured internal review tool.
1. Scope and Classification
- Confirm that the product qualifies as a “product with digital elements” under Article 3.
- Determine whether the product is listed in Annex III (Class I or Class II).
- Identify the appropriate conformity assessment procedure.
2. Cybersecurity Risk Assessment (Article 10)
- Perform and document a structured cybersecurity risk assessment.
- Ensure findings inform architecture, development, and maintenance decisions.
- Integrate the assessment into technical documentation.
3. Secure Design and Development Phases (Annex I, Part I)
- Implement secure-by-design and secure-by-default configurations.
- Eliminate known exploitable vulnerabilities prior to release.
- Implement appropriate authentication, encryption, integrity, and availability controls.
- Design and validate secure update mechanisms.
- Implement logging and security monitoring capabilities.
4. Vulnerability Management (Article 14; Annex I, Part II)
- Establish a documented vulnerability management process.
- Maintain an SBOM.
- Implement coordinated vulnerability disclosure procedures.
- Define internal remediation timelines.
- Implement ENISA notification workflows (effective 11 September 2026).
5. Documentation and Governance
- Compile complete technical documentation in accordance with Article 31.
- Prepare the EU Declaration of Conformity.
- Assign organisational responsibility for CRA compliance.
- Align supplier contracts with CRA obligations.
Get funding to help you prepare for CRA
For many organizations, the Cyber Resilience Act translates into very concrete changes: formalising a secure development lifecycle, introducing structured vulnerability handling, improving SBOM management, hardening default configurations, and building the technical documentation needed for conformity assessments.
The SECURE project (Strengthening EU SMEs Cyber Resilience), funded under the Digital Europe Programme, is aimed specifically at helping EU micro, small and medium-sized enterprises that fall within the scope of the CRA. Through cascade funding (Financial Support to Third Parties), SECURE provides grants directly to individual companies to support hands-on cybersecurity improvements.
The funding can be used for activities such as:
- Performing product-level security gap assessments against CRA requirements
- Introducing or maturing secure SDLC practices
- Implementing vulnerability management and coordinated disclosure processes
- Improving logging, update mechanisms, and security-by-design controls
- Preparing the technical documentation required for conformity assessments
- Training development and DevOps teams on product security obligations
Is penetration testing required under the Cyber Resilience Act?
The Cyber Resilience Act does not explicitly require penetration testing. The Regulation does not mandate any specific security testing methodology by name. Instead, it requires manufacturers to design and develop products in accordance with a documented cybersecurity risk assessment (Article 10), to place products on the market without known exploitable vulnerabilities (Annex I, Part I), and to regularly test and review product security as part of their vulnerability handling processes (Annex I, Part II; Article 14). The CRA is intentionally technology-neutral: it defines security outcomes and lifecycle obligations rather than prescribing particular tools or techniques.
In practice, penetration testing may be used as part of a broader, risk-based security validation strategy, but it is not a standalone legal requirement under the Regulation.
Penetration testing report may facilitate compliance by providing documented evidence that attack surfaces have been assessed, authentication and access controls have been validated, common exploitation paths have been examined, and identified vulnerabilities have been remediated prior to release. Such reports can strengthen the technical documentation required under Article 31 and may be particularly useful when undergoing independent review for higher-risk products.
Conclusion
The CRA is a response to both the growing number of cyber threats and the increased use of digital or connected products, aimed at countering cybersecurity threats and national security risks stemming from insecure devices. The Cyber Resilience Act aims to secure the whole supply chain of digital products, reducing the costs of handling the effects of cyberattacks and increasing the public’s trust in hardware and software products entering the European market.
If you are a device manufacturer interested in improving the cybersecurity of your products, contact us to learn more about our product security services.
