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, September 12, 2026 is your next hard deadline. From that date, all new connected products placed on the EU market must 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, with a phased implementation. The September 2026 deadline marks the point where product design requirements become mandatory. If your connected product generates data during use, users must be able to access that data “easily, securely, free of charge, in a comprehensive, structured, commonly used and machine-readable format, continuously and in real time.”
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 will need 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 must be gradually eliminated (fully by 2027). 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.
Preparing for September 2026
Now (Q1 2026): Audit every connected product you sell in the EU. Map the data each product generates. Identify gaps between current data access capabilities and Data Act requirements.
Q2 2026: Design and build data access APIs. Implement authentication, authorization, and third-party delegation. Build data export pipelines.
Q3 2026: Test data access with real users and simulated third-party integrations. Update product documentation and privacy notices. Train support teams on Data Act requests.
September 12, 2026: All new products on the EU market must comply. Existing products are not retroactively covered, but any new version or significant update resets the clock.
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.
