CRA Dossier
When a Website Is a Product with Digital Elements
Cyber Resilience Act scope and EU product-liability rules for SaaS, web applications and packaged software
When does a website become a product? Under the Cyber Resilience Act (CRA), a website isn’t a product with digital elements just because it is a website. For CRA scope, the decisive questions include where the software executes, whether it is supplied to the user and whether it supports the functioning of another product with digital elements. It comes into scope in two ways. The first is when data processing at a distance is developed by or under the responsibility of a manufacturer and its absence would prevent another product with digital elements from performing one of its functions. It then forms part of that product as remote data processing. The second is when web-based code is packaged and supplied for execution on the user’s electronic information system, for example as a desktop application or browser extension. The Product Liability Directive (PLD) draws the line somewhere else. Under the PLD, software is a product regardless of how it is supplied or accessed, including through cloud technologies or a software-as-a-service (SaaS) model. Information a site carries is excluded. For software products placed on the market or put into service after 9 December 2026, under respective national transpositions of the PLD, the operator of a consumer web application can face no-fault product liability even where the software doesn’t require CRA conformity assessment. This dossier runs ten common website, SaaS and web-application configurations through both laws. They range from a static information site to a device control console, a Tauri or Electron desktop app, a browser extension, an installed progressive web app (PWA) and self-hosted software with commercial plugins. Each setup gets a CRA result, a PLD result and the provision that decides it.
Written for product, web engineering and compliance teams deciding which of their web properties fall under the CRA, the PLD or both.
Why it matters
The CRA scope test for software turns on where the code runs. A web application reached only through a browser, including a SaaS application, is outside the CRA as a standalone product with digital elements. Being outside the CRA does not mean that no cybersecurity law applies. NIS2 may apply where the provider falls within a covered sector and meets the applicable size or designation criteria, while contractual, data-protection and sector-specific security requirements may also remain relevant. The same code packaged as a desktop build, a store package or a browser extension can be a product with digital elements under the CRA. Each build variant can be a separate product with its own CRA scope analysis, technical documentation and conformity assessment.
A website can take two statutes at once. It is remote data processing when it is displayed by the manufacturer’s own packaged app, and outside the CRA when someone opens it in a browser tab. The PLD ignores the execution test entirely. Software can fall within the PLD whether it is installed locally, accessed through a communications network, delivered through cloud technologies or supplied as SaaS. Hosted software never leaves the manufacturer’s control, so the defence that a defect arose after placing on the market isn’t available. For consumer web applications, the main exposure is destroyed or corrupted personal data. That damage can be compensated from the first claim, with no physical harm needed.
Transposition adds to the uncertainty. According to the Comply.Land PLD transposition tracker reviewed on 30 October 2026, national approaches differed widely. Croatia, Germany and Italy narrow the development risk defence for software and updates. Malta is one of seven Member States with no public draft.
What is inside
- Binding text versus guidance. Why the binding text (the CRA’s Articles and Annexes plus its delegated and implementing acts) carries different weight from the recitals, the Commission guidance and the FAQs. Also why the exclusion of websites must be read alongside the definition of a product with digital elements in Article 3(1), not on recital 12 alone.
- Ten website, SaaS and web-application configurations. Each gets a CRA status, a PLD status and the deciding provision, set out in a single summary table.
- The CRA’s narrow remote data processing boundary. It covers login portals, device consoles and update APIs, where the statutory dependency and manufacturer-responsibility conditions are met, while leaving out CRM, CI/CD pipelines and telemetry. The dossier also takes a position on the browser-side code of web consoles.
- Where the CRA and the PLD part company. Related services, manufacturer’s control, damage heads, and the unsettled question of when hosted software is placed on the market.
- PLD transposition across the EU. A Member State-by-Member State table as at 30 October 2026, covering the development risk defence, the recourse limit for small software suppliers, data damage and disclosure rules.
- Practical follow-up. Eight operational steps, eight monitoring triggers, and an annex of the operative texts quoted verbatim.
Who is it for
Manufacturers of connected products and their web teams, SaaS and web application operators, suppliers of desktop apps, browser extensions, self-hosted software, plugins and SDKs, and the compliance and legal teams who classify web properties under the CRA and the PLD.
Written by Daniel Thompson-Yvetot for CrabNebula Ltd. Not legal advice, not a conformity determination.
