The label SaaS is not the legal test. Pure browser-delivered services, software products distributed to users, manufacturer-controlled remote backends and third-party SaaS dependencies can occupy different CRA positions. NIS2 can also apply separately to qualifying cloud service providers.
Do Not Use SaaS as a Blanket CRA Exemption
The CRA does not contain a simple rule that everything marketed as SaaS is exempt. Scope depends on what software is actually supplied, whether another product with digital elements exists and whether cloud functionality qualifies as remote data processing. A SaaS company can therefore need more than one analysis where it offers browser software, downloadable agents, mobile applications, APIs or on-premises components under the same commercial brand.
- Analyse the actual software offering.
- Identify anything downloaded or installed.
- Identify connected products using the service.
- Do not classify from marketing terminology alone.
Browser-Only Web Applications Are Typically Not Products With Digital Elements by Themselves
The Commission's 2026 guidance explains that web applications, including progressive web applications, accessed exclusively through a web browser are typically not themselves products with digital elements merely as web-delivered services. Where such a web application is relevant to the CRA, the analysis commonly arises through the remote data processing concept in relation to another product with digital elements rather than by automatically treating the website itself as a separately placed software product.
- Browser-only delivery matters to the analysis.
- Web applications are not automatically software products placed on the market.
- Remote data processing can still make web functionality relevant.
- Assess the complete product architecture.
A Downloadable or Installable Client Changes the Facts
A SaaS business can also distribute a desktop client, mobile application, browser extension, agent, command-line tool or other installable software. That software may itself require CRA product-scope analysis because it is supplied as software rather than existing only as a browser service. If that software then depends on manufacturer-controlled remote processing for one of its functions, the associated backend can require Article 3(2) analysis as RDPS.
- Identify downloaded clients.
- Identify mobile applications.
- Identify agents and extensions.
- Assess the distributed software separately.
- Then analyse its remote dependencies.
SaaS Can Enter the CRA Product Boundary as Remote Data Processing
Cloud functionality can be inside the CRA product boundary when it is not truly standalone in the legal analysis but instead performs remote data processing for another product with digital elements. The manufacturer-controlled software must satisfy Article 3(2), including responsibility for design and development and functional dependency. A subscription model or browser-accessible administration interface does not prevent backend software from being RDPS where those statutory conditions are met.
- Look for another product with digital elements.
- Apply the Article 3(2) responsibility test.
- Apply the product-function dependency test.
- Do not let subscription billing determine scope.
Third-Party SaaS Usually Fails the Manufacturer-Responsibility Limb of RDPS
The Commission guidance provides a specific third-party SaaS model. The SaaS provider supplies a fully developed application while the product manufacturer has only limited user-specific configuration control. In that situation the application is not designed and developed by the manufacturer or under its responsibility, so it does not qualify as that manufacturer's RDPS even if the product depends on it for a function.
A Third-Party SaaS Dependency Can Still Be Security Relevant
Failure to qualify as RDPS does not make a third-party SaaS integration invisible to the CRA risk process. The Commission guidance says third-party remote solutions integrated into a product in a manner affecting security should be considered similarly to third-party components. Manufacturers should assess the associated risks, mitigate them through product-level measures and exercise proportionate due diligence regarding the provider.
- Out of RDPS does not mean irrelevant.
- Assess security impact on the product.
- Apply product-level mitigations.
- Perform provider due diligence.
The Commission e-Reader Example Shows the Difference
The 2026 guidance describes e-Reader software that depends on a third-party SaaS storage service so users can access purchased books. The storage service is functionally necessary but was not designed or developed under the e-Reader manufacturer's responsibility. It therefore does not qualify as RDPS. The manufacturer must nevertheless consider the service in its cybersecurity risk assessment, implement appropriate controls and exercise due diligence when selecting and integrating the provider.
- Functional dependency alone is not enough.
- Manufacturer responsibility is also required.
- Third-party SaaS can still affect product cybersecurity.
- Risk mitigation remains necessary.
SaaS, PaaS and IaaS Have Different Manufacturer-Control Patterns
The Commission guidance uses common cloud service models to illustrate the manufacturer-responsibility question. With IaaS, manufacturers can deploy their own software while the provider controls underlying infrastructure. With PaaS, the manufacturer can deploy its own application using provider execution environments. With third-party SaaS, the provider generally supplies the complete application. These differences help determine which software layer can potentially be RDPS.
- IaaS often leaves application software under manufacturer control.
- PaaS can also leave the application under manufacturer control.
- Third-party SaaS generally places application development with the provider.
- Always apply the complete Article 3(2) test.
Standalone SaaS and NIS2 Should Be Analysed Separately
Recital 12 points to the NIS2 framework for cloud computing services and common cloud service models. That does not mean every SaaS provider is automatically a regulated NIS2 entity, because NIS2 has its own entity, size and jurisdictional rules. It does mean CRA product scope and NIS2 service-provider scope should not be merged. A browser SaaS offering can require NIS2 analysis even where it is not itself a CRA product with digital elements.
- CRA is product-focused.
- NIS2 is entity and service focused.
- Check NIS2 scope independently.
- Do not infer one framework from the other.
A Single Vendor Can Have Both SaaS and CRA Product Obligations
A company can operate browser SaaS while also supplying downloadable software or connected devices. In that situation, the business should not assign one CRA status to the company as a whole. Instead, identify each product and service. The installed software may be a product with digital elements, the browser service may support it as RDPS, and other standalone SaaS modules may sit outside the CRA product boundary while remaining relevant under NIS2 or another regime.
- Analyse offerings separately.
- Map software distribution channels.
- Identify remote dependencies.
- Maintain separate CRA and NIS2 scope records.
SaaS Scope Can Change When the Product Model Changes
A browser-only service can later add a desktop agent, mobile application, local connector, browser extension or customer-deployed component. A SaaS platform can also become an essential backend for a newly launched connected device. These changes can alter the CRA analysis. Product teams should therefore trigger scope review when new installable software or connected-product relationships are introduced.
- Review new downloadable clients.
- Review new device integrations.
- Review new mandatory cloud dependencies.
- Review responsibility for new backend software.
Use a SaaS Offering Matrix Instead of One Company-Level Answer
A SaaS provider should maintain an offering matrix listing browser applications, downloadable clients, APIs, mobile applications, agents, SDKs, customer-hosted software and connected-product integrations. For each item, record whether software is placed on the market, whether it supports another product, whether it qualifies as RDPS and whether third-party cloud services create relevant cybersecurity risks. This produces a more reliable CRA position than a single statement that the business is or is not a SaaS company.
- List each software and service offering.
- Identify delivery model.
- Identify connected products.
- Apply Article 3(2) where relevant.
- Record third-party dependencies.
- Assess NIS2 separately.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.