Cyber Resilience Act: What you need to know and what you need to be doing

The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, marks a significant shift in the EU’s approach to cybersecurity for products with digital elements. For organizations, the CRA is not merely a technical regulation – it is a strategic compliance challenge that will require close coordination between legal, engineering, and business teams. This overview offers a practical legal roadmap, incorporating recommendations from our DLA Piper Cybersecurity team, who are regularly supporting organizations navigating this complex piece of legislation in a proactive, integrated, and holistic manner.

What is the CRA about?

With the CRA, the EU aims to ensure that digital products placed on the EU market have an adequate level of cybersecurity. This applies to all digital products used by both consumers and businesses. Manufacturers must meet comprehensive requirements throughout the product lifecycle, from planning and design to development and maintenance. Among others, this results in the obligation for vulnerabilities to be handled during the lifecycle of the product (update requirements) and notification requirements to be met in case of cybersecurity incidents. Mandatory CE marking will indicate to customers that digital products meet CRA requirements. 

Timeline

The EU’s CRA entered into force in December 2024. Reporting obligations under Article 14 apply from 11 September 2026, while full product conformity becomes mandatory for items placed on the EU market as of 11 December 2027.

Unlike the NIS2 Directive (for more on NIS2 click here), as a regulation, and not a directive, it is directly applicable in all EU member states without the need for local implementing laws.

In other words, the clock is ticking for any product with digital elements that is intended to be sold in the EU.

What’s in scope – and what’s not

The CRA applies to “products with digital elements”, which encompass hardware, software and their remote data processing solutions. Examples of products with digital elements are:

• hardware products: mobile phones, smart appliances, industrial IoT devices, machinery, network equipment;
• software products: mobile apps, games, operating systems such as firmware or software embedded into hardware devices.

The scope of the CRA is limited to remote data processing solutions designed or developed by or for the manufacturer, which are necessary for the product to function. Put differently: pure cloud/Software-as-a-Service (SaaS) offerings are generally excluded, unless they are essential to the operation of the product (each case should be carefully reviewed and documented) – for more information please see here.

Certain products containing digital elements are regulated by other EU legislation and are therefore exempt from the CRA, including medical devices and vehicles.

Organizations must ensure that product clarifications are documented with a clear rationale for inclusion or exclusion under the CRA. This is particularly important for complex products with cloud components or hybrid architecture.

Placing products on the market

Under the CRA, compliance obligations arise when an individual product is “placed on the market”. This is a per-unit concept, not a per-model one. According to the European Commission's Blue Guide, “placing on the market” refers to the initial supply for distribution, consumption, or use within the EU. This can happen before customs clearance, particularly in cases of online or distance sales.

In the context of software distribution, electronically delivered or downloadable software is, for the purposes of placing on the market, considered equivalent to physical goods. From a compliance and risk management perspective, it is advisable treating each new license granted to a user after 11 December 2027 as a distinct “making available” event under the CRA. This means that, regardless of when the software was first made available to users in the EU, any subsequent electronic delivery or license granted on or after 11 December 2027 must fully comply with the CRA's requirements. Appropriate steps should be taken to ensure that licensing workflows, distribution agreements and technical documentation are reviewed and updated as required.

Business teams within organizations should be advised as follows: Firstly, products placed on the market before 11 December 2027 are not retroactively subject to the CRA’s product requirements, unless they undergo a substantial modification after that date. Secondly, the CRA’s notification requirements apply from 11 September 2026 onward, regardless of when a product in scope was placed on the market.

Substantial modification versus routine maintenance for your products with digital elements

A key legal risk is determining when updates or changes to the product constitute “substantial modification”.

According to the CRA, a substantial modification occurs if product functions are added or changed in a way that increases cybersecurity risk or alters the intended purpose not foreseen in the initial risk assessment. Routine security patches, bug fixes, and minor functional changes (eg UI tweaks, language additions) are generally not considered substantial modifications.

Organizations should establish internal protocols for risk assessment and documentation of all product changes, ensuring that any modification is evaluated for CRA implications and recorded in the technical file.

Spare parts and repairs: How narrow is the exception?

The CRA provides a narrow exception for spare parts made available to replace identical components manufactured in accordance with the same specifications as the original part. Functionally equivalent substitutes do not qualify for this exemption. Accordingly, where organizations plan supplier substitutions or component upgrades, the exception will not apply. Legal teams should advise on the supply chain implications, while engineering teams should document the relevant specifications and ensure that replacement parts strictly meet these limited criteria.

Product categories: Important products and critical products

The CRA introduces a tiered approach to product risk, distinguishing between “important” products – such as identity management systems, browsers, password managers, VPNs, network management systems, SIEMs, operating systems and internet access routers – and “critical” products – such as hypervisors, container runtimes, PKI infrastructure, hardware security modules and industrial firewalls.

Critical products are subject to more stringent conformity assessment procedures, including potential requirements for EU cybersecurity certification. Businesses with legal support should map their product portfolios to these categories as early as possible, since classification affects compliance strategy, technical documentation and market access.

Essential requirements under the CRA

All products within the scope of the CRA must comply with the essential cybersecurity requirements set out in Annex I of the CRA. This includes ensuring that products

• are designed and produced to be secure by design and by default;
• do not ship with any known exploitable vulnerabilities;
• limit the attack surface; protect confidentiality and integrity; and
• can be updated to address vulnerabilities.

Organizations should ensure that (technical) documentation demonstrates compliance with each requirement and that software bill of materials (SBOMs) are maintained in machine-readable formats. Manufacturers are required to conduct a comprehensive risk assessment to identify which CRA requirements apply to the product and ensure their proper implementation.

This assessment must be performed regardless of whether the product with digital elements is considered important or critical. It must be documented to demonstrate compliance (eg to the relevant authorities) and confirm that all relevant requirements have been addressed. Furthermore, the risk assessment plays a vital role throughout the product lifecycle, including planning, design, development, production, delivery, and maintenance.

Support period

Organizations must determine and disclose a “support period” to their customers during which free security updates will be provided. The support period should reflect the expected lifecycle of the product and must be clearly specified in both the EU Declaration of Conformity and the user information.

Support periods must be reasonable, balancing business objectives with regulatory expectations. Transparency is essential; failure to provide updates during the support period could expose the company to enforcement action.

In practice, this means product teams need to set, justify, and communicate a support period upfront and be ready to provide updates for its duration. The CRA does not prescribe a fixed, universal duration for the support period. Instead, organizations are required to set a period that matches the product’s expected lifecycle and to be transparent about it. While the CRA states that a support period must be set for at least five years, this may not be sufficient for products with digital elements that are reasonably expected to remain in use for longer. Conversely, for products with shorter lifespans, a support period of less than five years may be justified.

Vulnerability and incident reporting

Starting 11 September 2026, manufacturers will be required to report actively exploited vulnerabilities and significant incidents impacting the security of the product to the designated Computer Security Incident Response Teams (CSIRT) and the European Union Agency for Cybersecurity (ENISA) via a single reporting platform operated by ENISA. Initial notification must be made within 24 hours, followed by a full report within 72 hours and a final update within 14 days of mitigation.

It must be emphasized that notifications according to the CRA do not replace other legal reporting obligations. If a vulnerability or incident involves personal data, GDPR requirements may require a separate notification to the competent supervisory authority (generally within 72 hours). Additionally, the notification requirements under the NIS 2 Directive and the corresponding EU Member State implementing law may also apply, creating further obligations for early‑warning and incident follow‑up to the national CSIRT.

It is therefore crucial for organizations to ensure that incident response protocols are harmonized across the CRA, GDPR, NIS2 and other applicable legal regimes.

Interplay with the AI Act

Some products with digital elements may also qualify as AI systems under the AI Act. Article 12 of the CRA establishes a link between the two regulatory frameworks. Where a product is a high-risk AI system under the AI Act, compliance with the product requirements and vulnerability handling processes in Annex I of the CRA can be used to demonstrate compliance with the AI Act’s cybersecurity requirements in Article 15. The associated AI Act conformity assessment routes must then be followed. However, nuanced exemptions exist for important and critical products that keep CRA assessment procedures in place for cybersecurity aspects, even if the AI Act's internal control provisions would otherwise take precedence.

Interplay with the Data Act and the GDPR

The requirements of the CRA and the Data Act may apply to the same product, i.e. a product with digital elements may also constitute a connected product or related service within the meaning of the Data Act. Manufacturers carrying out a risk assessment under the CRA, must consider the Data Act requirements, particularly with regard to the data access rights of users and third parties.

Although the CRA and the GDPR do not directly overlap in cases where vulnerabilities are exploited and significant incidents occur, such incidents may still affect personal data, triggering notification obligations under the GDPR.

DLA Piper’s Support for CRA Compliance

DLA Piper is actively supporting clients from a diverse range of industries as they navigate the evolving landscape of the CRA and its far-reaching compliance obligations. Our multidisciplinary team is well-positioned to guide organizations through the complexities of the CRA, ensuring that each client’s approach is tailored to their specific product portfolio, operational needs, and sector-specific risks.

DLA Piper offers strategic recommendations to enable clients to achieve and demonstrate CRA compliance, including:

• Comprehensive Portfolio Review: We assist organizations in conducting a thorough review of their product portfolios to determine the applicability of the CRA to each product line.
• Documented Risk Assessment: Our team supports the development of risk assessments to identify relevant CRA requirements and to provide clear evidence of compliance to authorities.
• Cross-Functional Collaboration: We help establish and coordinate cross-functional teams to define support periods, develop incident response protocols, and standardize documentation practices in accordance with CRA expectations and sector best practices.
• Targeted Training: DLA Piper provides tailored training for product, engineering, and business teams on CRA requirements, incident reporting obligations, and regulatory developments to foster organization-wide understanding and readiness.
• Regulatory Alignment: We facilitate coordination between privacy, data, and AI compliance teams to ensure that regulatory strategies are harmonized and that obligations under the CRA, GDPR, Data Act, and AI Act are fully aligned.
• Ongoing Monitoring: Our experts monitor regulatory developments, including delegated acts and guidance from the European Commission and ENISA, to keep clients ahead of emerging requirements.

The CRA represents a paradigm shift in EU product regulation, with significant implications for legal risk management, product development and market strategy. In-house counsel play a critical role in ensuring cybersecurity compliance is proactive, integrated and holistic.