Does the Cyber Resilience Act apply to you?

Most people meet the Cyber Resilience Act as a rumour: something about CE marking for software, sometime in 2027. Then they try to work out whether it is their problem, and the answer turns out to depend on three questions — one of which almost everyone gets wrong.

This guide is those three questions, in the order the Regulation asks them.

Question 1 — Is it a product with digital elements?

Article 3(1) defines a product with digital elements as a software or hardware product together with its remote data processing solutions. Article 2(1) adds the scope condition: the intended purpose or reasonably foreseeable use must include a direct or indirect data connection to a device or network.

Put together, three shapes are clearly in:

• Hardware containing software — devices, appliances, industrial equipment, network hardware.
• Software you ship or license — applications, firmware, SDKs, agents a customer installs.
• The remote processing those depend on — which is where it gets interesting.

That last clause is not decoration. It is what pulls cloud infrastructure into a Regulation people assume is about boxes.

Question 2 — The SaaS question, and why it is the one people get wrong

If you run a hosted service and ship nothing, the instinct is to conclude the CRA is somebody else’s problem. Sometimes that is right. Often it is not.

Article 3(2) defines remote data processing as processing at a distance which the manufacturer designs and develops, or is responsible for, and “the absence of which would prevent the product with digital elements from performing one of its functions”.

So the test is not “do we run a cloud service”. It is:

Would a shipped product lose one of its functions without your service?

Recital 12 gives the Regulation’s own worked example: a smart-home manufacturer’s cloud, the one that lets users control the device remotely, is in scope. The device does not do its job without it.

And the other side of the line is drawn just as explicitly. A website that does not support a shipped product’s functionality is out. A cloud service developed outside a manufacturer’s responsibility is out. Those sit in NIS2 territory instead, which is a different regime with different duties.

Your situation	CRA
Device or installed app calls your backend to do its job	In scope — you are the remote data processing half of a product
Hosted service is the entire product; nothing is shipped	Out of CRA; look at NIS2
Website marketing a product	Out
Cloud service someone else’s product happens to call, built outside their responsibility	Out

If you are a SaaS company that also ships an agent, a desktop client, a mobile app or firmware, this question is worth answering carefully rather than quickly.

Question 3 — Is it commercial?

Article 2(1) applies the Regulation to products made available on the market, and Article 3 defines that as supply in the course of a commercial activity “whether in return for payment or free of charge”.

Charging is not the test. Giving the product away is not, by itself, a way out. Selling, licensing, paid support, a paid hosted tier, or supply in a business context all count.

Genuinely non-commercial open source is treated differently — Article 24 creates a lighter regime for open-source software stewards, organisations that support the sustained development of open source used in commercial products. That is a real carve-out, not a loophole, and it comes with its own obligations rather than none.

Then: which role are you?

Scope is not the end of it. What you owe depends sharply on what you are, and the Regulation gives each role its own article:

Role	Article	What it means
Manufacturer	13	You develop the product, or have it developed, and market it under your name. The full set of obligations.
Importer	19	You bring a non-EU manufacturer’s product onto the EU market. Narrower, but real.
Distributor	20	You make someone else’s product available without changing it. Narrower again.
Open-source steward	24	You support sustained development of open source used commercially. A lighter regime.

A manufacturer carries essential requirements, technical documentation, conformity assessment, CE marking, vulnerability handling and reporting. An importer or distributor mostly carries duties of verification and of not making things worse — checking the CE marking is there, not placing a product they know to be non-compliant, cooperating with authorities.

One trap worth naming: modifying someone else’s product substantially can make you its manufacturer. Rebranding it certainly can.

What is carved out entirely

The CRA does not apply where sector-specific cybersecurity rules already do:

• Medical devices — MDR and IVDR (Regulations 2017/745 and 2017/746)
• Civil aviation — Regulation 2018/1139
• Motor vehicles — already covered by UN R155/R156
• Marine equipment — Directive 2014/90

These are genuine exclusions, not deferrals. If your product is a medical device, its cybersecurity obligations live in the MDR, not here.

If the answer is “I am not sure”

That is the honest answer for a lot of products, and it usually comes down to Question 2. Two things help:

Write down what the product actually is. Not the marketing description — the technical one. What is installed on whose machine, what talks to what, and what stops working if your infrastructure goes away. Most scope arguments dissolve once that is on paper.

Answer it before September 2026, not before December 2027. The full Regulation — essential requirements, CE marking, conformity assessment — applies from 11 December 2027. But the reporting obligations under Article 14 start on 11 September 2026, and they apply to manufacturers of products in scope. If you are in scope and do not know it, the first deadline arrives more than a year before the one everybody is planning for.

That gap between the two dates is the single most common planning mistake we see, and it is the subject of its own guide.