Is SaaS in scope of the Cyber Resilience Act?
Usually not on its own — but the exception catches more products than teams expect. A cloud service that is not part of a product is outside this Regulation and is addressed by the NIS2 Directive instead [1] [2].
The exception is remote data processing. Where software is designed and developed by the manufacturer, and its absence would prevent the product from performing one of its functions, that remote processing is part of the product [3]. It is covered by the same essential requirements and the same technical documentation as the installed part [4].
The test, in plain terms
Ask two questions about your backend.
Did you design and develop it as part of this product [3]? A third-party service you merely call is a supplier relationship, not part of your product in this sense.
Would removing it stop the product doing something it is sold as doing [3]? Not "would it be less convenient" — would a function stop working.
If both answers are yes, the backend travels with the product into scope [4].
Applies to you if
- You ship a desktop agent, sync client, or CLI that talks to your own API [4].
- You sell a device that is inert without your cloud [4].
- You publish a mobile app whose features are implemented server-side [3].
- You offer a browser-based product with an installed companion component [5].
What is genuinely outside
A web application with no installed component, no device, and no downloadable client is not a product with digital elements [5]. Your obligations there come from elsewhere — NIS2 if you fall within its scope, and sectoral rules — not from this Regulation [2].
That distinction is worth getting right rather than assuming the cautious answer, because the two regimes ask for different things. This Regulation asks for product conformity: essential requirements, technical documentation, a declaration, CE marking from 11 December 2027 [6] [7]. NIS2 asks for organisational risk management and incident reporting from an entity [2].
Where teams get it wrong
The common error is architectural rather than legal. A team concludes "we are SaaS" from how they bill, when the Regulation looks at what the customer installs. If any part of your product runs on the customer's machine or on hardware you sold them, you are not purely SaaS for this purpose, and the backend that part depends on comes with it [4].
The second error is treating the backend as out of scope because it is deployed separately, versioned separately, or owned by a different team. None of that matters. Scope follows the function the customer bought, not your deployment topology [3].
What to do next
Draw the boundary explicitly and write it down: which components are the product, which are supporting infrastructure, and why. That boundary is the first thing your technical documentation has to establish, and settling it now is much cheaper than settling it during an assessment [7].
What to do next
Run your own product through the checker — it takes under a minute and gives you a dated, citable result you can send to a customer.
Sources
- Cloud services that are not part of a product are outside the Regulation (they fall under NIS2); remote data processing essential to a product is within scope as part of that product. Art. 3(1)–(2), Recitals — EUR-Lex ↩
- Cloud services may fall under NIS2 (Directive (EU) 2022/2555) rather than the CRA. NIS2 — EUR-Lex ↩
- Remote data processing means data processing at a distance for which the software is designed and developed by the manufacturer and the absence of which would prevent the product from performing one of its functions. Art. 3(2) — EUR-Lex ↩
- Where a product depends on your own remote data processing (a backend or API without which it cannot perform one of its functions), that remote processing is part of the product: it is covered by the essential requirements, the technical documentation and market surveillance alongside the client software or device. Art. 3(1)–(2), Annex I, Annex VII — EUR-Lex ↩
- A product with digital elements is a software or hardware product and its remote data processing solutions, including components placed on the market separately, whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Art. 3(1), Art. 2(1) — EUR-Lex ↩
- The Regulation applies in full from 11 December 2027. Art. 71(2) — EUR-Lex ↩
- Technical documentation (Annex VII) is drawn up before placing on the market and kept, with the EU declaration of conformity, for at least ten years after placing on the market or the support period, whichever is longer. Art. 13(13), (16), Art. 31 — EUR-Lex ↩
Related
- What is a product with digital elements under the CRA?
A software or hardware product and its remote data processing solutions, including components placed on the market separately. The phrase is broad on purpose and the remote-processing half is the part people miss.
- Does the EU Cyber Resilience Act apply to my mobile app?
Yes, in almost every case. An installed app that connects to anything is a product with digital elements, and publishing it in an EU app store makes it available on the EU market.
- What must I do by 11 December 2027?
Everything else. From full application a product placed on the EU market needs a completed technical file, an EU declaration of conformity you sign, CE marking, a stated support period and a software bill of materials.
- Does the CRA apply to free or ad-supported apps?
Charging nothing does not put you outside the Regulation. What matters is whether the product is supplied in the course of a commercial activity, and advertising, data and freemium funnels all count.
CEMarque encodes Regulation (EU) 2024/2847 and the European Commission's published guidance as of 3 September 2026 (Facts v2026.09.2). It is not legal advice. Verify obligations for your product with qualified counsel where the stakes require it.