EU Data Act: What It Means for IoT System Architects

The EU Data Act (Regulation (EU) 2023/2854) gives the user of a connected product a legal right to the data that product generates, and a right to have it shared, on request, with a third party of their choosing. For a fleet operator running your gateways, that means the readings, runtime counters, and event logs coming off the machine are theirs to access and to move. For the OEM or integrator who built the system, it means the data path you designed is now a compliance surface, not just an engineering one.

The obligations that matter for architects are concrete: data has to be available to the user, where technically feasible, directly and in real time; it has to be shareable with a third party in a common, machine-readable format; and a switch to a new service provider cannot be blocked by contract or by design. If your only way to extract a year of CAN-bus telemetry is a CSV export a vendor runs for you on a quarterly cadence, you do not meet that bar.

Scope is narrower than the headlines suggest, and getting it right saves you from over-building. The Act covers data generated by the use of a connected product and its related service: sensor readings, GPS positions, drum-rotation counts, hours-run meters, fault codes, the diagnostic stream a machine emits in normal operation. It does not hand over your proprietary algorithms, your enrichment models, or data you derive through substantial investment downstream. Raw and lightly-processed device data is in; your analytics IP is not.

The user is whoever owns, rents, or leases the product, not necessarily the party that built it. On a leased crane or a financed concrete mixer, the operator running the asset can demand access even though the OEM put the telematics there. Architects who assumed the maker of the box also controls the data off the box need to revisit that assumption, because the regulation does not share it.

"Available to the user, where technically feasible, directly and in real time" is the line that closed-stack telematics struggles with. If device data lands only in a proprietary cloud and the user sees it through a portal the vendor controls, real-time direct access is something you have to ask for, and ask is exactly what the Act removes the need to do.

The architecture that satisfies this is the one good edge engineering already points to. Terminate protocols at an open gateway: J1939 on the drivetrain, Modbus on an auxiliary pump, OPC-UA on a line controller. Normalize on the device and publish over MQTT with store-and-forward buffering so a dropped link does not drop data. From there the same stream can fan out to your platform and to a user-owned endpoint without a second integration. Real-time access stops being a request to the vendor and becomes a topic subscription the user already holds.

The Act's switching provisions are aimed squarely at lock-in. A user can move to a different provider, and the incumbent has to support that move, in a structured, commonly-used, machine-readable format, without punitive fees and within defined notice periods. The practical test is simple: if your customer signed with a competitor tomorrow, how much of their data, history, and device configuration could they take, and how fast?

Build for that answer up front. Keep telemetry in open time-series storage (PostgreSQL with TimescaleDB rather than a closed cloud table you cannot export at volume). Define the wire format explicitly: timestamped JSON or a documented schema over MQTT, not an opaque binary only your decoder understands. Version device configuration in git so a gateway's behaviour is reproducible by whoever holds the repository. None of this is exotic. It is the difference between portability being a clause you comply with and a migration you can actually run.

The teams that will spend the least on the Data Act are the ones whose systems were already open. When the gateway runs Linux you control, the broker is Mosquitto, the store is yours, and the source is git-versioned and handed over, most of the regulation's demands are already satisfied as a side effect of how the system was built. Access, portability, and a clean exit are not retrofits; they are what an open edge stack does by default.

Closed platforms invert that. Every right the Act grants the user becomes a feature request to a vendor who has a commercial reason to slow it down, often priced per device or per export. The regulation is, in effect, a deadline on a decision many architects had been deferring: whether the field-data layer is something you own or something you rent. Designing for user access and portability now is cheaper than being compelled to bolt it onto a proprietary stack later, and it leaves you with an architecture that is better on its own merits.