Does the Cyber Resilience Act Apply to SaaS?

Who this is relevant to

Manufacturers, developers, importers, distributors and other economic operators involved with products that have digital elements and are placed or made available on the EU market.

It is also useful for technology teams whose hardware, connected product or software component is entering an EU sales, distribution or procurement chain and who need to establish which facts are still unknown, including SaaS and cloud teams asking whether their web app, downloadable client, agent or backend brings them into that same product test.

• —Hardware and connected-product businesses with embedded software
• —Software distributed as part of a product with digital elements
• —SaaS and cloud teams with a downloadable client, agent or companion app
• —Importers or distributors handling an EU-market product
• —Teams preparing vulnerability, update and product-security evidence

What the Cyber Resilience Act covers

The CRA establishes cybersecurity requirements for products with digital elements across their lifecycle. The relevant object is the product and its economic-operator chain, not an abstract claim that all software is regulated in the same way.

Market placement or making the product available in the EU is a central fact to establish. The answer should come from the product's commercial and distribution facts, not from the company's headquarters country or from a generic assumption that an EU customer is involved.

The obligations and evidence that matter can depend on the role in the chain, the product, its support period, vulnerability handling and update process, and any applicable product classification or conformity route.

Direct product obligations vs customer requirements

Where the CRA applies to a product and role, the relevant economic operator needs to assess its own obligations. Separately, an EU customer or channel partner may ask for security information, vulnerability processes, update commitments or product documentation as part of procurement and supply-chain review.

A customer request can be commercially important without converting every supplier into a direct CRA addressee. Keep the statutory scope question separate from the evidence a buyer wants to see.

• —Direct: determined from the product, EU market availability and economic-operator facts
• —Customer-driven: security, documentation or update evidence requested in a commercial relationship
• —Possible: a missing product or role fact needs verification before a conclusion is safe

Typical readiness areas

The evidence a team needs depends on its product and role. Start by making the product boundary and the EU-market route explicit, then assemble the records that show how security is managed over the product lifecycle.

• —Product inventory and a clear description of the digital elements involved
• —Economic-operator role, distribution chain and EU-market placement evidence
• —Vulnerability intake, triage, remediation and disclosure processes
• —Security-by-design decisions and technical documentation
• —Support period, update process and records of security updates
• —Incident and vulnerability records that can be shared with the relevant party
• —A named owner for product-security evidence and customer questions

Common misconceptions

“The CRA applies to every SaaS service.”

The CRA concerns products with digital elements within its scope. A standalone service is not automatically the same thing as a product covered by the Act; establish the product and distribution facts first.

“We are outside the EU, so the CRA cannot matter to us.”

Company location alone does not answer the question. The product's EU-market placement or availability and the economic-operator role are central facts.

“Any cloud backend connected to a product is automatically covered.”

The CRA's remote-data-processing test is narrower than 'the product calls an API.' The backend has to be designed and developed by, or under the responsibility of, the manufacturer, and the product has to be unable to perform one of its functions without it. A third-party or general-purpose dependency is a different question.

“If our software is downloadable, the CRA definitely applies.”

Being installable makes the product-with-digital-elements question more likely to matter, but it does not settle scope by itself. Market placement, the actual product boundary and the economic-operator role still need to be established.

“The CRA, NIS2 and the AI Act are one combined cybersecurity rulebook.”

They are separate instruments with different objects, roles and scope questions. A product can raise more than one question, but one regulation must not be used as proof that another applies.

“A customer questionnaire proves that the CRA applies directly to us.”

A questionnaire may reflect a buyer's procurement or supply-chain needs. It does not by itself determine the product's legal scope or the operator's role.

Practical checklist

1. 01List the products and software components that may be products with digital elements
2. 02Document whether and how each product is placed or made available on the EU market
3. 03Note what customers actually receive: a hosted service, downloadable software, or both
4. 04Identify your role in the economic-operator chain and the roles of relevant partners
5. 05Establish whether any remote or cloud backend is functionally required and who designed it
6. 06Map vulnerability reporting, remediation, disclosure and update ownership
7. 07Keep product-security and technical documentation in a maintained location
8. 08Record the support period and how security updates are released and evidenced
9. 09Separate direct CRA questions from customer procurement requests
10. 10Mark unresolved product, role and market-placement facts for verification rather than guessing

What RegRoute can and cannot determine

RegRoute can organize the product, EU activity, customer and evidence facts that determine which CRA questions should be reviewed. It can distinguish a direct regulatory signal from a customer-driven request or a possible result where important facts remain unknown.

It does not certify a product, make a conformity assessment, or turn a zero-result assessment into a legal finding that the CRA does not apply. Product scope, role and national or technical context may still require specialist review.

Does the Cyber Resilience Act apply to SaaS?

Pure web-hosted SaaS: a browser-based product with no downloadable client and no separate hardware is not automatically the same thing as a covered product with digital elements. The CRA's own recitals treat general cloud computing services, including SaaS, PaaS and IaaS, as sitting under the separate NIS2 Directive's cloud-service categories rather than being swept into CRA product scope by default. That is a starting position, not a blanket exclusion: if the same service is also marketed as, or forms part of, a product with digital elements, the product test still has to be checked.

SaaS plus a downloadable client, agent or companion app: adding installable software changes the analysis, because a downloadable component is more plausibly placed on the market as software in its own right or as part of a broader product. It does not settle scope automatically. A desktop agent that is only a thin interface to a web service is a different case from firmware, an SDK, or software distributed to run on a customer's own infrastructure or device. What is actually distributed, installed and controlled by the company is the fact that still needs to be established.

A connected product with a cloud backend: where a physical device or a piece of software depends on the manufacturer's own backend to perform one of its functions, that backend can be part of the same covered product as a remote data processing solution. This is narrower than 'the device calls an API, so the backend is covered'. The CRA's own test requires that the backend is designed and developed by, or under the responsibility of, the manufacturer, and that the product could not perform one of its functions without it. A third-party or general-purpose cloud dependency that meets neither condition is a different question.

Remote data processing: the concept that decides SaaS/cloud scope

Remote data processing is the CRA's own term for data processing at a distance that forms part of a product with digital elements rather than a standalone service. Two conditions from the statutory definition do the real work: the software carrying out that processing must be designed and developed by the manufacturer, or under the manufacturer's responsibility, and the product must be unable to perform one of its functions without it.

Manufacturer responsibility matters because a backend a company builds and operates for its own product sits differently from a general-purpose cloud platform, database or infrastructure service the company merely uses. Functional dependency matters because a component the product can do without, such as a marketing website, an optional analytics add-on or an unrelated internal tool, is not what the definition describes, even when it happens to be cloud-hosted and reachable from the same account.

The CRA's own recitals draw this line deliberately: general cloud computing services, including SaaS, PaaS and IaaS offerings, are addressed separately under the NIS2 Directive's own cloud-service categories, not folded into CRA product scope merely because they are cloud-based. Not every cloud dependency is remote data processing, and not every remote data processing solution is a large general-purpose platform. The statutory test, not either label, decides.

Non-EU technology companies and the CRA

A company established outside the EU is not automatically outside CRA scope, and it is not automatically inside it either. The Regulation applies to products with digital elements made available on the EU market. A company that places, or has such a product placed on its behalf, on the EU market can fall within scope regardless of where it is headquartered.

'Made available on the EU market' and 'an EU customer bought our software' are not the same fact. A website being technically reachable from Europe, or one EU customer signing up for a hosted service, does not by itself establish that a product with digital elements has been placed or made available on the EU market in the sense the Regulation uses. Distribution channel, whether the company or an importer acting on its behalf markets the product into the EU, and the product/service boundary discussed above are the facts that actually decide this.

Where a non-EU company's offering does involve a product with digital elements reaching the EU market, its own role in the chain decides which obligations apply to it specifically, rather than every party carrying identical duties.

Manufacturer, importer and distributor: the role changes the obligations

The CRA does not address a single generic 'vendor' role. A manufacturer is the party that develops a product with digital elements, or has it developed, and markets it under its own name or trademark. This party carries most of the CRA's substantive obligations, including the cybersecurity risk assessment, technical documentation and vulnerability-handling duties. An importer is an EU-established party that places on the EU market a product bearing a non-EU party's name or trademark, with narrower obligations focused on verifying the manufacturer's compliance rather than repeating it. A distributor makes a product available on the EU market without affecting its properties, and carries the lightest, largely verification-based obligations of the three.

A company can hold more than one of these roles for different products, and a company that only provides a service, with no product with digital elements placed under its own name, may find that none of the three describes it at all. That is itself a fact worth recording rather than defaulting to 'manufacturer' or assuming coverage either way.

Scenario table: is my offering a CRA-relevant product?

A starting map, not a conclusion. Every row still depends on the product, distribution and role facts described above. Read the middle column as what to check next, not a verdict.

Key CRA application dates

Regulation (EU) 2024/2847 entered into force on 10 December 2024. Article 14 vulnerability and incident reporting obligations apply from 11 September 2026. For a company that confirms it has a covered product, this is the first substantive deadline, well ahead of general application. The Regulation's general application date, covering the remaining essential requirements, is 11 December 2027.

• —Entry into force: 10 December 2024
• —Article 14 reporting obligations: 11 September 2026
• —General application: 11 December 2027

Official EU sources

Every conclusion on this page traces back to the primary legal text. We link only to official EU sources.

• Regulation (EU) 2024/2847 — Cyber Resilience Act · Read on EUR-Lex (CELEX 32024R2847)Verified 2026-08-17