EU Data Act Connected Products and Data Types

A connected product is not every digital device or every cloud service. The Regulation focuses on an item that obtains, generates, or collects data about its use or environment, can communicate product data through an electronic communications service, physical connection, or on-device access, and is not primarily used to store, process, or transmit data for someone other than the user.

That means the scope test should start from the physical item and its data path. Connected cars, health-monitoring devices, smart-home devices, aircraft, robots, industrial machines, agricultural machinery, smartphones, and TVs are examples in the Commission material, but the label is not enough; the item must generate or collect use, performance, or environment data and be able to communicate it.

The Data Act generally applies from 12 September 2025. The Article 3(1) duty to design connected products and related services so data is accessible by default applies only to products and related services placed on the market after 12 September 2026. That delayed design duty is separate from the Article 4 and Article 5 request-based access rules.

Chapter II excludes data generated through products manufactured or designed, or related services provided, by qualifying microenterprises and small enterprises. The exclusion is lost where the enterprise has a partner or linked enterprise that is not micro or small, or is subcontracted to manufacture, design, or provide the product or service. Article 7 also gives a narrower temporary exclusion to a newly medium-sized enterprise and certain recently placed products.

A related service is a digital service other than an electronic communications service, including software, that is connected with the product at purchase, rental, or lease in a way that absence of the service would prevent one or more product functions, or that is later connected by the manufacturer or a third party to add to, update, or adapt the product's functions.

The practical test is whether the service affects the connected product's operation or behaviour. A washing-machine app that adjusts a cycle based on sensor data can be a related service. In the vehicle guidance, remote door locking, cockpit pre-conditioning, charging management, driver-preference syncing, and route optimisation shown on the dashboard are treated as examples of vehicle-related services.

Product data is data generated by use of the connected product that the manufacturer designed to be retrievable by a user, data holder, or third party. Related-service data is data representing digitised user actions, inaction, or events related to the connected product during the provision of a related service.

Scope is field-level, not product-line-level. For each data stream, identify the event or sensor source, whether the data comes from the product or the related service, who can lawfully obtain it, and whether the user or a chosen third party needs metadata to interpret and use it.

Readily available data means product data and related-service data that the data holder lawfully obtains or can lawfully obtain from the connected product or related service without disproportionate effort beyond a simple operation. The analysis should therefore cover both data already retrieved and data the architecture can lawfully retrieve without disproportionate effort.

Metadata is part of the access package when it is necessary to interpret and use the data. A useful metadata dictionary names units, timestamps, identifiers, sampling or collection frequency, format, quality limits, location or context fields, retention, and the source system that supplies the value.

Chapter II covers raw and pre-processed data, plus metadata needed to make that data understandable and usable. Pre-processing can include preparing sensor output so it describes a physical quantity or quality, such as temperature, pressure, flow rate, audio, pH value, liquid level, position, acceleration, or speed.

Inferred or derived information is different. It is usually the result of additional investment, proprietary or complex algorithms, substantial transformation, sensor fusion that creates new insight, or analytics that assign new value beyond the underlying measurement. The data holder should still assess whether the underlying raw or pre-processed input data remains in scope.

A complete scope record should list data to share and explain excluded data, protected data, and conditions that may affect delivery. Tie each exclusion to a legal definition, guidance example, technical architecture fact, or protection measure.

Common exclusions or constraints include inferred or derived information, content protected by intellectual property rights, unavailable edge-processed data that no party can access, personal data without a valid processing basis, trade secrets needing confidentiality measures, security restrictions based on EU or national law, gatekeeper ineligibility for third-party access, and the ban on using accessed data to develop a competing connected product.

Create a product-and-data scope map before product, legal, security, engineering, and support teams write notices, access portals, APIs, contracts, or helpdesk scripts. A reviewer should be able to trace each field from product architecture to Data Act classification.

Keep the map concise enough to maintain, but specific enough to stop overbroad exports and unsupported exclusions. The record should show the product or service, user relationship, data holder, data category, availability, metadata, safeguards, delivery route, source, owner, and review trigger.