Cyber Resilience Act: the fine line between SaaS and digital products

Conceptually, you think of IoT devices, but the CRA has a far broader scope of application. In this article we examine one of the tricky nuances – distinguishing between a digital product and SaaS under the CRA.

The EU’s Cyber Resilience Act (CRA) looks to reshape product cybersecurity by imposing uniform baseline requirements on “products with digital elements” placed on the EU market. The CRA forms part of the EU’s wider Digital Decade architecture, which includes other cyber security laws such as NIS2 and DORA. One of the key scoping assessments for technology providers/users is the treatment of software delivered as a product, versus software delivered as a service (SaaS). In broad terms, the CRA targets hardware and software made available as products, including embedded and on‑premise software. Pure cloud‑native SaaS is generally excluded unless it is part of, or necessary for, the product’s core functionality. This distinction drives design choices, go‑to‑market models, contractual allocations and compliance strategies.

The Cyber Resilience Act at a glance

The CRA introduces essential cybersecurity requirements for products with digital elements throughout their lifecycle. The CRA aims to reduce products vulnerabilities, ensure manufacturers remain responsible throughout the product lifecycle, improve transparency, and strengthen cybersecurity standards. Manufacturers must implement the familiar-sounding secure‑by‑design and secure‑by‑default development processes, conduct risk assessments; maintain technical documentation; perform conformity assessments and, if approved, affix CE markings. There are requirements on vulnerability handling and incident reporting. Further, manufacturers should determine a product support period and clearly set out the end of that period. Importers and distributors assume due‑diligence and reporting obligations as part of their roles. Critical products face stricter assessment, including the involvement of regulatory bodies and other EU agencies. Enforcement powers, in the event of failings, include market surveillance, corrective measures and penalties.

The CRA entered into force on 10 December 2024 and applies, in full, from 11 December 2027. Transitional periods apply, with rules for managing and reporting vulnerabilities handling obligations coming into effect on the 11 September 2026.

The CRA’s centre of gravity is “products with digital elements” i.e. hardware or software products with a direct or indirect data connection to a device or network. The concept of ‘digital element’ and the requirement for a ‘connection’ to a device or network should be interpreted broadly. A connection can take various formats – physical or logical, direct or indirect – and a product may have multiple forms of connection simultaneously. For CRA purposes, our view is that what matters is whether the product has any such connection, rather than the specific technical mechanism involved.

Finding the line: SaaS vs SaaP(roduct)

The decisive question is not whether something is “software,” but whether it is made available as a product placed on the market (this is not limited to physical products), as opposed to a service. That framing has practical consequences for cloud‑first businesses.

At one end of the spectrum, embedded firmware, endpoint agents, operating systems, network equipment and IoT devices will ordinarily be within CRA scope. They are marketed and supplied as discrete products, typically licensed or sold, installed or embedded, and updated via supplier channels.

At the other end, pure SaaS offerings i.e., cloud‑hosted applications consumed via the internet without local installation and not presented to the market as a distinct product, are distinguishable as services rather than products. These may then be excluded from the reach of the CRA. Those services are already addressed by adjacent cyber security regimes, notably NIS2 which includes digital service providers and DORA, specifically for financial services ICT.

The challenge with this distinction is that the CRA does capture “remote data processing” within its scope when it is essential to the product’s core functions. While that does not transform every remote capability into a CRA‑regulated product, it does mean an assessment should be carried out as to whether the remote component is part of the product itself and necessary for its intended functionality, and not an ancillary cloud feature. For example, the Commission’s FAQs outline that standalone software that can be downloaded and installed on a device, e.g. a mobile app from an app store or program downloadable from a website will be caught.¹ It could, based on other examples, be argued conversely that an online chat function to help with financial interrogation is not, as it is likely to be ancillary. Of course, legal analysis based on the facts is always required. 

The question of what is “essential” to a product lies on a complex middle ground, where scoping turns on architecture, packaging and commercial presentation. For example:

• Software “plus cloud” bundles. If a vendor supplies an endpoint agent or on‑premise component that only functions with the vendor’s back‑end, the combined system may be treated as a product with digital elements whose core functionality depends on remote processing. In this case, the on‑premise component would likely fall under the CRA, and the remote component may also be captured if it is necessary for the product to operate as intended.
• Feature‑gated SaaS reliance. Where a locally installed product functions offline but there is gate access to cloud based advanced features, CRA may apply if those features are needed for the product’s main use. Where the offline baseline is genuinely complete and the cloud features are optional add‑ons, the remote service may be considered outside the CRA’s scope. This should be carefully considered and clearly documented.
• Cloud‑delivered software that behaves like a product. Some providers “stream” applications or deliver packaged workloads into the customer environment under a subscription. If the delivered component runs in the customer’s environment and is marketed as software, it may fall within CRA scope, notwithstanding a subscription based hosted arrangement.

These considerations have strategic implications. Shifting capability from an on‑premise component to a purely remote feature may reduce CRA exposure, only to push it into the reach of other EU cyber-security rules, such as NIS2. Conversely, integrating core functionality into a product can help demonstrate CRA compliance but requires robust development practices, vulnerability disclosure processes, technical documentation and conformity assessments.

Practical implications for product strategy and compliance

For manufacturers and software publishers, the SaaS versus product boundary should ideally be a design‑stage decision, though we recognise this may be unrealistic in practice. Where legal and compliance teams are tasked with understanding the CRA’s application, a mapping exercise of the organisation’s core offerings should be performed and documented findings where assessments around CRA application are made. This position should be kept under review as regulatory guidance evolves.

Pure SaaS providers, while generally out of scope of the CRA, should not assume a free pass. Cyber security outcomes will still be required up and down the supply chain. Customers will increasingly calibrate their procurement against CRA‑like requirements, when assessing resilience. Convergence around secure‑by‑design, vulnerability handling and coordinated disclosure is likely, regardless of the formal scoping outcome.

Key takeaways for the SaaS vs product boundary

In some cases, the distinction will be clear, but with the advanced functionality of online technologies, the use of SaaS terminology may be misleading. The CRA’s scoping turns on how functionality is delivered and how the offering is placed on the market.

Lastly, the CRA should also not be assessed in isolation as it rubs shoulders with many other EU digital and product laws, such as NIS2, DORA, GDPR, the AI Act and the Data Act to name but a few. For more information on that, keep up to date here: Navigating the EU Digital Decade | DLA Piper

For any questions relating to the CRA or other digital and data laws, reach out to the authors: Linzi Penman, Ryan Wheatley, Shervin Nahid, and Lorcan Burke.

¹We have considered the CRA FAQs released at the end of last year and updated this year (available here), and the concept of remote data processing is expected to form part of separate guidance from the Commission.