At the heart of the EU Data Act is a deceptively simple proposition: the person who uses a connected product should be able to access the data that product generates about their use. This is the core principle of Chapter II of Regulation (EU) 2023/2854, and it represents a significant shift in how data generated by connected devices is legally characterized. Before the Data Act, that data was effectively the manufacturer’s exclusive property, controlled through device architecture and contract terms. Under the Data Act, users have legally enforceable rights to access it, share it, and use it — rights that manufacturers cannot contract away.

This page explains the user access rights framework in Chapter II in depth: what data is covered, who has the right to access it, how access must be provided, what technical obligations manufacturers face, and what manufacturers are prohibited from doing with user data. For US manufacturers and service providers operating in the EU market, understanding Chapter II is the most operationally significant part of Data Act compliance.

Who Has the Right to Access Data

The Data Act’s user access rights apply to any “user” of a connected product or related service. As explained elsewhere in this series, the definition of user is intentionally broad: it covers both individual consumers and legal persons (companies and organizations) who own, rent, lease, or otherwise obtain a connected product or receive a related service. This dual coverage — consumers and businesses alike — is one of the Data Act’s most consequential design choices.

A factory that purchases a connected CNC machining center is a user with data access rights. A logistics company that leases GPS-equipped trucks is a user with data access rights. A hospital that operates networked patient monitoring equipment is a user with data access rights. A farmer who buys a GPS-guided tractor is a user with data access rights. A consumer who purchases a smart washing machine is a user with data access rights.

The regulation also distinguishes between the user who generated the data and third parties to whom the user may want to share that data. A user can exercise their access right directly, or they can instruct the data holder to share their data with a third party — a competing service provider, a repair shop, an insurance company, an analytics firm, or any other entity the user designates. The user’s ability to share their data with third parties of their choosing is a critical mechanism for enabling competition and innovation in connected product ecosystems.

What Data Is Covered

Chapter II applies to data generated by the use of a connected product or related service. This is not a narrow category. It encompasses all data that the product or service produces as a result of being operated: sensor readings, operational logs, performance metrics, error codes and fault records, location data, usage patterns, environmental measurements, and any other information generated as the product performs its intended function.

The scope includes both raw data — the unprocessed measurements and readings coming off the device — and derived data, to the extent that derived data is produced directly from device operation rather than from independent manufacturer analysis. A usage cycle log that simply records when the machine was turned on and off is clearly covered. A predictive maintenance score calculated by a complex proprietary algorithm trained on thousands of devices may be in a different category, as it involves significant manufacturer intellectual contribution beyond simply recording what the device did.

The coverage extends to both product data and related service data. If a companion mobile application generates data about how the user interacts with it — which features they use, how they configure the device through the app, what commands they issue — that data generated through use of the related service is also covered. US software companies providing related services should not assume that only hardware-generated data is in scope.

An important distinction exists between data that is technically accessible — stored somewhere in the manufacturer’s or service provider’s systems and potentially retrievable — and data that is “readily available” in the meaning the Data Act uses. The regulation’s access requirements apply to data that is or can be readily available, and data holders cannot hide data from access obligations simply by storing it in formats or locations that make retrieval technically complex if that complexity is of the data holder’s own making. The obligation requires that the data holder be able to retrieve and deliver the data.

Data Accessible by Default Versus Data Accessible on Request

The Data Act creates a distinction between two categories of user-accessible data based on how access is provided. The first category is data that the product or related service makes accessible by default — data that is designed to flow to the user automatically or through a standard interface as part of the product’s normal operation. The second category is data that is not accessible by default but that the user can request to receive.

For the first category, manufacturers must design products so that data can be “directly accessed” by the user from the device itself or through an interface that the product provides. The regulation uses the phrase “where technically feasible, directly from the connected product.” This means the product should have some form of on-device access mechanism — a display, a local data port, an on-device API, or similar — that allows the user to retrieve their data without necessarily routing through the manufacturer’s cloud. This is a significant design requirement that affects product architecture decisions at the hardware and firmware level.

For the second category, users can make requests to the data holder — typically the manufacturer or service provider — for access to data that is not directly available from the device. Upon such a request, the data holder must provide the data to the user. The regulation does not establish a specific response time for such requests but does require that access be provided in a timely and machine-readable manner. Manufacturers should establish clear processes for receiving, handling, and fulfilling user data access requests, including procedures for verifying that the requestor is actually a user of the product in question.

How Access Must Be Provided

The Data Act imposes specific standards for how data access must be provided. These standards are not suggestions — they are mandatory requirements that inform the technical and operational design of data access systems.

Real-Time and Aggregated Access

Users have the right to access their data both in real time (as it is generated) and as historical records. Real-time access is particularly important in industrial and agricultural contexts, where users need current operational data to make decisions about equipment performance, maintenance scheduling, and process optimization. An EU factory that has purchased connected production equipment has the right to receive live telemetry from that equipment, not just periodic exports of historical data.

Manufacturers that have designed their products to route all data through proprietary cloud platforms before it can be accessed by users need to assess whether that architecture is compatible with the real-time access requirement. If all data must travel to a US-based cloud server before it is accessible to the EU user, and that introduces latency or routing requirements that compromise effective real-time access, the architecture may need to change. Edge computing designs that make data available locally, or designs that support both cloud and direct device access, are generally better positioned to satisfy this requirement.

Machine-Readable Format

Data must be provided in a machine-readable format. This means formats that can be processed by software without manual human interpretation — structured data formats such as JSON, XML, CSV, or other open standard formats, rather than PDF reports or visual dashboards that require a human to read and extract the underlying data. The machine-readable requirement is designed to ensure that users can actually use the data they receive, including by feeding it into third-party applications or services.

For manufacturers that have historically provided users with access to their data only through proprietary dashboards or reporting tools — which give users a view of the data but not portable access to the underlying dataset — the machine-readable requirement represents a significant change. It requires exposing the actual data, not just a curated view of it.

Free of Charge by Default

The Data Act establishes a default rule that user access to data from connected products must be provided free of charge. Manufacturers and service providers cannot charge users a fee for accessing their own usage data. This directly conflicts with business models that have treated proprietary data access as a paid add-on service — for example, telematics subscription services that charge equipment owners for access to their own machine’s operational data.

The free-of-charge rule is not absolute. The regulation permits data holders to seek fair compensation when sharing data with third parties designated by the user, and allows for some cost recovery in narrow circumstances. But the baseline for user-to-data-holder data access is no charge to the user. Companies with revenue models that depend on charging users for their own data need to restructure those models to comply with the regulation.

Easily and Securely

The Data Act requires that access be provided easily and securely. “Easily” is interpreted to mean that the access mechanism must not create unnecessary barriers or require technical expertise that the typical user does not possess. Requiring users to submit complex technical documentation, navigate multi-step bureaucratic processes, or use specialized equipment to access their own data would not satisfy this standard. The access mechanism must be genuinely user-friendly.

“Securely” means that the data access mechanism itself must incorporate appropriate technical security measures. Data transmitted to users must be protected against interception or unauthorized access during transmission. The authentication mechanism used to verify the user’s identity before providing access must be robust. This security requirement applies equally to direct device access, API-based access, and any other delivery method.

Technical Obligations on Manufacturers

Chapter II creates affirmative technical obligations on manufacturers, not just procedural ones. Manufacturers must ensure that connected products are designed and manufactured — and that related services are designed and provided — in a way that enables user access to data from the outset. This is a design requirement, not an afterthought.

Practically, this means manufacturers need to think about data access architecture at the product design stage. The product must be capable of generating and storing the data generated by its use, making that data accessible to the user through an appropriate interface, communicating data to third parties designated by the user upon instruction, and doing all of this in a way that does not require the user to route through manufacturer-controlled systems if direct access is technically feasible.

For products with significant local processing capability, direct access through a local API or physical data port is expected where technically feasible. For simpler devices that offload all data to cloud backends, the cloud system must have appropriate user-facing access interfaces. Products that generate large volumes of data need data management architecture that can handle selective retrieval and export at user request without undue operational burden.

Manufacturers that are developing new connected products for the EU market must integrate data access design from the earliest engineering stages. Retrofitting data access capabilities onto products that were designed without this requirement in mind is possible but expensive and technically complex. Engineering teams need to understand these requirements as a design constraint — similar to other product compliance requirements like safety standards or electromagnetic compatibility — not as a legal team problem to be solved after the product is designed.

The Prohibition on Using Data to Build Competing Products

The Data Act includes a critical protection for manufacturers against a specific misuse of user data by third parties. When a user exercises their right to have their data shared with a third-party data recipient — for example, a competing service provider or a platform that offers analytics services — the data recipient is explicitly prohibited from using that data to develop a product that competes directly with the connected product from which the data was obtained.

This prohibition was included in the Data Act specifically to address manufacturers’ concerns that opening up data access would allow competitors to reverse-engineer their products or use operational data to develop directly competing hardware. The concern is legitimate: detailed operational data from a piece of industrial machinery could, in principle, give a competitor significant insight into that machine’s design, performance characteristics, and engineering tradeoffs. The Data Act acknowledges this concern and addresses it by restricting what data recipients can do with shared data.

The prohibition applies specifically to data received pursuant to the Data Act’s user-initiated sharing mechanism. It does not apply to data that a company acquires through independent means, or to data used to develop services that complement but do not directly compete with the connected product. A third-party maintenance service that receives operational data from an industrial machine and uses it to offer maintenance scheduling recommendations is not building a competing product. A company that receives the same data and uses it to design a competing industrial machine would be in violation.

For US manufacturers, this prohibition provides meaningful protection against one of the scenarios that makes data access rights most threatening to their business models. But the protection is not absolute, and its scope will ultimately be defined by enforcement decisions and court interpretations in EU member states. Manufacturers should not rely on this prohibition as a complete defense against competitive data use; they should also pursue available trade secret protections for genuinely proprietary data.

The Prohibition on Barriers to Access

Equally important as the technical access requirements is the prohibition on barriers to access. The Data Act explicitly prohibits manufacturers and service providers from making data access more difficult than necessary through technical measures, contractual terms, or business practices. This prohibition addresses a pattern that EU policymakers observed in the connected product market: even where manufacturers technically could provide data access, they often made access difficult through design choices, pricing structures, and contract terms that served as practical barriers without technically prohibiting access.

Examples of prohibited barriers include: contract terms that require users to waive their data access rights as a condition of purchase or use; technical interfaces that are nominally available but require such complex authentication or technical capability to use that typical users cannot practically access them; pricing structures that make data access prohibitively expensive; deliberate design choices that make data access technically impossible even when the underlying data exists and is available in the manufacturer’s systems; and contract terms that penalize users for accessing their data or for sharing it with third parties.

The prohibition on contractual barriers is particularly significant for US manufacturers reviewing their EU customer agreements. Standard terms and conditions that were drafted before the Data Act took effect may contain provisions that are now invalid under the regulation. Terms that purport to grant the manufacturer exclusive ownership of all device-generated data with no user access rights, terms that prohibit users from connecting third-party services to the device, and terms that require users to pay for data exports are all potential targets for regulatory challenge.

US manufacturers should conduct a systematic review of their standard EU customer contracts, distributor agreements, and end-user license agreements to identify provisions that may conflict with the Data Act’s user access rights framework. Provisions that limit, complicate, or condition data access beyond what the regulation permits need to be revised or removed. This contract review is not merely a legal housekeeping exercise — it is a substantive compliance requirement.

Implications for Business Models Based on Data Monetization

Many connected product manufacturers have built significant revenue streams around the data their products generate. Telematics services, predictive maintenance subscriptions, operational analytics platforms, fleet management software, and similar offerings all depend on the manufacturer having privileged access to device data and the ability to monetize insights derived from that data. The Data Act does not prohibit these business models outright, but it fundamentally changes the terms on which they operate.

Under the Data Act, users have the right to receive their own data without charge and to direct it to competing service providers. This means that a US manufacturer’s telematics subscription that charges EU customers for access to their own vehicle data needs to be restructured: the underlying data access must be available free of charge regardless of subscription, while premium services that add value beyond raw data access — analytics, insights, integrations, reports — can potentially still be offered on a paid basis. The key distinction is between charging for access to the user’s own raw data (prohibited) and charging for value-added services built on top of that data (potentially permissible).

Manufacturers whose EU customers can now direct their device data to third-party analytics and service providers will also face new competition in the service layer. The captive audience for manufacturer-provided data services will shrink as users gain the practical ability to take their data elsewhere. This is exactly the competitive dynamic the Data Act is designed to create. US manufacturers need to think hard about how their value proposition in the EU market evolves in a world where they no longer have exclusive access to the data their products generate.

The most durable competitive position is one built on genuine value creation — superior product performance, superior analytics capabilities, superior integration with the user’s broader technology environment — rather than data lock-in. Manufacturers that have relied primarily on data exclusivity to maintain their service revenue may find the EU market increasingly competitive, while manufacturers who have built their services on genuine insight and user value may find that the Data Act’s framework actually strengthens their position by legitimizing the data economy in which they operate.