Blogpost

The Cyber Resilience Act (CRA) in 10 questions and answers

Table of Contents

While the NIS2 Directive requires essential and important entities to achieve a certain level of cybersecurity at organisational level, the Cyber Resilience Act (CRA) introduces cybersecurity requirements at product level in addition to organisational cybersecurity obligations.

Products with digital elements (PDEs) must therefore comply with specific minimum cybersecurity requirements under the CRA. In this blog, we explain what this means.

 

Key takeaways

  • The CRA makes cybersecurity a legal product requirement. Products with digital elements must be securely designed, maintained and supported throughout their lifecycle to remain on the EU market.
  • The role of manufacturer is determined by your position in the supply chain, not by who technically developed the software. Organisations that market products under their own name or integrate third-party software into their own solutions may legally be considered manufacturers and will bear the corresponding obligations under the CRA.
  • Contracts play an important role in achieving CRA compliance. Manufacturers remain legally responsible, but contractual arrangements shape how vulnerability management, updates and supplier cooperation are implemented.
  • Preparation must start now, not in 2027. Organisations should already review their supply chain structure, contractual framework and internal responsibilities to ensure they are ready to comply once the CRA becomes fully applicable.

1. Why do we need cybersecurity requirements for products?

The need for cybersecurity requirements for products with digital elements (hereinafter PDEs or products) can best be illustrated with a simple example.

Imagine a manufacturer placing a smart access control system on the market that determines who may enter an office building. The hardware and software function perfectly. 6 months later, however, a hacker discovers a vulnerability in one of the system’s software components. By exploiting this vulnerability, the hacker gains access to the building. The vulnerable software component was not developed by the manufacturer, but by one of its suppliers.

A vulnerable access control system creates a risk for the manufacturer’s customer, namely the user of the system. It turns out that some customers use the system not only to control access to office buildings, but also to server rooms and industrial facilities.

This situation raises several difficult questions:

  • Who is responsible for fixing the vulnerability (the manufacturer or the supplier of the vulnerable software component)?
  • Should customers be informed of the vulnerability?
  • If customers must be informed, who will do so?
  • Who bears the cost of remediation?
  • Who is liable for any resulting damage?

Until recently, the answer to these questions largely depended on contractual freedom. The party with the stronger negotiating position often determined the allocation of risks. The Cyber Resilience Act (CRA) changes this.

This example is not unique. In addition to vulnerabilities, it is often unclear how long a manufacturer will support a product or how frequently security updates will be provided.

The CRA addresses this by requiring manufacturers to ensure the cybersecurity of their products throughout the entire lifecycle of the product. This includes, among others:

  • secure design,
  • vulnerability management,
  • security updates, and
  • incident reporting.

In short, adequate cybersecurity is now a condition for placing a product on the EU market.

2. What falls within the scope of the CRA?

Not all products must comply with the CRA’s cybersecurity requirements. The Regulation applies only to products with digital elements that are made available on the European market and that themselves, or through the device on which they run, can exchange data with other devices or networks.

But what are products with digital elements under the CRA? They include both hardware and software products, including software components placed separately on the market, that connect directly or indirectly to networks or other devices. Think of the smart access control system mentioned above.

A fully offline product with no connectivity capabilities will in principle fall outside the scope of the CRA.

3. When does the CRA apply?

The CRA entered into force in December 2024, but its obligations apply in stages.

  • The first important milestone is September 2026. From that date, manufacturers must report actively exploited vulnerabilities and severe incidents relating to their products.
  • The CRA becomes fully applicable in December 2027. From that moment onward, all products with digital elements placed on the EU market must comply with the CRA’s cybersecurity requirements.

Although this transition period may seem long, contracts are often concluded for longer durations. Many supplier agreements signed today will still be in force once the CRA becomes fully applicable. Organisations should therefore already take the CRA into account when entering into new contracts.

4. To whom does the CRA apply?

The CRA applies to all economic operators placing products with digital elements on the EU market.

This includes:

  • manufacturers
  • importers
  • distributors
  • authorised representatives

Importantly, the CRA looks at your actual role in the supply chain, not merely your contractual designation. If you place a product on the market under your own name or trademark, you are considered the manufacturer, even if another party originally developed the product. If you modify a product in a way that affects its cybersecurity, you may also be considered a manufacturer.

This has significant implications for organisations that:

  • offer white-label products
  • integrate third-party software
  • bundle third-party software into their own solutions
  • resell connected products under their own brand

In such cases, contractual roles and legal roles may diverge. Ultimately, your legal qualification determines your obligations under the CRA.

5. Who is the manufacturer under the CRA?

One of the most important and often misunderstood questions under the CRA is who qualifies as a manufacturer. This matters because the manufacturer bears key obligations under the CRA.

The CRA defines the manufacturer as the entity that develops or manufactures a product with digital elements, or has it designed, developed or manufactured, and markets it under its own name or trademark. In other words, you may be considered a manufacturer even if you did not physically produce the product yourself.

This has important practical consequences:

  • If you offer a product (e.g. software) under your own brand on a white-label basis, you are the manufacturer.
  • If you integrate third-party software into your own product and market it as a single solution, you are the manufacturer.
  • If you modify a product in a way that affects its cybersecurity, you may also qualify as the manufacturer.

Your qualification as manufacturer is therefore decisive in determining which obligations under the CRA apply to you.

6. How does the CRA differ from NIS2?

The CRA and the NIS2 Directive are often mentioned together, but they regulate different aspects of cybersecurity.

  • The NIS2 Directive focuses on organisations.

It requires medium-sized and large organisations in certain sectors to implement cybersecurity governance, risk management and incident reporting.

  • The CRA focuses on products.

It requires products themselves to be secure before they are placed on the market.

The CRA and NIS2 complement each other. Both frameworks place strong emphasis on supply chain security. Cybersecurity risks can propagate throughout the supply chain, and a vulnerability in one component can affect thousands of downstream products.

7. What is the impact of the CRA on your contracts?

Until now, cybersecurity clauses were often broadly or risk-based formulated. Terms such as “appropriate security measures” or “industry-standard security” were common. Under the CRA, such clauses may no longer suffice.

Manufacturers must, for example:

  • identify and remedy vulnerabilities
  • provide security updates throughout the product lifecycle
  • monitor the cybersecurity of their products
  • report vulnerabilities and incidents
  • ensure the cybersecurity of integrated components

Although the CRA does not explicitly require manufacturers to amend their contracts, the CRA obligations indirectly affect both supplier agreements (upstream) and customer contracts (downstream). Organisations should therefore review existing contracts and align new contracts with the CRA.

Without contractual arrangements with suppliers, a manufacturer may not be able to comply with the CRA, for example if a supplier refuses to cooperate or charges additional fees for its cooperation. The CRA may not apply directly to the supplier, meaning contractual agreements are often the primary mechanism ensuring supplier support in achieving CRA compliance (e.g. in relation to vulnerability remediation, see next question).

In a separate blog post, we further elaborate on the specific contractual clauses that deserve particular attention in light of the CRA.

8. What if the product integrates third-party software?

Modern products rarely consist entirely of proprietary software. They often integrate open-source components, third-party libraries and external software modules.

The CRA explicitly takes this into account. Manufacturers remain responsible for the cybersecurity of the entire product, including integrated components. The CRA requires manufacturers to apply appropriate due diligence when integrating third-party components and to address vulnerabilities without undue delay at product level.

The fact that a vulnerability originates in a third-party component does not release the manufacturer from its obligations under the CRA. Clear contractual arrangements with suppliers are therefore important to ensure effective compliance.

9. What if my product does not comply with the CRA?

If a product with digital elements does not comply with the CRA, this may have significant consequences.

Market surveillance authorities may intervene. They may require the manufacturer to bring the product into compliance. If non-conformity persists, they may restrict or prohibit the product’s availability on the market, or require it to be withdrawn or recalled.

The CRA also provides for administrative fines of up to EUR 15 million or 2.5% of the total worldwide annual turnover, whichever is higher.

In addition to sanctions, non-compliance may also result in reputational damage and loss of trust among customers and partners.

10. What should I do now to comply with the CRA?

Although the CRA will only become fully applicable in 2027, organisations should already take action, including:

  • Determine whether you qualify as manufacturer, importer or distributor under the CRA.
  • Identify which of your products fall within the scope of the CRA.
  • Analyse your supply chain and identify third-party components.
  • Clarify internal responsibilities for product security, conformity assessment, vulnerability management and incident reporting.
  • Review upstream and downstream contracts to ensure they address updates, vulnerability management and cooperation.
  • Update contract templates to ensure future agreements are CRA-compliant.

Conclusion

Cybersecurity requires attention at both organisational and product level. While NIS2 addresses the organisational dimension, the CRA addresses product-level cybersecurity, ensuring that products themselves comply with statutory cybersecurity requirements.

The CRA imposes significant obligations on manufacturers, including vulnerability management and the provision of security updates throughout the product lifecycle. It also reshapes the allocation of responsibilities within the supply chain.

Organisations should not treat the CRA as a purely technical exercise. Doing so risks overlooking its contractual implications and creating legal exposure.

Like NIS2, the CRA requires a multidisciplinary approach, involving close cooperation between legal and technical teams.

Share this:

Written by

Bernd Fiten

Bernd Fiten

Michael Thomas

Michaël Thomas

Hi! How can we help?

In need of internal privacy help or an external DPO? Reach out and we’ll look for the best solution together with you.

  • Solutions
  • Knowledge
  • Careers
  • About