Does the EU Cyber Resilience Act Apply to Your Product?

If you place hardware or software on the EU market and any part of it connects to a device or a network, start from the assumption that the Cyber Resilience Act applies and work backwards from there. Regulation (EU) 2024/2847 covers products with digital elements whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network, and Article 3 defines a product with digital elements to include its remote data processing solutions. That last clause is the one teams miss: a connected device plus the cloud backend the manufacturer built for it is one product for CRA purposes, not a product and a service.

The dates are staged rather than distant. Chapter IV applies from June 11, 2026, the Article 14 reporting duties from September 11, 2026, and the main obligations from December 11, 2027.

The scoping question is not whether you sell software or a service. It is whether anything you sell is placed on the EU market as a product. Here is how to answer that in an afternoon.

Key takeaways

• If you place hardware or software on the EU market and any part of it connects to a device or a network, start from the assumption that the CRA applies and work backwards.
• A connected device plus the cloud backend the manufacturer built for it is one product, not a product and a service. Remote data processing sits inside the product definition.
• Pure software as a service with no product component is out of scope and addressed by NIS2 instead. Ship an on-premises agent, a desktop client, a browser extension or a device and you are placing a product on the market.
• Carve-outs are product-level, not company-level. A medical device manufacturer is still in scope for a general-purpose connected accessory.
• Article 69(3) is the trap. The Article 14 reporting duties reach products already on the market, so from September 11, 2026 a product you shipped in 2023 and have not touched since is inside the reporting regime.

What counts as a product with digital elements

Article 3 defines it as a software or hardware product and its remote data processing solutions, including software or hardware components placed on the market separately. Remote data processing means data processing at a distance for which the software is designed and developed by the manufacturer, or under the manufacturer's responsibility, and whose absence would prevent the product from performing one of its functions.

Read together, that captures more than a hardware maker expects and more than a software vendor expects:

• A connected thermostat and the cloud service that stores its schedules
• A desktop application sold with a licensing and sync backend
• A firmware component sold separately to integrators
• A mobile app whose entire function depends on an API the same company operates

It also captures free software distributed in the course of a commercial activity, which is a point open-source-heavy companies underestimate. Making something available on the market is the trigger, and the European Commission's own CRA summary puts it plainly: products with digital elements that are not made available on the market, meaning not supplied in the course of a commercial activity, are not subject to the CRA.

The SaaS question, answered properly

The most common question we get is whether pure software as a service is in scope. The short answer is no, on its own. The CRA regulates products placed on the market, and a cloud service delivered with no product component is addressed by the NIS2 regime rather than by the CRA.

The longer answer is that "pure" does a lot of work in that sentence. If your service exists to support a product you also sell, the remote data processing definition pulls the backend into the product's scope. If you ship an on-premises agent, a desktop client, a browser extension, or a device, you are placing a product on the market and the CRA applies to it, backend included where the backend is integral.

The scoping test worth running is mechanical. List everything a customer can install, flash, embed, or physically receive. For each item, ask whether any cloud component is required for it to perform a function. That intersection is your CRA product inventory, and it is usually shorter than the fear and longer than the hope.

What is carved out

Article 2 excludes products already governed by sectoral EU legislation that addresses the same risks, which is why the exclusions look like a list of regulated industries:

• Medical devices and in vitro diagnostic medical devices under Regulations (EU) 2017/745 and 2017/746
• Motor vehicles under Regulation (EU) 2019/2144
• Civil aviation products certified under Regulation (EU) 2018/1139
• Marine equipment within Directive 2014/90/EU
• Spare parts placed on the market to replace identical components, manufactured to the same specifications
• Products developed or modified exclusively for national security or defence purposes, or specifically designed to process classified information

Two cautions on the carve-outs. First, they are product-level, not company-level: a medical device manufacturer that also sells a general-purpose connected accessory is in scope for the accessory. Second, if you are a device manufacturer already working to FDA premarket cybersecurity requirements under Section 524B, that program is genuinely useful preparation for the CRA's vulnerability-handling requirements even where the medical-device exclusion applies to your EU product line, because the underlying artifacts overlap heavily.

Open source, and the steward regime

The CRA does not treat open source the way its early critics feared. Free and open-source software published but not marketed sits outside scope, per the Commission's summary of Recital 18, and becomes subject to the regulation when it is commercially distributed.

For the organizations that sustain open-source projects intended for commercial use, Article 24 creates a distinct and lighter role: the open-source software steward. A steward must put in place and document a cybersecurity policy fostering secure development and effective vulnerability handling, including encouraging voluntary reporting within the community, must cooperate with market surveillance authorities on reasoned request, and must comply with the Article 14 reporting obligations to the extent it is involved in the development of the product or operates infrastructure affected by a severe incident. The Commission notes that stewards are not subject to penalties for CRA infringements.

If your business model is commercial support around an open-source core that you also steward, you may hold both roles at once, and the analysis has to be done per product rather than per company.

The dates, and the trap in the transition

The staging is:

The trap is Article 69. Paragraph 2 says products placed on the market before December 11, 2027 only have to meet the requirements where they are substantially modified after that date, which reads like a grandfather clause and is usually where people stop reading. Paragraph 3 then applies the Article 14 reporting obligations to all in-scope products placed on the market before that date, modified or not.

So the first thing that binds you is also the thing that reaches furthest back. From September 11, 2026, a product you shipped in 2023 and have not touched since is inside the reporting regime if it is in scope. Any inventory exercise that only looks forward at the roadmap is answering the wrong question.

When the CRA is not your problem

The honest boundary. If you sell nothing that a customer installs or receives, operate no device, and ship no client-side component, the CRA is not your regulation and building a CRA program is a misallocation. NIS2 may well be, depending on your sector and size, and so may sector rules like DORA if your customers are EU financial entities. Those are different projects with different artifacts.

Equally, if your only EU-bound product is a simple component with no network function, the scoping analysis is a memo rather than a program. Write the memo, keep the evidence, and move on. We would rather write you a two-page scoping opinion than sell you a readiness engagement you do not need.

Where Top Floor fits

Our EU Cyber Resilience Act practice starts where this article ends: the product inventory, the in-scope determination, the Annex III class call, and the gap assessment against the Annex I essential requirements. From there the work splits into the vulnerability-handling program, the software bill of materials, the conformity route your product class forces, and the Article 14 reporting runbook.

Where product security work needs testing behind it rather than documentation, penetration testing is the companion service, and where the EU exposure is one of several, it belongs inside a broader international compliance scope.

How to decide this week

Build the inventory. One row per thing a customer can install, flash, embed, or physically receive, including products you no longer actively sell but which are still deployed. For each, record whether a cloud component is required for it to function, whether a sectoral exclusion applies, and whether it appears in an Annex III important class.

Then draw one line across the inventory at September 11, 2026. Everything above it needs a reporting capability by that date, including the old products. Everything needs the Annex I work by December 11, 2027 or on its next substantial modification, whichever comes first.

Frequently asked questions

Does the Cyber Resilience Act apply to SaaS?

Not to a pure cloud service delivered with no product component, which is addressed by NIS2 instead. It does apply where the service is a remote data processing solution belonging to a product you place on the market, meaning data processing at a distance designed and developed by you and required for the product to perform a function. A connected device with a companion backend is one product for CRA purposes, and the backend comes with it.

Does the CRA apply to companies outside the EU?

Yes, where they place products with digital elements on the EU market. The CRA is product-market legislation rather than establishment-based, so a US or UK manufacturer selling into the EU is a manufacturer for its purposes, with the same essential requirements, reporting duties, and conformity assessment obligations as an EU-based one. Non-EU manufacturers also need to think about the importer and distributor roles in their EU distribution chain, since those carry their own obligations.

Does the CRA cover open-source software?

Free and open-source software published but not marketed falls outside the scope. Once it is supplied in the course of a commercial activity it is in scope, and the manufacturer obligations attach to whoever places it on the market. Article 24 creates a separate, lighter role for open-source software stewards, organizations that systematically support the development of free and open-source software intended for commercial activities, with documentation, cooperation, and Article 14 reporting duties but no penalty exposure.

What happens to products we already sold?

Article 69(2) means products placed on the market before December 11, 2027 only have to meet the full requirements if they are substantially modified after that date. Article 69(3) is the exception that matters: the Article 14 reporting obligations apply to all in-scope products already on the market. From September 11, 2026 you are responsible for reporting actively exploited vulnerabilities and severe incidents in products you shipped years ago, which makes a complete deployed-product inventory the first deliverable rather than a later one.