The European Union’s Data Act — formally titled Regulation (EU) 2023/2854 of the European Parliament and of the Council — is one of the most consequential pieces of technology regulation to emerge from Brussels in years. It entered into force on January 11, 2024, and its substantive obligations began applying on September 12, 2025. The regulation establishes harmonized rules governing who can access and use data generated by connected products and related digital services across the EU. For US businesses that manufacture connected devices, operate apps linked to those devices, or provide cloud infrastructure to European customers, the Data Act creates real legal obligations — even though you may never have set foot in Europe.

This page explains what the EU Data Act is, what problem it was designed to solve, who it covers, and what the key defined terms mean in practice. Getting the definitions right matters enormously: a single classification question — whether your product is a “connected product” or whether your company is a “data holder” — can determine whether the full weight of the regulation applies to your business.

What Problem Does the EU Data Act Solve?

The EU Data Act was designed to address a fundamental imbalance in the data economy. When a person uses a connected product — a smart thermostat, an industrial sensor, a GPS-enabled tractor, a wearable fitness tracker — that product continuously generates data. Under the pre-Data Act status quo, that data flowed almost exclusively to the manufacturer or the service provider who built the product’s ecosystem. The person who purchased and used the product, whose behavior generated the data, often had no practical ability to access it. Businesses that depended on connected equipment found themselves locked into proprietary data ecosystems they could not exit. Competitors and innovators could not build complementary services because they could not access the raw data from devices already deployed in the field.

The European Commission concluded that this market structure was not accidental. It was a product of design choices — devices that did not expose data interfaces, contract terms that prohibited sharing, and technical lock-in that made switching costs prohibitive. The Data Act intervenes directly in this dynamic by creating legal rights of access that cannot be contracted away and by requiring manufacturers to design products that can actually deliver that access.

At a broader level, the Data Act is part of a larger EU data strategy that includes the Data Governance Act, the AI Act, and several sector-specific regulations. Together these instruments are meant to create a “European data space” — an environment where data flows more freely among businesses, public institutions, and individuals, while still respecting privacy and other fundamental rights. The Data Act occupies the layer closest to the physical world, governing the data that comes off machines and devices rather than data that was created or processed by software alone.

Key Defined Terms: The Building Blocks of Compliance

The Data Act’s definitions section is not administrative boilerplate. The definitions are carefully constructed gates: if your business or product fits within a definition, specific chapters and articles apply to you. Understanding each term in depth is the foundation of any compliance analysis.

Data

The regulation defines “data” broadly as any digital representation of acts, facts, or information, and any compilation of such acts, facts, or information, including in the form of sound, visual, or audiovisual recording. This is an intentionally expansive definition. It covers sensor readings, event logs, telemetry streams, images captured by cameras, audio recorded by microphones, GPS coordinates, and any other form of digitally encoded information. The broad definition ensures that manufacturers cannot argue that certain outputs of their products fall outside the regulation’s scope simply because those outputs are in an unusual format.

Connected Product

A “connected product” is defined as an article that obtains, generates, or collects data concerning its use or its environment, and that is able to communicate data via an electronic communications service, physical connection, or on-device processing, and whose primary function is not the storage, processing, transfer, or analysis of data. This last qualifier is important: a laptop, smartphone, or cloud server is not a connected product under the Data Act because its primary function is data processing. A smart washing machine that records water usage and reports it to a cloud platform is a connected product because its primary function is washing clothes, not data processing.

Connected products include consumer electronics, household appliances, vehicles, industrial machinery, agricultural equipment, medical devices, wearable technology, and a wide range of other physical goods. If your company makes or sells any physical product that connects to the internet or another network and generates data about how it is used, that product is almost certainly a connected product under the Data Act. The implications of that classification are covered throughout this series.

Related Service

A “related service” is a digital service — including software — that is connected with the product in such a way that its absence would prevent the connected product from performing one or more of its functions, or that is provided by the manufacturer or a third party and is connected with the connected product to add to, build on, or limit functions of the product. The classic example is a mobile application that must be installed to configure or operate a smart device. The app is a related service. So is a cloud-based dashboard that displays data from an industrial sensor, or a firmware update service that keeps a device functional.

The related service concept is important for US businesses because you might not manufacture the physical device yourself — you might provide the companion app or cloud platform. If your software qualifies as a related service to a connected product sold on the EU market, Chapter II obligations apply to you just as they do to the hardware manufacturer. US software companies that build IoT management platforms, analytics dashboards, or companion apps for smart devices should pay close attention to this definition.

User

A “user” is a natural or legal person who owns, rents, leases, or otherwise obtains a connected product or receives a related service. The definition is explicitly broad enough to cover both consumers (individual people) and businesses. A factory that leases a connected piece of production equipment is a user. A logistics company that uses GPS-enabled vehicles under a fleet management contract is a user. A hospital that operates connected medical imaging equipment is a user. The Data Act’s user access rights discussed in later pages of this series apply to all these actors.

The inclusion of legal persons — companies — as users is a deliberate policy choice. The Data Act’s drafters recognized that a large share of connected product usage occurs in B2B contexts, particularly in manufacturing, agriculture, transportation, and healthcare. By extending user rights to businesses, the regulation ensures that companies that depend on connected equipment for their operations can access the operational data those devices generate, even if the manufacturer would prefer to keep that data proprietary.

Data Holder

A “data holder” is a natural or legal person who is legally obliged or entitled under the regulation to use and make available data to which they have access. In most scenarios involving connected products, the data holder is the manufacturer of the connected product or the provider of the related service — the entity whose systems actually receive and store the data the device generates. If you are a US manufacturer of connected products and your backend servers collect telemetry from those devices as they operate in Europe, you are a data holder under the Data Act.

Being a data holder is not simply a description — it is a legal status that comes with obligations. Data holders must share data with users who request it, must provide data to third parties designated by users, and must not use shared data in ways the regulation prohibits. The entire data access framework in Chapter II of the Data Act runs through the data holder concept.

Data Recipient

A “data recipient” is a natural or legal person (other than the user who generated the data) to whom the data holder makes data available, pursuant to a legal obligation or contractual agreement. The data recipient concept matters most in the context of user-initiated data sharing: when a user exercises their right under the Data Act to have their data shared with a third party — say, a competing service provider or a repair shop — that third party is the data recipient. Data recipients have their own set of obligations under the regulation, including prohibitions on using shared data to build competing products or to profile users.

Data Generated by Use

While not a separately defined term in the Data Act’s glossary, the concept of data “generated by use” of a connected product or related service runs throughout the regulation and defines its scope. This is data that is produced as a result of the product being operated — sensor readings, usage logs, error codes, performance metrics, location data, audio or video recordings, and anything else the product captures or calculates in the course of performing its functions. Data that the manufacturer independently creates — for example, proprietary analytics models trained on aggregated data — is not “data generated by use” in the same sense and is not subject to the same access obligations.

Categories of Actors Covered by the Data Act

The Data Act addresses four principal categories of actors: manufacturers of connected products, providers of related services, holders of data generated by those products and services, and users of those products and services. A single company can fall into more than one category simultaneously. A US company that manufactures a smart industrial pump, operates the cloud platform that receives pump telemetry, and sells that data analytics as a service to factory operators is simultaneously a manufacturer, a related service provider, a data holder, and potentially a data recipient — all under the same regulation.

For cloud and data processing services specifically, Chapter V of the Data Act creates obligations aimed at preventing vendor lock-in and enabling customers to switch providers. This chapter primarily targets infrastructure-as-a-service and platform-as-a-service providers and is discussed separately in this series. For now, it is enough to note that US cloud providers serving EU customers who themselves operate connected products may find Chapter V highly relevant to their business.

Public sector bodies occupy a special category under Chapter V of the Data Act, which allows EU member state governments to request data from private data holders in cases of public emergencies or other exceptional circumstances. While the practical implications for US businesses are limited, companies operating in sectors like healthcare, energy, or critical infrastructure should be aware that their EU data could potentially be subject to government access requests under this framework.

What the EU Data Act Does Not Cover

Understanding the regulation’s exclusions is as important as understanding its inclusions. The Data Act explicitly does not apply to certain categories of data and certain types of products and services.

Personal computers, tablets, and smartphones are not connected products under the Data Act because their primary function is data processing. A laptop running software that collects telemetry about how the user works is not a connected product within the meaning of the regulation — though the software may have separate obligations under the GDPR. Similarly, smart televisions that primarily function as display devices for streaming content occupy a gray area, and manufacturers in that segment should analyze their specific product architectures carefully.

The Data Act does not apply to content created by users — documents, photographs, communications — even if that content is stored on connected devices. It also does not create new obligations with respect to data that was not generated by the use of a connected product. For example, if a manufacturer collects data about its customers through a separate loyalty program or website, that data is not governed by the Data Act (though it may be governed by the GDPR).

Non-personal data is generally in scope for the Data Act, but the regulation requires that sharing obligations be implemented in a manner consistent with the GDPR. If data generated by a connected product also qualifies as personal data — for example, location data tied to an identifiable person — the GDPR’s requirements cannot be displaced by the Data Act’s sharing obligations. Both sets of rules must be satisfied simultaneously, which creates practical complexity in product design and data architecture.

The Data Act also contains an important carve-out for trade secrets. A data holder is not required to disclose data that constitutes a trade secret unless the holder takes measures to preserve confidentiality. This means that manufacturers cannot simply label all their data as trade secrets to avoid sharing obligations, but it does mean that genuinely proprietary information — such as predictive maintenance algorithms, proprietary calibration data, or unique manufacturing process metrics — may be protectable if the holder has actually taken steps to treat it as confidential.

Why These Definitions Matter for Practical Compliance

The definitional framework of the Data Act is not an academic exercise — it determines whether your business needs to redesign products, revise contracts, appoint an EU legal representative, implement new data-sharing APIs, or audit your cloud service agreements. Before investing in any compliance program, every US business with EU market exposure should work through a classification analysis: Does the product qualify as a connected product? Does the company operate a related service? Is the company a data holder with respect to EU-sourced data? Do users of the product have access rights that the company currently does not support?

These are not always easy questions. Product architectures that involve edge computing, hybrid cloud deployments, or third-party data processing chains can make it difficult to determine which entity is the data holder for a given dataset. In B2B scenarios, the question of who qualifies as the “user” — the equipment owner, the lessee, the operator, or the end consumer — can be genuinely ambiguous. The regulation provides guidance on some of these scenarios but leaves others to be resolved through national enforcement and, eventually, court interpretation.

The subsequent pages in this series address specific compliance obligations in detail. But every one of those obligations flows from the definitional foundation covered here. Getting the classification right is the starting point for every other question the Data Act raises.