Does the EU Cyber Resilience Act apply to SaaS?

The most common CRA question from software companies is also the one with the most misleading short answer. Yes — pure SaaS falls outside the Cyber Resilience Act. But "pure" is doing a lot of work in that sentence, and most software businesses that call themselves SaaS ship something that is very much in scope.

This guide walks the line in detail, because getting it wrong in either direction is expensive: assume you're out when you're in, and you're facing the 11 September 2026 reporting obligation unprepared; assume you're in when you're out, and you're doing compliance work you don't owe.

Want the answer for your specific product in three minutes? Run the free scope check.

Why SaaS is (mostly) out

The CRA regulates "products with digital elements" that are placed on the EU market — things that are sold or made available as a product. A cloud service that users access through a browser is not placed on the market in that sense; it is provided as a service. Services have their own regime: NIS2 covers cloud providers and other critical services, which is precisely why the CRA leaves them out.

So: a pure web application — login page, everything runs on your servers, nothing installed on the customer's side — is outside CRA scope. That covers a lot of B2B SaaS.

The five ways "SaaS" companies end up in scope anyway

1. You ship a client component. A desktop app, a mobile app, a CLI, a browser-installed agent, a sync client. The moment customers install something of yours, that something is a product with digital elements. The backend may stay out of scope; the installed component is in. Think of every SaaS with an Electron app or a mobile companion — the service is out, the apps are in.

2. You ship an agent, collector or connector. Monitoring tools, backup services, security products — the dashboard is a service, but the agent running on the customer's machines is squarely in scope. This catches most infrastructure and dev-tool companies.

3. Your cloud service is "remote data processing" for a device. The CRA explicitly pulls in remote processing that a physical product depends on to function. If you sell a sensor, camera, tracker or machine whose features live in your cloud, that cloud counts as part of the product with digital elements. You cannot carve the product into "device (in scope)" and "essential cloud brain (out of scope)" — they are assessed together.

4. You sell on-prem or self-hosted versions. The self-hosted edition of your SaaS that enterprise customers run themselves is installable software — a product, in scope. Many companies will be in scope for their on-prem tier only.

5. You ship libraries, SDKs or APIs-with-client-packages. An SDK your customers embed in their products is a product with digital elements in its own right (and your customers will start demanding your SBOM for their own compliance — supply-chain pressure arrives before the regulator does).

Quick self-test

Ask one question: does anything of ours run on hardware we don't control? If the answer is no — genuinely no installers, no agents, no apps, no embedded components, no device depending on your cloud — you are out of CRA scope. Check NIS2 instead if you serve critical sectors, and expect SBOM questions from enterprise customers regardless.

If the answer is yes, the next questions are which class that component falls into and which deadlines apply — for most software it's the default class (self-assessment, no notified body), with the reporting obligation starting 11 September 2026 and full compliance due 11 December 2027. Our deadlines guide covers what each date requires.

Edge cases worth knowing

• Free tiers of commercial products are in scope. "Commercial activity" includes free products that support a paid offering. Only genuinely non-commercial open source is exempt.
• Internal tools are out. Software you build for your own use isn't placed on the market.
• Browser extensions are installed software — in scope.
• Non-EU companies are not exempt. Scope follows the market, not your headquarters: selling into the EU puts your installable components in scope wherever you're based.
• Electron/desktop wrappers around a web app are still installed products. The wrapper is thin; the obligation is not.

What to do if you're in scope for a component

The obligations attach to the component you ship: an SBOM for it, vulnerability monitoring, the 24-hour ENISA reporting readiness, technical documentation and CE marking by December 2027. In practice the client component usually shares dependencies with your main codebase, so the work is smaller than it sounds — our compliance checklist sequences it, and the SBOM guide covers the first concrete step.

Three minutes to certainty: check whether your product is in scope — no signup, based on the regulation text.