ZetrixwebWhat "access by design" actually requires
The Data Act has been partly in force since September 2025, but its access-by-design obligation for connected products takes effect September 12, 2026. The rule: where relevant and technically feasible, a connected product and any related service must be designed and manufactured so that product and service data are, by default, directly available to the user - in an easy, secure, comprehensive, structured, commonly used, and machine-readable format, and continuously and in real time where relevant.
What counts as a connected product
The Act's definition is broader than "IoT device" in the consumer-gadget sense:
Physical + connected
Any physical product that obtains, generates, or collects data about its use or environment and can communicate that data via a wired or wireless connection.
Explicit scope examples
Smartphones, tablets, wearables, smart vehicles, industrial and agricultural equipment, medical devices, and home appliances are all named categories.
Related services included
The companion app or cloud service that processes and displays the product's data is covered alongside the hardware itself - not a separate, exempt layer.
No home-market exemption
The obligation applies to all manufacturers placing connected products on the EU market and providers of related services, regardless of where they're established.
Where this actually lands on an engineering roadmap
For most teams, this isn't a single ticket - it touches firmware/telemetry design, the API layer that already exists for your own app, and the access-control model that decides who's "the user" for a shared or fleet-managed device. The practical work usually breaks into three pieces: identifying which telemetry already qualifies as "product data" a user generates by using the product, building or exposing a structured, machine-readable access path for it, and making sure that access path doesn't become a new attack surface - the Act asks for security in the same sentence as access.
Not sure whether your product's telemetry pipeline already satisfies "access by design," or where the gaps are? Get a free Data Act scoping review.
Why "where technically feasible" isn't a blanket exemption
Some coverage has treated the feasibility qualifier as an opt-out. It isn't one in practice: regulators and legal trackers read it as a constraint on implementation method, not on the obligation itself - a product that could reasonably expose structured access but chooses a design that makes it harder is not the intended reading of "not technically feasible." Building the access path in from the start is materially cheaper than retrofitting it once a customer or regulator asks why it doesn't exist.
| Data Act element | Status | What it requires |
|---|---|---|
| General provisions, contract terms, switching rules | In force since Sep 2025 | Fair contract terms for data sharing, cloud-switching support |
| Access by design for connected products | In force from Sep 12, 2026 | Default, structured, machine-readable, real-time data access for the user |
| Public-sector emergency data access | Already in force | Data holders providing data to public bodies in exceptional need |
Key takeaways
- From September 12, 2026, connected products and related services sold in the EU must give users default, structured, machine-readable access to the data they generate.
- Scope covers far more than consumer IoT - industrial equipment, medical devices, vehicles, and their companion apps are all named categories.
- "Where technically feasible" limits the implementation method, not the obligation itself - it isn't a general exemption.
- The rule applies to any manufacturer or service provider placing a connected product on the EU market, regardless of where they're headquartered.
- Building access-by-design into the telemetry architecture from the start is materially cheaper than retrofitting it later.