Can an Intangible Component Be a Product?

EU Directive-level explanationUpdated 16 October 2026By ProductLiability.help editorial desk

The component definition includes intangible items

Article 4 of Directive (EU) 2024/2853 defines component broadly enough to include an intangible item integrated into or interconnected with a product. The definition also identifies raw materials and related services. It is therefore incorrect to restrict components to physical parts that can be held, replaced or listed by weight in a manufacturing specification.

The meaning of product and the meaning of component overlap without being identical. Software is expressly included as a product and can become a component of a larger product. A qualifying related service can be a component through its statutory relationship to a product. These routes require attention to what the intangible element actually is and how it functions, rather than relying on the label digital asset.

Software provides a clear example

A software library, embedded control routine or operating system can be integrated into another product without a separate physical housing. Its instructions may affect how the larger product behaves. Record the software identity, relevant version and integration relationship. The developer of a library and the manufacturer supplying the finished device may be separate participants whose roles need individual examination.

A dependency list can identify candidates for investigation, but it does not establish that each dependency contributed to an incident. Some listed components may be unused in the relevant configuration. Others may have been modified or replaced. Preserve information showing which functions were active and how the alleged unsafe behaviour could arise. Classification should guide evidence collection rather than convert a component inventory into a list of proven defects.

Digital information is not automatically a product

The Directive's recitals distinguish digital files generally from the specifically included category of digital manufacturing files. They also explain that information content, such as media files or e-books, is not itself covered merely because it is digital. Describing something as an intangible item should not be used to bypass these boundaries or to classify every instruction, measurement or message as a standalone product.

For example, a controller can receive a temperature measurement without every measurement becoming a separate software product. The supplied software processing that measurement, a defective physical sensor and a qualifying related service may each require examination. The legal classification depends on the actual item and relationship. Preserve the distinction between executable software, functional manufacturing instructions, ordinary content and data used by the system.

Establish a real integration or interconnection

The phrase used with another product can describe many arrangements, including incidental use. Article 4's component definition requires integration or interconnection. Record the technical relationship, the functions exchanged and the product concerned. A document read by a developer while writing code is not necessarily an integrated component merely because it influenced the design.

The companion article on components as products explains why that relationship should be mapped explicitly. For intangible elements, useful evidence includes interface descriptions, build records and architecture diagrams. A supplier contract can identify an intended arrangement, while deployed configuration shows what was actually implemented. If they differ, record both instead of silently assuming that the contract describes the incident environment.

Related services have a distinct route

A digital service can enter the component analysis where it meets the Directive's related-service conditions. Those conditions should not be replaced with the vague observation that a device uses the internet. The focused article on digital services as product components explains the classification workflow while the connected-products guide provides the full related-service definition and examples.

This distinction matters when a product combines locally running software and remote processing. Both can be intangible contributions while reaching the legal analysis through different facts. Identify what is supplied, what is executed and what depends on a continuing service. An architecture diagram should show the dependency without predetermining whether a particular provider is liable for a subsequent incident.

Classification precedes responsibility

Article 8 addresses manufacturers of defective products and components under specified conditions, including the relevant manufacturer's control over integration or interconnection. It does not say every provider of an intangible element compensates every injured user. Article 11's exemptions can also require examination. Preserve evidence of authorisation, integration instructions and the origin of a suspected defect before drawing conclusions about responsibility.

Article 7 separately determines defectiveness using the safety standard and all relevant circumstances. Article 10 addresses proof of defectiveness, damage and causation. An intangible item can qualify without being unsafe, just as a physical component can. The absence of a tangible specimen changes the kinds of evidence available but does not remove the need to establish those substantive elements.

Preserve identity and relevant dates

Keep versioned copies, build identifiers and the records connecting an intangible component to the product actually involved. Later source code or a current service description may not represent the incident state. Corrected Article 2(1) covers products placed on the market or put into service after 8 December 2026. Check that chronology and the applicable national framework rather than assuming that an intangible item follows the accident date.

Records that help the review

Use the following as a practical starting point. Select and preserve records appropriate to the product, incident and applicable procedure.

Technical description of the intangible element
Integration architecture and interface specifications
Supplier, version and commercial-supply records

Independent educational information at EU Directive level. National implementing law and procedure require separate review.

Primary sources and legal scope

This page explains the EU Directive framework. Check national implementing law, the corrected temporal scope and relevant procedure before applying it to a case.

Official Journal Directive (EU) 2024/2853, recital 13 and 16: digital scope and product categories ↗

Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.