Your Users Own Their Data. The EU Is Making Sure of It.
If you build connected products, smart devices, or IoT systems sold in the EU, the deadline you were counting down to is already behind you. Every connected product placed on the EU market after September 12, 2026 has to incorporate “access by design” principles.
That’s not a suggestion. It’s law.
The EU Data Act (Regulation 2023/2854) entered into force in January 2024 and applies in phases. Most of it went live on September 12, 2025, which is when the duty to hand data over started. If your connected product generates data during use, users must be able to get that data “easily, securely, free of charge, in a comprehensive, structured, commonly used and machine-readable format, continuously and in real time.”
September 12, 2026 added the harder half. Products placed on the market after that date have to be designed so the data is directly accessible by default, rather than extracted on request through whatever back office you happened to have.
Every word in that quote is a technical requirement. Let’s unpack what it means for your product architecture.
What’s In Scope
The Data Act covers “connected products”: any tangible item that obtains, generates, or collects data concerning its use or environment and can communicate that data. That’s broad. It includes:
Smart home devices. Connected vehicles. Industrial machinery. Wearable devices. Smart appliances. Agricultural sensors. Energy monitoring systems. Connected medical devices. Basically anything with a sensor and a network connection.
“Related services” are also in scope. The mobile app that controls your smart thermostat. The cloud platform that stores your connected vehicle’s data.
The analytics dashboard for your industrial sensors. These must facilitate data access, not restrict it.
The regulation covers both personal and non-personal data. Raw sensor outputs. Pre-processed information. Metadata. Everything generated during product use.
The Core Requirements
Access by design
Products placed on the market after September 12, 2026 must be designed from the ground up to enable user data access. This isn’t something you can patch in later. It’s an architectural requirement.
Users and businesses that own or lease connected products get the right to access their data directly, at no additional cost. The data must be provided in real time where technically feasible, or without undue delay.
What “machine-readable” means in practice: JSON, CSV, XML, or any structured format that can be processed programmatically. Not a PDF report. Not a screenshot of a dashboard. Raw, structured data that third parties can ingest.
Third-party data sharing
Users can request that their data be shared with third parties. If your customer wants to send their connected vehicle data to an independent mechanic’s diagnostic system, you must enable that.
The third party can’t use the data to develop a competing connected product. But they can use it for compatible services, maintenance, repairs, and analytics.
No gatekeeping
You can’t make data access contingent on using your proprietary service. You can’t degrade the connected product’s performance if the user accesses data through third-party tools. You can’t charge for data access (beyond the marginal cost of data transmission).
Business Model Implications
Here’s where it gets uncomfortable for some companies.
If your revenue model depends on locking users into your data ecosystem (pay for premium analytics, pay for API access, pay to export your own data), the Data Act forces a rethink. User-generated data from connected products isn’t your proprietary asset anymore. It’s the user’s.
This hits hardest in industrial IoT. Machine manufacturers that sell “data-as-a-service” on top of connected equipment have to separate machine data access from value-added analytics.
Users get the raw data for free. Your analytics layer on top of it can still be a paid service. But the underlying data can’t be held hostage.
Smart home manufacturers face similar pressure. A user who buys a connected security camera owns the footage data. They can export it. They can share it with a third-party monitoring service.
The business opportunity, though, is real. Companies that embrace data openness can differentiate on the quality of their analytics, their UX, and their integration ecosystem. Walled gardens are a liability now. Open platforms win.
Technical Implementation
Data access APIs
Build RESTful APIs (or GraphQL endpoints) that expose product-generated data to authenticated users. Standard authentication (OAuth 2.0), structured responses (JSON), pagination for large datasets, and real-time streaming for continuous data (WebSockets or Server-Sent Events).
Document these APIs publicly. The Data Act expects that users understand how to access their data without needing your engineering team’s help.
Data format standards
Where industry-specific data standards exist, use them. MQTT for IoT messaging. OPC UA for industrial automation.
Matter for smart home interoperability. Don’t invent proprietary formats when open standards are available.
Real-time access
“Continuously and in real time” means your architecture needs to support streaming data access. For sensor data that updates every second, batch exports once a day don’t cut it.
Event-driven architectures work well here. Sensor readings go into a message broker (Kafka, RabbitMQ, MQTT broker).
Users subscribe to their data streams. Third parties with user authorization subscribe to the same streams.
Third-party authorization
Users authorize third parties to access their data. Your system needs an authorization layer that supports delegated access.
OAuth 2.0 with scoped tokens is the standard approach. Users grant specific third parties access to specific data categories for a defined duration.
Revocation must be immediate. When a user removes a third party’s access, data flow stops.
Data portability
Users can request a full export of their historical data. Build an export pipeline that aggregates all data from the connected product’s lifecycle and delivers it in a standard format. This could be a one-time download or an automated transfer to another service.
What About Trade Secrets?
The Data Act includes protections for trade secrets. You don’t have to expose proprietary algorithms, model weights, or manufacturing processes. But the data generated by the product during use belongs to the user.
In practice: the raw temperature readings from a connected industrial oven are user data. The predictive maintenance algorithm that analyzes those readings is your trade secret. Users get the data. You protect the algorithm.
Document clearly what constitutes a trade secret and why. Regulators will challenge overly broad trade secret claims used to restrict data access.
Cloud Service Provider Obligations
The Data Act also addresses cloud lock-in. Cloud service providers must provide tools for data export and service switching.
Switching charges drop to zero on January 12, 2027. Until then they can’t exceed the costs the provider actually incurs for the switch. Interoperability standards must be supported.
If you offer a cloud-based IoT platform, this applies to your service too. Users must be able to migrate their data and connected product configurations to a different platform.
You Either Shipped It or You Didn’t
There’s no preparation timeline left to hand you. September 12, 2026 has been and gone, so you’re reading this from one of two positions.
If access by design shipped, your next date isn’t an architecture problem. Chapter IV bans unfair contractual terms that one enterprise unilaterally imposes on another, and it has covered every contract concluded after September 12, 2025.
On September 12, 2027 it reaches backwards. Contracts signed on or before September 12, 2025 get pulled in too, if they run indefinitely or don’t expire until at least ten years out from January 11, 2024. Dig those agreements out now and read the data clauses.
And if it didn’t ship? Less dire than you’re bracing for, and less forgiving than you’d like.
Start with what the obligation actually attaches to. Article 2(22) defines “placing on the market” as the first making available of a connected product in the Union, which happens exactly once. Nobody is going to make you retrofit the units already sitting in your users’ hands, and a firmware push to those units doesn’t re-place them.
That reprieve is thinner than it sounds. Two reasons.
First, it covers the design duty and nothing else. Articles 4 and 5 have applied since September 12, 2025 to your connected products regardless of when they shipped. If a user can’t pull their data straight off the product, you still have to hand it over on request, and still have to pass it to any third party they nominate.
A portal. An export endpoint. A support queue that actually answers. Something.
Second, the reprieve is already spent. Anything you first make available on the EU market from here is in scope on day one, with no runway at all.
So the work is the same work, just without the calendar. Audit every connected product you sell in the EU and map the data each one generates. Find the gap between what a user can reach today and what Articles 3, 4 and 5 require.
Then build the access layer: authentication, third-party delegation, export pipelines. Test it against real users and a simulated third-party integration. Update your product documentation and the pre-contract disclosures Article 3(2) demands, and make sure whoever answers support can recognize a Data Act request when one lands.
For the broader EU regulatory landscape affecting your products, see our pillar guide on EU compliance for software teams. If your connected products process personal data (and most do), our GDPR architecture guide is essential reading. And for data residency considerations, check where to store your EU data.
Building connected products for the EU market? Let’s design your data access architecture together. We help IoT and connected product teams meet Data Act requirements without sacrificing competitive advantage.
