Does the CRA apply to SaaS?

What does the legal scope test ask?

Articles 2 and 3 of Regulation (EU) 2024/2847 define the starting point: products with digital elements made available on the market whose intended or reasonably foreseeable use includes a direct or indirect connection to a device or network. The product definition covers software, hardware, their remote data processing solutions, and components placed on the market separately. Check applicable exclusions and sector-specific rules before reaching a conclusion.

Recitals 11 and 12 explain the distinction between integrated remote processing and standalone services. They help interpret the operative provisions; they are not a separate checklist that overrides them. An ordinary website that does not support a product function and a backend required by a distributed product are different cases. Avoid converting that distinction into a claim that every web application is exempt or every API is covered.

When does a backend belong to the product?

Article 3(2) asks whether the remote-processing software was designed and developed by the manufacturer, or under its responsibility, and whether its absence would prevent the product from performing one of its functions. The test is not whether the whole product becomes completely unusable. Identify the function and explain the dependency.

Start from a user action and trace the path: client, authentication, API, database or processing service, and returned result. Record who is responsible for each part. Outsourcing development does not necessarily remove manufacturer responsibility, while buying generic cloud infrastructure does not automatically turn the provider's whole platform into your product. Describe the boundary and retain the architecture evidence behind it.

Three examples to work through

These are illustrative applications of the legal test, not determinations about a particular business. In each case, the commercial supply facts, intended functions and exclusions still need review.

A browser-only scheduling service with no separate supplied client or connected product calls for analysis of the service itself and how the software is supplied. Do not invent an in-scope hardware product just because customers use laptops. Equally, do not stop at the phrase browser-only if the offering actually distributes software components with their own functions.

A downloaded desktop application that requires a manufacturer-operated API to synchronise customer files has both a supplied software product and a concrete remote-function dependency to assess. Record the application versions, synchronisation function, API responsibility and consequences of losing the backend. A subscription payment model does not erase the downloaded product.

A hosted monitoring platform with an agent installed on customer servers needs a separate description of the agent and its remote functions. The agent's privileges, update channel and network behaviour matter. If security monitoring is core functionality, scope review must be followed by a separate classification review; calling it a SaaS add-on does not choose a CRA class.

Build a product-boundary record

Use the following as a suggested evidence record. It is not a prescribed CRA form. Its purpose is to let another person reconstruct the conclusion without relying on what the team happened to remember during a meeting.

• Product and supplier: commercial name, responsible legal entity, version and EU supply model.
• Delivered software: installers, mobile apps, agents, extensions, packages or customer-hosted images, with release identifiers.
• Functions and connections: intended use, foreseeable use and direct or indirect device/network connections.
• Remote processing: function supported, service responsibility and what stops working if it is absent.
• Legal basis: provisions considered, exclusions evaluated, unresolved facts and links to supporting evidence.
• Decision: conclusion, rationale, responsible reviewer, date and changes that require reassessment.

What changes after the scope decision?

For an in-scope product, move to classification, product-specific risk assessment, support planning and release evidence. Those are separate questions: being in scope does not imply an important category, and a default category does not imply that no work is required.

If the conclusion excludes a standalone service, retain the reasoning and identify the changes that would reopen it. Adding an on-premise edition, browser extension or device integration can change the facts. Keep other legal analyses separate: a CRA scope conclusion does not determine NIS2, data-protection or contractual security duties. Do not label a company exempt when the conclusion only concerns one offering.

How evidence software can help

ConformOps can organise product facts and release-linked evidence for an assessment, but the manufacturer must decide the legal boundary. A repository cannot establish the complete commercial supply arrangement or whether a backend contract places development under your responsibility. Capture those facts alongside the engineering artifacts.

Before importing source, write down the product under review and the evidence needed to explain it. Then use the readiness checklist for the wider work. Keeping the scope record linked to the assessed version helps prevent a later feature release from silently inheriting an outdated conclusion.