Shop

When a Website Is a Product with Digital Elements

by Daniel Thompson-Yvetot for CrabNebula Ltd.

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.

Free until 12 November

How to determine if it is a product with digital elements?

by Daniel Thompson-Yvetot for CrabNebula Ltd.

A dishwasher with wash-cycle firmware and no way to connect to anything is the classic example of a product outside the Cyber Resilience Act’s scope. The example is correct, but “it has no connectivity features” is not the legal test. Under Article 2(1), what matters is whether a data connection falls within the product’s intended purpose or reasonably foreseeable use. The Commission’s guidance of 27 July 2026 adds what counts as a data connection: digitally encoded information, sent according to a defined scheme and decodable at the other end. Switching an output on and off does not qualify. This dossier restates the CRA scope and product-with-digital-elements test and applies it to seven versions of the same dishwasher. It shows why a service header used to read fault codes brings a product within the Cyber Resilience Act’s scope, why a USB port used only for power does not, and why any product whose firmware can be updated in the field is in scope.

Written for compliance, engineering and product teams assessing embedded firmware, connected hardware and other potential products with digital elements for Cyber Resilience Act compliance.

Free until 5 November

Who Signs for the Kitchen

by Daniel Thompson-Yvetot for CrabNebula Ltd.

What happens when separate EU product-compliance regimes meet inside one installed system? A fitted kitchen sits across two EU product regimes. The carcases and fronts fall within the furniture product group being developed under the Ecodesign for Sustainable Products Regulation (ESPR), while the floor and the door may be regulated as construction products under the Construction Products Regulation (CPR). Each regime keeps its own product records. However, neither of them describe the installed room that the owner insures and a professional signs for on the day of acceptance. This dossier is a fitted kitchen in a Milan apartment as a practical case study in Digital Product Passport requirements, EU product compliance and responsibility for installed works. It tests against the operative texts of the CPR, the ESPR and the recast Energy Performance of Building Directive. It explains why the join sits at the works level, which the CPR leaves to Member States, why neither digital product passport exists yet, and why a stone worktop may be part of the furniture rather than a construction product. Professionals who certify installed works get eight operational steps for classifying each item, collecting the matching records and writing the assembly record themselves.

Written for professionals who certify installed works in which products regulated under the CPR and ESPR meet.

Free until 29 October

The Digital Product Passport for Software Products

by Daniel Thompson-Yvetot for CrabNebula Ltd.

No EU law requires a Digital Product Passport (DPP) for standalone software, but the registry is live, the standards are cited in the Official Journal, and from 18 February 2027 battery passports will carry data that battery management system firmware produces. This dossier provides a comprehensive breakdown of the Digital Product Passport (DPP) requirements, standards and vocabulary relevant to software products. It details the core horizontal system requirements necessary for full passport conformance and explores how software vendors can gain a strategic advantage by aligning their CRA compliance evidence with standard-conformant passport structures. Software vendors can serve customers whose physical products carry mandatory passports, be ready for the registry at marginal cost if scope later extends to software, and turn compliance documentation into a transparency asset their customers can see.

Written for product, engineering, and compliance leadership.

Free until 22 October

Extended Security Maintenance and “Placing on the Market”

by Daniel Thompson-Yvetot

Under the Cyber Resilience Act (CRA), patching a product already on the market keeps its original placing-on-the-market date. Only certain updates count as a new placing. This dossier explains what happens to security updates after the CRA support period ends, where the Commission’s adopted guidance draws that line, and why a paid extended security maintenance (ESM) offering should never charge for the security update itself.

Written for product security and compliance leads, product owners classifying maintenance releases, and commercial teams pricing extended support.

Free until 15 October

Iterative Software and Support Periods Under the Cyber Resilience Act

by Daniel Thompson-Yvetot

One of your weekly releases may qualify as a substantial modification under the Cyber Resilience Act and require a new support-period assessment. This dossier shows which releases may create a substantially modified product requiring its own CRA support-period declaration, and how Article 13(10) may allow you to focus vulnerability handling on the latest version when users can upgrade free of charge and without additional costs.

Written for CTOs, engineering leads and compliance owners who need defensible answers before their next release ships.

Free until 8 October

Downstream Post-Market Modifications and Break-Glass Agreements

by Daniel Thompson-Yvetot

An emergency fix to a product you do not manufacture can assign "manufacturer" obligations and reporting duties under the Cyber Resilience Act. This dossier maps which post-market modifications and break-glass actions cross that line, and how to agree who carries the obligation before an incident forces the answer.

Written for product security, compliance and engineering teams handling post-market fixes on someone else's product.

Free until 1 October

Article 14 Reporting beyond the Support Period

by Daniel Thompson-Yvetot

Ending a product's support period does not end your Cyber Resilience Act's Article 14 reporting duty. This dossier argues that duty only ends when your company does, tracing that position through the Regulation's text, the adopted European Commission guidance, and the wider EU product-safety framework.

Written for general counsel and compliance leads deciding whether a discontinued product's Cyber Resilience Act reporting duty has actually ended.

Free until 24 September

Vulnerability Handling under CRA: the 11 September 2026 Reporting Obligations

by Daniel Thompson-Yvetot

From 11 September 2026, the Cyber Resilience Act's vulnerability and incident reporting obligations apply to manufacturers, and they cover products already on the market, not just new ones. This dossier sets out the 24-hour and 72-hour reporting deadlines, and the 14-day final-report deadline for actively exploited vulnerabilities: what actually triggers them and how to be ready before the clock starts.

Written for product security and compliance leads, and whoever owns incident response, at any manufacturer with a product with digital elements already on the EU market.

Free until 17 September

Cyber Vulnerability Reporting: Fundamentals

by Daniel Thompson-Yvetot

A practical, self-paced foundation course on vulnerability and incident reporting under the EU Cyber Resilience Act. In partnership with ECI Ireland.