Does the Cyber Resilience Act apply to SaaS software?

A browser-only web application is not a product with digital elements on that basis alone, but downloadable or locally installed software is, and a backend can bring a SaaS product into scope if it performs remote data processing the product needs to function. The Commission's guidance C(2026) 5252 makes both points in its section 2.2, so the answer for your product depends on what runs in the browser, what runs on the customer's side and what the backend does. If a customer or regulator asks, start by mapping those three layers rather than answering from the marketing label "SaaS." The guidance treats software that runs remotely and is only accessed by the user, such as a web application used exclusively through a browser, as outside the product definition on that basis. The same logic covers websites. Browser extensions and desktop apps built with web technologies that are downloaded or installed and run on the user's side are products with digital elements. If your offering includes a companion agent, a sync client, a desktop app or an SDK that ships to customer machines, that component needs its own scope assessment even when the core service is hosted.

Architecture also decides whether the backend itself counts. Under Article 3(2), remote data processing is processing at a distance, designed and developed by or under the responsibility of the manufacturer, without which the product could not perform one of its functions. Section 8.1.2 of the guidance lists functions that can qualify, including sending commands to a device, synchronising files, onboarding, configuration, automated update distribution and identity and access management. Check whether an authentication service issues credentials or tokens your client product needs. Telemetry used purely for statistics is not remote data processing. Internal systems such as HR, payroll, CRM, CI/CD and penetration testing tooling are not covered. The guidance also confirms that this processing can run on your own servers or private cloud, not only on a public cloud. Document each backend service, its function and the reason the product depends on it, and confirm the result with your counsel or notified body before you rely on it.

How common SaaS architectures are treated

This table compares four common SaaS setups, from browser-only applications to on-premises backends, and shows how the CRA treatment changes with each. Read each row against the first question listed, because the answer to that question usually decides whether the product or its backend is in scope.

Architecture	CRA treatment and reason	Question to answer first
Browser-only web application	Generally outside the CRA as a product with digital elements. Software that runs remotely and is only accessed through a browser is not on that basis alone a product, per Commission guidance C(2026) 5252, section 2.2.	Does the application run only in the browser, with no download or installed component on the user's side?
SaaS with a downloadable or installed client	The client is a product with digital elements. Software downloaded or installed that runs on the user's side, including browser extensions and locally installed apps built with web technologies, falls in scope.	Does the user install or download any code that runs on their own device or endpoint?
SaaS with a backend that issues updates or manages devices	The backend may be remote data processing of the product (RDPS) if the product cannot perform a function without it. Sending commands, distributing updates, configuration and identity and access management are listed RDPS functions in section 8.1.2.	Does the installed product depend on this backend to perform one of its functions, such as updates, commands or credentials?
On-premises or private cloud backend	Hosting location does not decide the question. RDPS need not run on third-party cloud, so a backend on the manufacturer's own servers or private cloud can qualify, per section 8.1.1 of the guidance.	Is the backend designed by or under the manufacturer's responsibility and required for a product function, regardless of where it runs?

When a backend becomes remote data processing for a product

A backend becomes part of the CRA scope when it is remote data processing for a product with digital elements. Article 3(2) describes this as processing at a distance, designed and developed by or under the responsibility of the manufacturer, without which the product could not perform one of its functions. Two tests follow from that wording. The first is whether the product depends on the service to do something it is meant to do. The second is whether the manufacturer controls how that service is designed. A backend that the manufacturer runs for its own staff, such as a CRM, payroll system or build pipeline, fails the first test. A backend the product calls at runtime usually passes it, whichever cloud or data center hosts it, because the Commission guidance says remote processing on the manufacturer's own servers or private cloud can qualify just as a public cloud can.

The guidance names functions where remote processing can qualify: sending commands to a device, synchronising files, onboarding the user, configuration, automated distribution of updates, and identity and access management. For each backend service, write down the product function it serves and what breaks if that service is unavailable. For example, if the desktop client cannot sign in without a token from your service, the authentication endpoint serves a product function. An authentication portal that issues credentials or tokens the product needs to operate is RDPS. A website that only explains the product is not, and neither is telemetry analysed purely for statistics or future development. Telemetry that the product needs for a function, such as a licence check that gates features, should be treated as a function, not as analytics. Confirm each classification with your legal and product owners and record the reasoning, because an assessor will ask for it.

Which parts of a SaaS company's infrastructure stay outside the CRA

The Commission guidance draws a line between the remote processing that makes a product work and the wider IT estate a manufacturer runs to build, sell and secure it. The cards below cover the components the guidance places outside remote data processing, and what to document so the boundary holds up if a market surveillance authority asks.

Internal HR and payroll systems

Human resources, payroll and similar back-office platforms hold employee records rather than processing anything the product needs to function. The guidance treats them as outside remote data processing solutions, and the CRA does not cover a manufacturer's whole IT infrastructure. Check that these systems share no service, database or identity path with the product's runtime. If a payroll integration issues tokens or configuration the product uses, the boundary moves, so document the data flows that prove separation.

Customer relationship management

A CRM holds sales and account data about customers and prospects, and it does not run the product's functions for the end user. The guidance lists CRM systems among the internal systems outside the regulation. The risk to review is data leaving the CRM and feeding the product, such as account status or entitlements that gate features. Where that feed exists, the sync path needs its own assessment, and the reader should record which fields cross the boundary.

CI/CD pipelines

Build and release pipelines compile code, run tests and package artifacts, which places them in the manufacturer's development environment rather than in the product's operation. The guidance excludes CI/CD systems from remote data processing. The boundary weakens when the pipeline pushes signed updates directly to devices or to the update service, because that delivery step serves the product. Document which pipeline stages touch production signing keys and which artifacts the product consumes.

Edge distribution of updates

Content delivery networks and edge caches that serve update packages to devices sit outside remote data processing, according to the guidance. The distinction matters because automated distribution of updates is itself a listed RDPS function when the manufacturer's backend decides what is delivered and to whom. Confirm that the edge layer only caches and forwards artifacts, and that targeting, version selection and entitlement checks remain in the backend that is in scope.

Penetration testing and red team systems

Tools, infrastructure and test environments used for penetration testing, threat hunting and red teaming are excluded by the guidance. These systems exist to examine the product, not to make it work for users. The reader should still document that testing platforms are isolated from production credentials and customer data, and that any findings flow into the vulnerability handling process. Keep records of test scope, tool ownership and access, since an assessor may ask how the exclusion was applied.

Security operations and monitoring tooling

Internal security monitoring that watches the corporate estate, such as an enterprise SIEM collecting endpoint and office logs, serves the company's own defense rather than the product's operation. Whether a given monitoring stack counts depends on whether it processes data the product needs, such as device telemetry used to deliver its functions. Write down which log sources feed which platform, and state where product telemetry is used only for statistics or future development, which the guidance does not treat as RDPS.

On-premises backends and what the CRA leaves to NIS 2

A backend does not have to sit in a public cloud to count as remote data processing. The Commission guidance (C(2026) 5252, section 8.1.1) states that remote processing on the manufacturer's own servers or in a private cloud can qualify just as a public cloud solution can. For a SaaS vendor that runs its product's command, update distribution, identity or configuration services in its own data center, the question is therefore not where the servers are but whether the processing is designed by or under the manufacturer's responsibility and whether the product could not perform one of its functions without it. If the answer is yes, the service sits inside the CRA's scope as part of the product, and the team should map each such function, including any authentication portal that issues tokens the product needs, to the product's technical file and vulnerability handling process.

The guidance also recalls, citing recital 12, that cloud computing services fall under the NIS 2 Directive. Risk-management requirements for cloud providers are specified in Implementing Regulation (EU) 2024/2690. The practical split is that the CRA governs the product and its remote data processing services, including their vulnerabilities and support period, while NIS 2 governs the operations of a service provider that is itself an in-scope entity, such as its incident handling, supply chain security and governance. A company can therefore face both regimes for the same platform, but the obligations attach to different things. Vendors should not assume that a NIS 2 program covers CRA duties, or the reverse.

Whether NIS 2 applies to your organization depends on its sector, size and the national law that transposes the directive, and the answer should come from your national competent authority or qualified counsel rather than from a product-level analysis. Ask that adviser to confirm your entity classification and the cloud or digital service category that applies to you, then record the answer next to your CRA scope decision. DeployOpen can prepare the system inventory, architecture documentation and evidence that feed both assessments, but it does not determine legal status under either regime.

Who decides the scope and who checks it

Your product and engineering team owns the facts that decide the scope. Only people who build the system can say which backend functions the product depends on to perform its functions, where processing happens, and who designed and runs each component. The CRA question turns on whether a backend is remote data processing designed and developed by or under your responsibility, without which the product could not perform one of its functions. Engineering therefore produces the function map and the boundary description that every later decision relies on. Outsourcing usually covers architecture reviews, dependency mapping and drafting the boundary document, while your own engineers confirm each statement against the running system.

Function map: list each backend service and the product function it supports, such as command dispatch, file synchronisation, onboarding, configuration, update distribution or identity and access management.
Telemetry separation: identify analytics pipelines used only for statistics or future development, and keep them apart from functional services.
Hosting model: record whether each service runs on public cloud, your own servers or a private cloud, since the guidance does not require third-party cloud.
Internal systems: document HR, payroll, CRM, CI/CD and security tooling that the CRA does not reach, with the reasons.
Change control: assign an owner to re-check the boundary whenever a function moves.

Confirm that the boundary document matches the architecture as deployed, not as designed.

How to run a scope assessment for a SaaS product

This sequence tests whether each part of a SaaS product is software with digital elements, whether a backend counts as remote data processing, and which parts fall outside the regulation. It ends with a dated scope decision that your team can defend and revisit when the architecture changes.

Inventory every client and backend component
Start by listing everything your customers run and everything your platform runs for them: browser front ends, downloadable desktop or mobile clients, agents, SDKs, command-line tools and each backend service they depend on. Include the hosting model for each backend, whether public cloud, your own servers or a private cloud. Engineering owns the list, and product management confirms that it matches what customers actually install. The output is an architecture inventory that names every component, its owner and where it runs.
Classify each component by how it runs
For each entry in the inventory, decide whether it is browser-only software that runs remotely and is accessed only by the user, software downloaded or installed and run on the user's side, or a backend service. Commission guidance treats downloaded and installed software, including locally installed desktop apps built with web technologies, as a product with digital elements. Browser-only web applications and websites are not on that basis alone. Record the classification and the evidence behind it, such as a packaging artifact or an installer. The output is a classified inventory with a short justification per row.
Map backend functions to product functions
For every backend service, list what it does for the product and whether the product could still perform each function without it. Describe functions in the terms the guidance uses, such as sending commands to a device, synchronizing files, onboarding users, configuration, distributing updates and identity and access management. Keep the product function and the backend function side by side so that a reviewer can see the dependency. The output is a function-to-service map that shows where the product depends on remote processing.
Apply the RDPS test and its exclusions
Test each mapped backend function against the definition of remote data processing: processing at a distance, designed and developed by or under the manufacturer's responsibility, without which the product could not perform one of its functions. Then apply the exclusions. Telemetry analyzed only for statistics or future development is not RDPS, a website that merely informs users is not RDPS, and internal HR, payroll, CRM, CI/CD and security testing systems are outside the product scope. Mark each service as RDPS, not RDPS, or unresolved. Legal and security leads should review any unresolved item. The output is a test sheet with a result and a reason for each service.
Check hosting and NIS 2 boundaries
Confirm where each RDPS service runs and which regime governs the service provider. Remote processing does not need to run on a third-party cloud, so your own servers or private cloud can qualify. Cloud computing services fall under NIS 2, and the risk-management requirements for cloud providers appear in Implementing Regulation (EU) 2024/2690. Note which obligations sit with you as the product manufacturer and which sit with a cloud provider or another in-scope entity. Ask your hosting providers for their own NIS 2 position in writing. The output is a responsibility matrix that separates CRA duties from NIS 2 duties for each RDPS service.
Record the decision in a signed scope memo
Write a scope memo that lists each component, its classification, its RDPS result, the reasons and the people who approved the decision. Include the regulation article or guidance section relied on for each exclusion, and mark any item that depends on a fact you still need to confirm. Have an accountable executive sign the memo, and store it with the architecture inventory and test sheet. The output is a signed scope memo that an auditor, customer or market surveillance authority can read without your team in the room.
Set triggers for reviewing the scope
Define the events that reopen the assessment, such as a new backend service, a change in the functions a backend performs, a move between hosting models, a new client platform or a change in how the product is distributed. Assign an owner for watching these triggers, usually the product or architecture lead working with compliance. Check the Commission's guidance and the regulation's application dates when your next review happens, because the interpretation can change. The output is a review procedure with named triggers and an owner, linked to the signed scope memo.

Questions buyers ask about CRA scope for SaaS

Is a pure web application covered by the Cyber Resilience Act?

A web application that runs remotely and is only accessed through a browser is not, on that basis alone, a product with digital elements under the Commission's guidance (C(2026) 5252). The picture changes when software is downloaded or installed and runs on the user's side, including browser extensions and locally installed desktop apps built with web technologies. Scope therefore depends on how the software is delivered and run, not on the programming technology used. Confirm the delivery model of each component with your legal or compliance lead before you assume the answer for the whole product.

Does a cloud backend alone bring a product into scope?

Not automatically. The backend matters when it is remote data processing (RDPS), meaning processing at a distance, designed and developed by or under the responsibility of the manufacturer, without which the product could not perform one of its functions (Article 3(2)). The guidance lists functions that can qualify, including sending commands to a device, synchronising files, onboarding the user, configuration, automated distribution of updates, and identity and access management. Telemetry analysed purely for statistics or future development does not qualify. Map each backend service against that test, because a service can be in scope for one product and outside it for another.

Does a backend on our own private cloud count as remote data processing?

Yes, it can. The guidance states that RDPS need not run on a third-party cloud, so processing on the manufacturer's own servers or private cloud can qualify just as a public cloud solution can. Hosting location does not decide scope; the functional role of the service does. The same test applies to services you run in your data center or on a private cloud you operate. Document where each function runs and why it is needed for the product to work, so an assessor can follow the reasoning.

Do we need outside help to decide whether the CRA applies to our SaaS?

The organization owns the scope decision and must be able to defend it. Outside help is useful when the architecture is complex, when the same backend serves several products, or when the team needs a written record of how each service was classified. An implementation partner can map services against the RDPS functions and prepare the supporting architecture documentation. Only legal advisors and, where relevant, independent assessors give binding views or issue reports, so a partner's analysis should be treated as input to your own decision. Ask any provider to state the scope of the analysis in writing before work starts.

What does the scope work require from our internal team?

The work is mainly architectural and documentary, so it needs people who know how the system actually behaves. Engineers should provide an inventory of components, data flows, and the functions each remote service performs, including what breaks if that service is unavailable. Product owners should confirm how each component is delivered to users and who controls its releases. Compliance or legal staff should own the final classification and keep it current as the architecture changes. Ask any partner to list these inputs in the written scope so the effort is visible before the engagement starts.

Do the CRA's dates already apply to SaaS products?

Regulation (EU) 2024/2847 entered into force on 10 December 2024 and applies from 11 December 2027, with the Article 14 reporting obligations applying from 11 September 2026. Products placed on the market before 11 December 2027 fall under the regulation only if they are substantially modified from that date, but Article 14 reporting applies to all in-scope products whenever they were placed on the market. For SaaS, the practical question is whether a component counts as a product with digital elements and whether it is substantially modified after the cut-off. Confirm with counsel how your release history and planned changes interact with these dates.

Which cloud services fall under NIS 2 instead of the CRA?

The guidance says the CRA does not cover a manufacturer's whole IT infrastructure. Internal HR, payroll, CRM and CI/CD systems, edge distribution of updates, and penetration testing, threat hunting and red teaming systems are not remote data processing solutions. The guidance also recalls that cloud computing services fall under the NIS 2 Directive, whose risk-management requirements for cloud providers are specified in Implementing Regulation (EU) 2024/2690. A service can therefore sit outside the CRA as an internal system and still carry duties under NIS 2 if your organization is in scope of that directive. Map both regimes separately so neither is assumed to cover the other.

How DeployOpen prepares SaaS scope and evidence

DeployOpen starts by settling which parts of a SaaS or cloud product are products with digital elements and which parts sit outside the regulation. We then prepare the systems, documentation and evidence that support the conclusion, while the organization keeps ownership of its scope decisions and the independent assessor makes any formal determination.

How we scope

Written scope that lists each component, how it is delivered and whether it runs on the user's side or remotely.
A map of backend functions that could be remote data processing, such as command routing, update distribution and identity services.
Clear exclusion of internal systems like HR, CRM and CI/CD, recorded with the reasons for leaving them out.
Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work begins.

How we build

Hardening and configuration of self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks.
Logging, access control and update mechanisms set up to match the scope the organization has decided on.
Security testing of applications, APIs and infrastructure in the in-scope components before handover.
Integration of the chosen platforms with the client's existing identity, monitoring and deployment tooling.

How we hand over

Documentation of the architecture, scope boundaries and data flows that an assessor or regulator will ask to see.
Evidence packages that show how each in-scope control operates, organized so the client can present them without rework.
Runbooks for operating, backing up and upgrading the platforms after the engagement closes.
A list of decisions the client must still confirm with counsel, the market surveillance authority or a notified body, where relevant.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Re-review of the scope when the platform changes, such as a new backend function that may become remote data processing.
Coordination with the client's own compliance lead and external assessors, who issue any reports or certificates.
Retainer terms, response expectations and fees are set out in a written quote that follows from the agreed scope.

Does the Cyber Resilience Act apply to SaaS and cloud software?