Regulations •

EU Data Act: data access for connected products and what changes on 12 September 2026

From 12 September 2026, every connected product newly placed on the EU market must be designed so users can reach their data directly. What Regulation (EU) 2023/2854 requires, where trade secrets stop it, and how the Data Act differs from the digital product passport.

Author: myDPP Team

EU Data Act: data access for connected products and what changes on 12 September 2026

European product law now gives two completely different answers to the question “who owns a product’s data”. The digital product passport answers it for static data: materials, origin, repairability, conformity — facts the manufacturer establishes and publishes through a data carrier for consumers, authorities and recyclers. The Data Act answers it for dynamic data: run hours, fault codes, sensor readings, consumption profiles — everything that only comes into existence when someone uses the product. The two regimes cover the same device from opposite directions.

Regulation (EU) 2023/2854 has applied since 12 September 2025. The decisive second step lands now: from 12 September 2026, every connected product newly placed on the market must be designed so that the data it generates is, by default, easily, securely and free of charge directly accessible. That is no longer a duty to answer requests — it is a design requirement, and it falls on product engineering rather than the legal department. This article sets out what applies from that date, where the limits sit, and where the Data Act overlaps with the digital product passport.

Key takeaways

  • The Data Act is Regulation (EU) 2023/2854. It entered into force on 11 January 2024 and has applied directly in every member state since 12 September 2025 — no national transposition needed.
  • Access on request has applied since 12 September 2025. Users can ask for the product data their use generates (Article 4) and require the data holder to pass it to a third party (Article 5) — an independent repairer or a maintenance provider, for instance.
  • Access by design starts on 12 September 2026. Article 3(1) covers connected products and related services placed on the market after that date: the data must be directly accessible by default, where relevant and technically feasible. A request-and-approval portal no longer satisfies it.
  • Products already on the market are outside Article 3(1). They stay under the access-on-request regime. The cut-off attaches to placing on the market, not to the sale to the end customer.
  • Trade secrets are not a blanket refusal ground. They must in principle be disclosed where the data holder and the recipient agree proportionate technical and organisational safeguards. Refusal is possible only in narrow circumstances and must be reasoned.
  • Micro and small enterprises are exempt. Under Article 7, Chapter II does not apply to products and services of enterprises with fewer than 50 staff and no more than EUR 10 million turnover or balance sheet total — unless they are linked to a larger enterprise or act as a contract manufacturer.
  • Enforcement is national. Each member state designates competent authorities and sets penalties. Germany’s Data Act implementation act (DA-DG) has been in force since 30 May 2026 and names the Bundesnetzagentur as coordinating authority.
  • The Data Act does not replace the digital product passport. It governs usage data and access rights; the DPP governs product master data and publication duties. Meeting both means a data model that keeps them cleanly apart.

What the Data Act regulates — and what it does not

The Data Act is not a data protection law. It does not decide whether personal data may be processed — that stays with the GDPR, which applies alongside it and prevails in a conflict. The Data Act decides something else: who may access the data a product generates in use, and on what terms.

Four blocks sit inside the regulation:

  • Chapter II — access to product data. The core for manufacturers of connected devices. Users get access to the data their use generates and can pass it on to third parties.
  • Chapters III and IV — fair terms. Where data is made available under a legal obligation, the terms must be fair, reasonable and non-discriminatory (FRAND). Unilaterally imposed unfair contract terms between businesses are not binding.
  • Chapter V — public sector access. Public bodies can request data in situations of exceptional need, such as emergencies.
  • Chapter VI — switching between cloud services. Providers must enable a move to another service. Switching charges are being phased out and may no longer be levied from 12 January 2027.

What the regulation does not create is ownership of data. It grants access rights, not a property position. And it does not let the user turn the data into a competing product — that prohibition is written into the text.

Connected product, data holder, user: the three terms everything hangs on

A connected product is any item that obtains, generates or collects data about its use or environment and can communicate that data through an electronic communications service, a physical connection or on-device access. That is broader than most companies first assume: vehicles, agricultural machinery, production lines, lifts, heat pumps, household appliances, medical devices, wearables — and expressly machines that only release their data through a local service port.

Excluded are items whose primary function is storing, processing or transmitting data on behalf of someone else: servers, routers, cameras acting purely as transmission devices. What matters is whether collecting data is a by-product of the real function or is the function itself.

The data holder is whoever has the right or the practical ability to use the data — usually the manufacturer, sometimes the operator of the cloud platform. The user is whoever owns, rents or leases the product. With capital goods that is frequently neither the manufacturer nor a consumer but a business in between. A company that cannot map these three roles across its own product fleet cannot meet the obligations.

Two data regimes, one product: Data Act and DPP compared

Data Act (2023/2854)Digital product passport (ESPR)
Type of dataUsage data: sensor values, run hours, fault codesMaster data: materials, origin, repairability, conformity
OriginContinuously, during operationBefore placing on the market, static until updated
Entitled partiesThe user and third parties the user namesConsumers, authorities, recyclers, distributors — by access tier
Access routeOn the device or through an interfaceData carrier on the product (QR code, GS1 Digital Link)
TriggerAn access request, or the design dutyA delegated act for the product group
TimingSince 12.09.2025; access by design from 12.09.2026Product group by product group from 2027 (textiles first)
Public?No, bilateral between entitled partiesPartly, through tiered public access

The practical point: both regimes need the same foundation — an unambiguous product identity and a maintained data model — but they answer different questions. Merging them into one field catalogue produces a data set that satisfies neither the user nor market surveillance.

What has applied since 12 September 2025

Access on request (Article 4)

The user can ask for the readily available product and related service data — without undue delay, in the same quality and format the data holder holds it in, free of charge and, where technically feasible, continuously and in real time. “Readily available” means raw and pre-processed data the data holder can obtain without disproportionate effort. Derived analytics that embed the holder’s own know-how are outside it.

Sharing with a third party (Article 5)

At the user’s request the data holder must transmit the data to a nominated third party. This is the provision with the largest market effect: it opens up to independent workshops, maintenance providers and analytics firms a data channel manufacturers used to control. In that sense the Data Act completes the right to repair on the data side. Gatekeepers under the Digital Markets Act are excluded as recipients.

Fair terms and FRAND (Chapters III and IV)

Where a company makes data available under a legal obligation, the terms must be fair, reasonable and non-discriminatory. Towards consumers, and towards micro and small enterprises, no compensation beyond the costs of making the data available may be charged. Unilaterally imposed, unreasonable data-access clauses are not binding between businesses.

Switching cloud providers (Chapter VI)

Providers of data processing services must enable a move to another provider or to on-premises infrastructure, within contractual deadlines and without technical obstacles. Switching charges are being withdrawn in stages and may not be charged at all from 12 January 2027. This matters to manufacturers because device telemetry usually sits with a hyperscaler.

What changes on 12 September 2026: access by design

Article 3(1) requires that connected products and related services be designed and provided so that product data and related service data are, by default, easily, securely, free of charge, in a comprehensive, structured, commonly used and machine-readable format, and — where relevant and technically feasible — directly accessible to the user.

The shift from the current position is fundamental:

  • Until now: the user asks, the manufacturer supplies. A service portal with a request form and a processing time is enough.
  • From 12.09.2026: access has to be built into the product. No application, no unlocking, no manufacturer software as the only route in.

The date attaches to placing on the market. Products first made available on the Union market before then stay under the old regime, even if they continue to be sold afterwards. For product planning that means every series whose production start falls after 12 September 2026 has to ship with the interface. Retrofitting is rarely economic on devices with long development cycles, which is why the decision is in practice already being made inside current engineering projects.

The qualifier “where relevant and technically feasible” is not a way out. It permits gradation for devices with no display and no permanent connection, but it requires a documented justification. Anyone relying on it should record the assessment in writing — in a dispute it is the only evidence.

Which data is covered — and where the line runs

Covered are the raw and pre-processed data the product generates or collects in use: operating hours, temperatures, fill levels, cycle counts, fault and diagnostic codes, location data, consumption values.

Not covered:

  • Derived or inferred data that embeds the holder’s own algorithms, models or assessments. The raw output of a vibration sensor has to be handed over; the remaining-life score calculated from it does not.
  • Data that is not readily available, meaning it could only be obtained with disproportionate effort.
  • Content unrelated to the use of the product.

On trade secrets the common expectation is wrong. They are not an exclusion: protected information must in principle be disclosed provided the data holder and the recipient first agree proportionate technical and organisational safeguards — confidentiality agreements, access restrictions, technical containment. Refusal is exceptional, must be reasoned, and must be notified to the competent authority. A company with no classification of which data fields carry trade secrets cannot realistically use that exception.

Pre-contractual information duties

Article 3(2) and (3) move part of the obligation forward in time. Before a user buys, rents, leases or subscribes to a connected product or related service, they must be told in clear and comprehensible language:

  • the type, format and estimated volume of data the product is likely to generate,
  • whether the data is generated continuously and in real time,
  • how it is stored and for how long,
  • how the user accesses it and can have it erased,
  • who the data holder is, with identity and contact details,
  • whether the data holder intends to use the data itself and whether it shares it with third parties.

These points belong in pre-contractual communication, not in a footnote to the terms and conditions — and they have to match what the device actually does. In practice they usually end up in a dedicated data sheet kept alongside the digital instructions for use.

Who is exempt: micro and small enterprises

Article 7 disapplies Chapter II to products and related services manufactured or provided by micro or small enterprises within the meaning of Recommendation 2003/361/EC: fewer than 50 staff and no more than EUR 10 million in annual turnover or annual balance sheet total.

The exemption falls away in two situations:

  • The enterprise has a partner or linked enterprise that is not itself a micro or small enterprise. A subsidiary in a larger group cannot rely on its own headcount.
  • The enterprise acts as a contract manufacturer or design subcontractor. Producing on behalf of a larger manufacturer puts the obligation back.

Medium-sized enterprises are not exempt. The widespread assumption that “SMEs are out” only holds for the lower half of the SME definition.

National enforcement: Germany as the example

The Data Act applies directly, but enforcement sits with the member states. Each designates competent authorities and sets penalties; the regulation only requires that they be effective, proportionate and dissuasive. Where personal data is involved, data protection authorities can apply the GDPR ceiling of up to EUR 20 million or 4 percent of worldwide annual turnover.

In Germany the Data Act Durchführungsgesetz (DA-DG), in force since 30 May 2026, allocates responsibility, and the Bundesnetzagentur acts as the coordinating supervisory authority and complaints contact point. Companies selling into several member states should establish early which authority leads for them — the allocation rules differ, and there is no one-stop-shop mechanism as under the GDPR.

What the Digital Omnibus would change — and what is not yet law

The Commission has proposed amendments to the Data Act as part of the Digital Omnibus package. Two points matter to manufacturers:

  • Stronger trade secret protection. Data holders would find it easier to refuse access requests where disclosure would expose protected knowledge to recipients connected to third countries without adequate protection.
  • Narrower public sector access. The broad “exceptional need” framework in Chapter V would be replaced by a narrower regime tied largely to genuine emergencies.

The planning point: the proposal does not touch the core data-access rules, and it has not been adopted. The 12 September 2026 date stands. Deferring the design obligation on the expectation of a softer regime means deferring it against the law in force.

Where the Data Act and the digital product passport converge

Four places where the two regimes meet concretely:

  1. Product identity. Both assume a device can be identified unambiguously. A company introducing the GS1 Digital Link for the DPP has the same key available for mapping telemetry.
  2. Repair and spare parts. The DPP supplies the repair instruction and the part number; the Data Act supplies the fault code out of the device. Only together do they add up to a usable repair process.
  3. Access tiers. The DPP works with graded access rights for consumers, authorities and recyclers. The Data Act requires comparable rights management for users and nominated third parties. Building them separately means running two permission systems for the same people.
  4. Data quality as the bottleneck. The most common reason both projects stall is identical: product data scattered across ERP, PIM, CAD and service systems. Why the data foundation comes before the interface is set out in DPP and PIM.

Six steps to prepare

1. Build a product inventory

List every series that obtains or transmits data, including those readable only through a local service port. Mark the planned or actual date of placing on the market for each. Everything after 12 September 2026 falls under Article 3(1).

2. Assign the roles

Determine, per series, who is data holder and who is user. With leasing, rental and operator models this is not trivial and is often set out in contracts differently from what the regulation assumes.

3. Classify the data fields

Separate raw and pre-processed data from derived outputs, and flag the fields containing trade secrets. Without that classification you can neither disclose confidently nor refuse with reasons.

4. Specify the interface

Define the direct access route: device interface, local API, open export function. Format structured, commonly used and machine-readable. Document where direct access is not technically feasible and why.

5. Draft the pre-contractual information

One data sheet per product family carrying the Article 3(2) and (3) points, agreed with sales and marketing so that it actually reaches the customer before the contract is concluded.

6. Update the contracts

Review supply, service and cloud agreements for clauses that restrict data access or impose unreasonable compensation. Such clauses are not binding between businesses and create liability exposure if they stay in use.

Five mistakes that get expensive

  • Treating the Data Act as an IT topic. Article 3(1) is a design requirement. It belongs in product development and in the specification, not in a compliance register.
  • Reading the cut-off as the date of sale. What counts is placing on the market, not delivery to the end customer.
  • Invoking trade secrets wholesale. Without field-level classification and an offer of safeguards, the argument does not hold.
  • Relying on the SME exemption. It only covers micro and small enterprises and disappears with group membership or contract manufacturing.
  • Merging DPP and Data Act into one data model. Static conformity data and live usage data have different update cycles, recipients and retention rules.

Frequently asked questions

Does the Data Act apply to machines with no internet connection?

Yes, if they collect data and can communicate it through a physical connection or on-device access. A machine tool whose operating data can only be read through a local service port is a connected product under the regulation. For the wider regulatory picture in machinery see the EU Machinery Regulation 2023/1230.

Do I have to retrofit products already on the market?

No. Article 3(1) applies only to connected products placed on the market after 12 September 2026. Older devices stay under the access-on-request duty in Article 4 — which has applied since 12 September 2025 and has to be met as well.

Can I charge for data access?

Not to the user. Compensation from a third party nominated by the user is possible but must be non-discriminatory and reasonable; towards micro and small enterprises it may not exceed the costs of making the data available.

How does the Data Act differ from the GDPR?

The GDPR governs the processing of personal data and the rights of data subjects. The Data Act governs access to data arising from product use, whether or not it is personal. Where it is personal, the GDPR applies in addition and prevails in a conflict.

Do I need a digital product passport to comply with the Data Act?

No — they are separate obligations on separate timelines. In practice both rest on the same foundation of unambiguous identification and maintained product data, which is why implementing them together makes sense. The starting point is the DPP implementation checklist.

What are the penalties?

Member states set them. They must be effective, proportionate and dissuasive; where personal data is involved, data protection authorities can apply the GDPR range of up to EUR 20 million or 4 percent of worldwide annual turnover. In Germany the Bundesnetzagentur is the coordinating authority.

Can myDPP satisfy the Data Act obligations?

myDPP manages product master data and the digital product passport — the static side. Telemetry from the device stays in your operational systems. What myDPP contributes is the unambiguous product identity and the data model that lets both worlds map to the same product; how that connects to ERP is described in the ERP integration guide.

Sources

Back to Knowledge Base