The EU Data Act and connected products: what access by design means for your device
Connected products placed on the EU market after 12 September 2026 must be designed so users can get at the data they generate. Who is caught, what the rule asks for, and what it means for firmware, cloud and the sales process.

- Insights
- 25 October 2026
- 4 min read
For most connected products, the data a device generates has in practice belonged to whoever built the cloud it reports to. The owner of a machine could see a dashboard, but getting the raw data out, or handing it to another service company, was up to the manufacturer. The EU Data Act changes that. Its rules have applied since 12 September 2025, and from 12 September 2026 a new obligation, access by design, applies to connected products and related services placed on the EU market after that date (Withers; JD Supra).
Who is caught
A connected product, in the Act's terms, collects data about its use or environment and can transmit it: smart appliances, industrial machinery, medical devices, wearables and connected vehicles are all examples. Products whose main job is to store or move other people's data, such as servers and routers, are excluded, and so are prototypes (JD Supra). Related services are covered too: digital services that exchange data both ways with a product and affect what it does, such as remote start or predictive maintenance alerts.
Location does not help. A product made outside the EU by a non-EU company is covered if it is sold in the EU. A South African or UK manufacturer exporting connected equipment to Europe is in scope.
There is relief for the smallest companies. Micro and small enterprises are exempt from the connected-product obligations, provided they have no partner enterprise, are not linked to a larger one and are not making the product as a subcontractor. A medium-sized enterprise is exempt for a product's first year on the market (BIPT).
What access by design asks for
Product data and related service data, including the metadata needed to make sense of it, must be easily, securely and freely accessible to the user, in a structured, commonly used, machine-readable format. Where it is technically feasible, users must be able to get it directly from the product. Where it is not, the manufacturer must offer another route, such as a way to request it (Withers).
Users can also ask for their data to be shared, without undue delay, with a third party of their choosing, such as an independent repairer or a service provider. That third party may not use it to build a competing product (JD Supra). Before a sale, buyers must be told what data the product generates, in what format and volume, how it is stored and for how long, and how they can manage it (Withers).
What it means for the design
The data model has to be written down. If users are entitled to the data and to the metadata needed to interpret it, then units, timestamps, sampling rates, calibration and the meaning of every field must be documented in a form an outsider can use. Many products have never needed this, because the only consumer of the data was the manufacturer's own app.
There has to be an export path. For most products that means an API or a download in a standard format, with authentication that ties each user to their own devices and nothing else. For some, direct access on the device itself, over a local connection, will be the feasible route.
The user needs a definition in your system. The company that owns a machine, the one that leases it and the operator who runs it may all be different, and the Act's rights follow the user. Your access controls have to model that, including what happens when a device is sold or a lease ends.
Third-party sharing has to be built as a feature. A user can direct you to share their data with a service provider, which means a way to grant, scope and revoke that access, and a log of who received what.
The pre-sale information has to stay true. A product page that lists data types, formats, storage and retention needs engineering to confirm it, and needs updating when a firmware release changes what is collected.
Retention needs a setting. If you tell buyers how long data is kept and how they can manage it, the platform has to enforce those periods.
Where to start
If you sell, or plan to sell, connected products into the EU, begin with an inventory: every data point each product generates, where it is stored, who can see it today and in what format. Then decide the export route, the user model and the sharing mechanism, and build them into the next hardware or firmware revision instead of bolting them onto the current one. Products placed on the market before 12 September 2026 are not caught by the design rule, though their users have been able to request their data since September 2025, and your next revision will be caught.
We are engineers, not lawyers, so take legal advice on your own obligations. If you need the data model, the export path and the access controls built, send us a brief, or write to hello@handee.co.za.
EU Data Act
Design for access, not export
Design for access, not exportTell us what your product collects and where it is sold. We will work out what access by design means for your firmware and cloud.
- 01A working slice of device, cloud and dashboard, validated against real hardware
- 02Senior engineers who own the architecture and every decision
- 03An honest view on what to prove first, and what can wait
What happens next
- 01We read your briefWe come back to you with the questions that will shape the prototype.
- 02A first callWe talk through the problem, the hardware, the data and what success looks like.
- 03A clear proposalScope and cost for the prototype phase, so you know exactly what you're committing to.