Does the Cyber Resilience Act apply to my software?
A scope test for the EU Cyber Resilience Act: who counts as a manufacturer, what falls outside, and why shipping an agent pulls a SaaS company back in.
The Cyber Resilience Act is written for products, not for companies. That single fact decides most of the question. If what you sell reaches a customer in the EU as software they run, or as a device with software inside it, you are probably in scope. If what you sell is a service they log into, you probably are not.
The short test
- Does the thing you sell get placed on the market in the EU? Downloadable software, firmware, a physical device, a plugin, a library sold commercially: all count.
- Does it have digital elements, meaning software or firmware that can be updated separately from the hardware?
- Is it placed on the market rather than operated by you on your own servers?
Three yeses and the Regulation applies to you as a manufacturer, wherever your company is registered. A no on the third question is the one that saves most SaaS companies, and it is also the one people get wrong.
Who counts as a manufacturer
Being established outside the EU changes nothing. A US company selling a desktop agent to European customers is a manufacturer under the Regulation exactly as a German one is. What changes is that the obligations travel through your importer and distributor as well, which means your resellers will start asking you for documents you do not have yet.
What sits outside
| Category | Status | Why it matters to you |
|---|---|---|
| Standalone SaaS | Outside | Nothing to place on the market. The customer never receives software. |
| SaaS that ships an agent, plugin or CLI | The shipped part is inside | The agent is a product with digital elements even when the service around it is not. |
| Non-commercial open source | Outside | Maintainers acting outside a commercial activity carry no manufacturer obligations. |
| Commercial open source stewardship | Lighter regime | A separate, reduced set of obligations rather than a full exemption. |
| Medical devices, aviation, cars | Own regimes | Sector legislation applies instead of the CRA. |
The case that trips people up
A hosted service is outside the scope until it hands the customer something to install. Monitoring products ship agents. Payment products ship SDKs. Analytics products ship snippets that are really libraries. Design tools ship desktop apps. In each case the hosted half stays outside and the shipped half does not, and the shipped half is usually the part with the longest dependency tree and the least attention.
The reverse trap exists too. Remote data processing that is integral to a product, where the product cannot perform its function without it, is pulled into the scope with the product. A connected doorbell whose servers you switch off stops being a doorbell, and the Regulation treats that backend as part of the product rather than as a separate service.
Open source
The line is commercial activity, not the licence. Publishing a library under Apache 2.0 and taking donations is not the same as selling support contracts for it. If you monetise a project, read the open source steward provisions rather than assuming either extreme.
What to do with the answer
- List every artefact a customer can install: installers, firmware images, plugins, container images, SDKs, CLI tools.
- Mark each one in scope or out of scope, and write down the reason next to it. The reason is what an auditor asks for, not the verdict.
- For anything in scope, find out which third-party components it carries. That inventory is the input to everything else the Regulation asks of you.
- Keep the list. Scope decisions are revisited every time you ship something new, and a decision without a written reason gets re-argued from scratch.
The Regulation itself is Regulation (EU) 2024/2847, published in the Official Journal and freely readable. When a summary and the text disagree, the text wins.