REP27 · Data Act · IoT manufacturers
Article 3(1) · access by design · related services
Most compliance work is paperwork applied after a product exists. The Data Act is not, and that is what makes it awkward. Article 3(1) requires connected products to be designed and manufactured so that the data they generate is accessible to the user by default, easily and securely, and where relevant directly from the device. A firmware team hears that differently from a legal team, and the companies that do this cheaply are the ones where both heard it at the same time. This page is written to be forwarded to engineering.
Access by defaultMachine-readableFirmwareAPIsDocumentation
Step one is the expensive one and it is also the one with the longest lead time, because it lands in firmware and in the cloud backend rather than in a policy document. Everything else follows from it in weeks.
| The wording | What it means in the build |
|---|---|
| Accessible by default | No paid tier, no support ticket, no special request to reach your own data |
| Easily and securely | Authenticated, documented, and reachable without reverse engineering |
| Free of charge | For the user's own access. Charges may exist only for third-party recipients |
| Comprehensive | The readings, not a summary view built for the app |
| Structured, commonly used, machine-readable | JSON, CSV, a documented API. Not a PDF, not a screenshot, not a dashboard |
| Where relevant, directly from the device | A local interface where the architecture allows it, not only through your cloud |
| Same quality as available to the holder | The resolution and frequency you use internally, not a downsampled copy |
| Metadata to interpret it | Units, timestamps, sensor identifiers, schema. Data nobody can read is not access |
Every sensor, every counter, every event, with frequency, retention and where it lands. Two days of work that everything else depends on.
Readings are the user's to reach; your models and scores are not. Draw that line in the data dictionary, not in a meeting.
A documented endpoint returning the readings in a machine-readable format, with the metadata to interpret them.
The user names a recipient; you deliver. Tokens, scopes and revocation, which is the same work you already do for integrations.
The pre-contractual information, in the manual and on the product page, in the languages you sell in.
If you have no entity in the Union, a written mandate so requests reach somebody who answers.
Retrofitting access into shipped firmware is the most expensive version of this project, and it is what happens when the design duty is discovered late.
European buyers, especially industrial ones, have started asking how a device satisfies Articles 3 to 5 before signing.
Penalties are set nationally and must be effective, proportionate and dissuasive. Where personal data is involved, the GDPR runs alongside.
Repairers and analytics providers are the intended beneficiaries. Blocking them is the behaviour the regulation was written to end.
Refusing access to a customer's own machine data reads badly, and increasingly it reads unlawfully.
Doing it at design time, once, for the next product generation. That is the whole argument for reading this now.
A connected device rarely has only one European obligation attached, and the overlaps are worth knowing before four teams solve them separately.
| Regulation | What it adds for a connected device |
|---|---|
| GDPR | Personal data in the readings: lawful basis, notice, and the Article 27 representative if you are outside the Union |
| Cyber Resilience Act | Security requirements, vulnerability handling and, from 11 September 2026, reporting of actively exploited vulnerabilities |
| GPSR | Physical safety and the Article 16 responsible person named on the product |
| Radio Equipment Directive | Where the device has a radio, including delegated acts on cybersecurity |
| Ecodesign and energy labelling | Where applicable to the product category, with their own documentation |
When this lands with a firmware or platform team, the same five objections come up. They are reasonable, and four of them have straightforward answers.
| The objection | The answer |
|---|---|
| "Our device has no capacity for a local API" | Then access is provided by the data holder on request. Direct access is required where relevant and technically feasible, not always |
| "Full-resolution export will cost bandwidth" | Data of the same quality available to you, delivered on request rather than streamed continuously. Design the export accordingly |
| "Customers will hand data to competitors" | Recipients cannot use it to develop a competing connected product, and gatekeepers are excluded outright |
| "Our schema is a trade secret" | Metadata needed to interpret the data has to travel with it. Genuine secrets are protected with safeguards, not by withholding units and timestamps |
| "We ship globally, not just to the EU" | Then the duty attaches to units placed on the Union market. Most teams build once rather than maintain two firmware lines |
The last row is the decision that quietly determines the cost. Maintaining a European variant of firmware and a rest-of-world variant looks cheaper in the sprint and is more expensive for the life of the product. Almost every manufacturer that has been through this ends up building the access route once, for everyone, and treating the regulation as a specification rather than a jurisdiction.
Retrofitting is hard and sometimes impossible. Where direct access cannot be added, the data holder route under Article 4 carries the obligation.
This is the cheap moment. Adding an authenticated export to a design that has not shipped costs a fraction of adding it later.
Portals and apps are easier to change than firmware and are usually where the first compliant export appears.
The pre-contractual information can be written this month regardless of where the engineering stands, and it is what a regulator sees first.
Design the product so the user can reach its data by default, easily, securely and in a machine-readable format, directly from the device where that makes sense. Publish what the product generates before the sale. Build a route for the user to obtain the data and a route to send it to someone they name. Keep your inferences; hand over the readings. And if no entity of yours is established in the Union, sign the representative mandate so requests arrive somewhere that answers within a deadline rather than at an inbox in another time zone.
The most common reason a connected product company is late is not disagreement, it is that nobody is responsible. The work spans four teams and belongs entirely to none of them.
| Team | What they own here |
|---|---|
| Firmware and hardware | Whether data can be read from the device, and at what resolution |
| Platform and cloud | The export endpoint, authentication, third-party transmission and rate limits |
| Product and documentation | The pre-contractual information, the manual and the product page |
| Legal and compliance | Trade secret identification, safeguards template, terms with recipients |
| Commercial | What happens to aftermarket revenue when third parties can receive the data |
Name one owner across the five, give them a fortnight to produce the data inventory, and the rest becomes ordinary delivery work. Without that, each team assumes another has it, and the first request from a customer finds an organisation that has never discussed the question.
Partly, and deliberately. The regulation exists to open repair, maintenance and analytics around connected products, and that was the stated intention rather than an accident. What it does not permit is a recipient using your data to build a competing connected product, and designated gatekeepers are excluded from receiving it at all. The commercial answer that works is to compete on the service rather than on access to the machine's own readings, because the readings are no longer defensible ground.
Not the user, for their own data. With third-party recipients, reasonable and non-discriminatory compensation can be agreed, and for small recipients it is limited to the costs of making the data available. Pricing an export like a professional services engagement is the fastest way to attract a complaint, and the amounts involved rarely justify it.
This section exists to be forwarded. It is the regulation translated into work items, with no legal vocabulary in it.
| Work item | Acceptance criterion |
|---|---|
| Data dictionary | Every field the device produces, with units, frequency, retention and whether it is a reading or a derivation |
| Authenticated export endpoint | Returns readings for a date range in JSON or CSV, with a documented schema |
| Same resolution as internal | The export matches what internal analytics consumes, not a downsampled copy |
| Local access where feasible | A documented route to read data from the device without our cloud, where the architecture allows |
| Third-party delivery | The user authorises a recipient; tokens are scoped and revocable |
| No paywall on own data | Access is available on the base tier, without a support ticket |
| Deletion path | The user can delete data where the regulation allows, with confirmation |
| Documentation | Public API docs a competent integrator can use without contacting support |
Everything on that list is ordinary product work. What makes it a compliance project is discovering it after the hardware has shipped, which is why the eight rows are worth reading now rather than in a year.
Design so the user can reach the readings, say so before the sale, build a route to send them to a third party the user names, keep your derivations, protect genuine secrets with safeguards rather than refusals, and if no entity of yours is established in the Union, sign the representative mandate so requests reach somebody who answers. The regulation is demanding at design time and undemanding afterwards, which is the opposite of most compliance work and the reason it rewards acting early.
Yes. Article 3(1) requires products to be designed so that data is accessible to the user by default. It is not a documentation exercise.
Structured, commonly used and machine-readable, with the metadata needed to interpret it, at the same quality available to you.
No. Access by the user is free. Compensation is possible only with third-party recipients, on the regulation's terms.
Where relevant and technically feasible, yes, directly from the product. Where it is not, the data holder makes it available on request.
No. Data you inferred or derived from readings stays yours.
Identify them, propose safeguards, and refuse only in the exceptional cases the regulation allows, with reasons.
Yes, at the user's request, to a recipient they name, subject to the limits on gatekeepers and competing products.
Largely, from the sharing obligations, with a transitional position for enterprises that recently grew beyond the threshold.
Yes. Business users have the same access rights, and industrial data is often entirely non-personal, so only the Data Act applies.
Then direct access from the product is the route, and the design duty applies just the same.
If no entity of yours is established there, yes: a written mandate under the regulation, separate from Article 27 GDPR.
They apply together. The CRA governs security of products with digital elements; the Data Act governs access to the data they produce.
You can set fair, non-discriminatory conditions, but you cannot contract away the right itself. Unfair unilateral terms are not binding.
Third parties cannot use data received to develop a competing connected product. That limit is in the regulation.
The obligations attach to products placed on the market and to related services, with design duties applying to products placed on the market after the relevant dates. Check the phasing for your category.
Set by Member States, effective, proportionate and dissuasive, with GDPR penalties running alongside for personal data.
Signed within 24 hours of an intake call confirming your role and the Member State.
Product design, building the export, negotiating with recipients, and legal advice on national implementing measures.
Related: what users can obtain · the representative mandate
Europe Services, SE in Prague as your Data Act representative, so that user and authority requests reach a desk in the Union while your team builds the access route.
Request this service