On September 12, 2026, a second deadline inside the EU Data Act came into force. The Act itself has applied since September 2025, but this part is narrower and harder to fake: any connected product placed on the EU market after that date has to be designed so the data it generates is easily, securely, and directly accessible to the user, by default, without the manufacturer’s involvement, wherever that’s technically feasible. Germany has already named the Federal Network Agency as enforcement authority and attached fines of up to 4% of annual EU turnover. This isn’t a policy update. It’s an architecture requirement, and it lands squarely on anyone building a sensor, a wearable, a smart lock, or any other device that pairs to an app and phones home to a cloud dashboard.
What “access by design” actually rules out
Most connected hardware products today work the same way regardless of category. A device collects data, a companion app relays it over BLE, and the app ships it to the vendor’s cloud, where it lives behind an API the vendor controls. If a user wants their raw data, the options are usually a support request, a CSV export button buried three menus deep, or nothing at all. That flow technically involves the data holder in every access request, which is precisely what the new obligation is written against. “By default” and “without the data holder’s intervention” are doing real work in that sentence. A vendor portal that requires a ticket doesn’t clear it. Neither does an export feature the vendor can quietly deprecate.
This catches a lot of companies off guard because the data was never really hidden. It just required going through the vendor to get it. Under the new rule, that intermediation step is the violation, not a workaround for it.
Why this is a bigger deal for hardware than for SaaS
A web app can bolt on a data export endpoint without touching its core architecture. A connected device usually can’t, because the data path was built cloud-first from day one: sensor to phone to server, with the server as the canonical source of truth and the only place a full record exists. Retrofitting direct, local access onto that pipeline means either exposing new interfaces on hardware that’s already shipped and hard to update, or rebuilding the data model so the device or the paired app holds a complete, exportable copy instead of a cache. Neither is a quick patch. Both are cheaper if you plan for them before the product exists than after several hundred thousand units are already in the field running old firmware.
This is exactly the argument for treating connected products as local-first software from the start rather than thin clients for a vendor cloud. When the phone or the device itself holds the authoritative copy of a user’s data, and the cloud is a sync target instead of the source of truth, “access by design” is close to free. The user’s data is already sitting somewhere they control. You’re not building a new compliance feature. You’re exposing something that already exists.
The upside nobody’s advertising
We’d push back on the framing that this is purely a cost. A product built so users can pull their own sensor history off the device without asking anyone is also a product that survives you shutting down a backend, getting acquired, or changing your pricing model. It’s the same architecture, and it solves both problems at once. If a fitness band’s data lives only on a server you control, a user’s five years of step counts and heart rate readings evaporate the day you sunset the API, regardless of any EU deadline. If the same data has always been directly accessible from the app or the device, that risk doesn’t exist. Regulation forced the conversation, but the design decision behind it was already the right one for anyone who wanted their product to hold up over time.
There’s also a competitive angle worth being blunt about. Large IoT vendors with years of cloud-locked product lines are going to have a much harder and slower path to compliance than a company building something new. If you’re a founder shipping a first-generation connected product, you can build the access-by-design requirement into the architecture from the start for a fraction of what it will cost an incumbent to retrofit it into a decade of firmware.
What this means if you’re scoping a connected product now
Start the data model with the question the regulation is really asking: if the user asked for everything the device knows about them, right now, with no support ticket, could they get it. If the honest answer is “eventually, through our export tool,” the architecture needs to change before the product does, not after. Decide up front whether the device, the paired app, or both hold the canonical record, and treat the cloud as a sync and backup layer rather than the only complete copy. Build the export path as a first-class feature, not a settings-page afterthought, and test it the way you’d test any other core function, because regulators and users will both eventually try it.
None of this requires abandoning cloud services. Sync, backup, and remote features are still useful and often necessary. What changes is where the authoritative copy of the data lives and whether reaching it requires the vendor’s cooperation. Get that ordering right and the compliance question mostly answers itself.
If you’re scoping a connected product and want the data architecture right before you’re locked into hardware and firmware decisions, get in touch. It’s a much cheaper conversation to have now than after the first compliance audit.