A lot of what is written about the EU Data Act mixes two different things together: the obligations on manufacturers of connected products and providers of related services, and the architecture of European data spaces. They are related, but they are not the same thing, and confusing them leads organisations to either over-build or under-prepare.
So let’s separate them. This piece covers the core obligations in Chapter II of the Data Act, Articles 3, 4 and 5, and the obligations those create for everyone involved. The short version: none of them require you to join a data space. What they require is that data flows to the right party, on request, under the right conditions. How you make that happen is up to you. (Why a data space can make it much easier is the subject of the next piece.)
Three roles to keep straight
The Data Act’s connected-product rules revolve around three parties.
The user is whoever owns, rents or leases the connected product, or receives the related service. That can be a consumer, a farmer, a fleet operator, a factory.
The data holder is the party that has the right or obligation to use and make available the data the product generates, in most cases the manufacturer or the provider of the related service.
The third party, or data recipient, is whoever the user asks the data holder to share the data with: a repair shop, an independent service provider, an insurer, an analytics company, a competitor of the manufacturer in the aftermarket.
Most of the Data Act’s connected-product obligations are about the relationships in this triangle.
Article 3: design for access, and tell people before they buy
Article 3(1) is the “access by design” obligation. Connected products and related services have to be designed so that product data and related service data, “including the relevant metadata necessary to interpret and use those data”, are by default accessible to the user “easily, securely, free of charge, in a comprehensive, structured, commonly used and machine-readable format”, and where relevant and technically feasible, directly accessible.
This paragraph applies to connected products and related services placed on the market after 12 September 2026. That date has now passed. If your organisation is putting a new connected product on the EU market, access by design is no longer a roadmap item.
Articles 3(2) and 3(3) are the pre-contractual transparency obligations, and they already apply. Before a user buys, rents or leases a connected product, or signs up for a related service, they must be told, among other things, what type, format and estimated volume of data the product generates, whether it is generated continuously and in real time, where it is stored and for how long, and how the user can access, retrieve or erase it. For related services, the user must also be told whether the provider intends to use the data itself or let third parties use it, and for what purposes, plus the identity of the data holder and how to lodge a complaint.
In practice this means product and legal teams need an accurate, maintained inventory of what data each product actually produces. Many organisations discover they don’t have one.
Article 4: the user’s right to access
Where the user can’t access the data directly from the product, Article 4 requires the data holder to make readily available data, and the metadata needed to interpret it, available to the user “without undue delay, of the same quality as is available to the data holder, easily, securely, free of charge, in a comprehensive, structured, commonly used and machine-readable format”, and where relevant and technically feasible, continuously and in real time.
A few details matter a great deal in implementation.
The data holder may not make exercising this right “unduly difficult”, including through non-neutral choices or manipulative interface design. A buried request form or a deliberately confusing portal is a compliance problem, not just a UX problem.
The data holder may ask only for the information necessary to verify that someone is the user, and should keep logs of access only as far as needed for sound execution and security.
Trade secrets get protection, but not a veto. The data holder and user can agree proportionate confidentiality measures, and in exceptional cases the data holder can refuse or suspend sharing where it can demonstrate serious economic damage. Any such refusal has to be substantiated and notified to the competent authority.
And the user may not use the data to develop a product that competes with the connected product it came from.
Article 4 also runs in the other direction. The data holder may only use readily available non-personal product data on the basis of a contract with the user. The default of “we collected it, so it’s ours to use” no longer holds.
Article 5: the right to have data shared with a third party
Article 5 is where the Data Act becomes a market-opening instrument. At the request of the user, or someone acting on their behalf, the data holder must make the same readily available data available to a third party, “without undue delay, of the same quality as is available to the data holder, easily, securely, free of charge to the user”, in the same kind of format, and continuously and in real time where technically feasible.
Note the words “free of charge to the user”. The data holder may agree compensation with the third party, under the conditions of Articles 8 and 9: fair, reasonable and non-discriminatory terms, with compensation for SMEs limited to the costs of making the data available.
Article 5 also contains some sharp edges. Designated gatekeepers under the Digital Markets Act cannot be eligible third parties, and cannot solicit users to share data with them. The data holder may not use the data to derive insights about the third party’s economic situation, assets or production methods. Where personal data is involved, a valid legal basis under the GDPR is still required.
The obligations don’t stop at the data holder
Article 6 sets out what the third party must do once it receives data. It may process the data only for the purposes and under the conditions agreed with the user, and must erase it when no longer needed for that purpose. It may not use the data for profiling unless necessary for the service the user asked for, pass it to another third party unless agreed with the user, hand it to a gatekeeper, use it to develop a competing product, or disregard the confidentiality measures agreed for trade secrets.
Article 11 gives data holders remedies when those conditions are broken: the recipient must erase the data, may have to stop producing goods or services derived from it, and may owe compensation.
These are substantial obligations on the receiving side. Enforcing them is where things get difficult, and it’s the part most implementations underestimate.
What none of this requires
None of Articles 3 to 6 requires you to join a data space, run a connector, or adopt a specific protocol. The Data Act is technology-neutral here. You could meet these obligations with a well-designed customer portal, a documented API, and a solid contract framework.
What the Data Act does require is that the outcomes are real: users can actually get their data, third parties can actually receive it, requests are handled without undue delay, and the conditions attached to each transfer are respected.
For a data holder with a handful of users and a couple of known third parties, a bilateral approach can work. For a manufacturer with tens of thousands of users, each of whom can nominate any third party they like, the question stops being “can we send the data” and becomes “how do we know who we’re sending it to, whether they are authorised, and whether they’ll respect the terms”. That is the question data spaces were designed to answer, and it’s where we’ll pick up next.
A practical note: this piece describes the legal text, not legal advice for your situation. Several details, including exemptions for micro and small enterprises, depend on your specific facts.