Data Act Access by Design: The ERP Question Hiding Behind the IoT Label

A machine builder in the Hunsrück region is three months out from launching a new generation of connected equipment. The production schedule is set, the first units ship in the autumn, and the control-system supplier has already answered the compliance question in one sentence: “Access by design? We will do that on the PLC.” Everyone in the room nods, because it sounds like a firmware setting and firmware is the supplier’s department.

The question nobody asks out loud is the one that decides the cost: who grants the user access, and who keeps the data structured and available, when that same machine is connected to a new ERP system three years from now? The answer is not in the firmware. And from 12 September 2026 it has to exist before the product ships, not after.

The Wrong Drawer

In the Mittelstand, the German term for the family-owned mid-sized companies that form the industrial backbone of the German-speaking market, the Data Act lands in the wrong drawer almost by reflex. Connected product, sensors, telemetry: that reads as an IoT topic, and IoT reads as someone else’s problem.

The text says otherwise. Article 3(1) of Regulation (EU) 2023/2854, the Data Act, requires that connected products be designed so the data they generate is, by default, easily, securely, and where relevant directly accessible to the user, in a commonly used, structured, machine-readable format. The DIHK, the umbrella body of the German chambers of commerce, frames the September 2026 stage the same way: devices have to be built so the data is available directly and automatically, without a detour through the manufacturer.

Read that obligation closely and the IoT label starts to peel off. “Directly accessible to the user” is a statement about access control, while “structured, machine-readable format” describes a data model that someone has to define and hold stable. Neither of those lives on a sensor. Both live wherever your product data is administered and served under access rules, which in almost every machine builder is the layer made of ERP and MES, plus an integration platform.

Where the Obligation Actually Hangs

The data is generated at the machine. Administering it and then serving it in the required format to whoever is authorised to see it is backend work.

That distinction is not a matter of taste. Articles 4 and 5 of Regulation (EU) 2023/2854 carve out trade secrets and define when a data holder may withhold or condition access. A carve-out implies a filter, and a filter implies a permission regime that decides, per request and per field, what a given user is allowed to see. You cannot express that logic in a PLC that only knows torque and cycle count. You express it in a role and authorisation model, which is exactly what an ERP or MES already maintains for every other class of business data. KPMG places the Data Act squarely in the governance-and-architecture category for connected products, not in the firmware category.

So the practical question is not “can the machine emit the data.” Most modern machines already do. The question is who holds the contract with the user, maps each request to a permission, and then guarantees the format stays stable across firmware revisions and integration projects. That owner sits in the data backbone. This is the same architecture problem I keep meeting in requirement engineering and interface work, where the question of which system owns a data flow is settled far too late, usually after the route has already been built twice.

Why September, and Why the Date Splits in Two

There are two dates, and conflating them is the second most expensive mistake after the wrong drawer.

The Data Act became generally applicable on 12 September 2025. That stage governs duties around data already being generated, such as access on request. The design obligation under Article 3(1) is governed separately by the transitional regime in Article 50: it applies only to connected products placed on the market after 12 September 2026. Greenberg Traurig spelled this out for manufacturers in September 2025: there is no retrofit duty for installed machines, but every new product after that autumn date needs the access architecture built in from the start.

Germany has put teeth behind it. The Data Act implementation act, the Datenverordnung-Anwendungs-und-Durchsetzungs-Gesetz or DADG, was passed by the Bundestag on 26 March 2026 and entered into force on 30 May 2026. It names the Bundesnetzagentur as the central enforcement authority, and Section 15 DADG sets out administrative offences carrying fines of up to 500,000 euros within that authority’s remit. The clock is therefore not abstract. A product placed on the market in October 2026 without a working access path is exposed under a statute that is already in force.

What Actually Has to Be Done

This is an ownership decision before it is a technical project. Three moves, in sequence, starting twelve weeks before a launch.

Decide ownership first. Name the person and the system responsible for the Article 3 data provision. That owner is the IT or ERP side, with the control-system supplier as a contributor, not the sole holder. If the only answer in the room is “the supplier handles it on the PLC,” the obligation has already been misfiled.

Fix the interface in the backbone next. Map where the data is generated, where it is held in structured form, and which API serves it to the user in a machine-readable format. Document that route before the product ships, because Article 3(1) demands the access exists by design, which means by launch, not on first request.

Then put the trade-secret limit where it belongs. Model the Article 4 and 5 carve-out in the ERP or MES authorisation scheme, not in the firmware. A limit expressed in the backbone is maintained once and inherited by every downstream integration. A limit hard-coded into a machine control has to be rebuilt for each new connection, which is the duplicated-effort trap I described in the case for keeping data sovereignty in your own backbone. Clean source data is the precondition for any of this to work at all, a point I have made at length on why projects fail at the data-preparation stage.

What the Compliance Reflex Does Not See

The fair objection to all of this is that I am overstating the ERP team’s role. A control-system supplier could reasonably argue that modern machines already expose their data over a standard industrial protocol, and that exposing data and complying with the Data Act are the same act. For pure telemetry on a single, isolated machine, that argument almost holds.

It stops holding the moment a second party enters the picture. The Data Act is about provision to a defined user under defined conditions, with a trade-secret filter and a format guarantee that must survive the product’s whole service life. A PLC has no concept of who the user is, and no way to hold a stable format commitment across firmware updates. So the limit of my position is narrow and worth naming: where access is genuinely a one-machine, one-protocol, no-conditions case, the supplier route can be sufficient. That case is rare in a connected product line that will be integrated and re-permissioned across new owners over years.

The thesis holds for the same reason it started. The Data Act phrases the duty in terms of users, permissions, and formats, and those three words name backend functions, not sensor outputs. Filing the obligation with the control-system supplier does not make it cheaper. It defers the real work to the first ERP migration or platform integration that touches the machine, and then charges for it again every time after that. The reasoning behind a related vendor-gateway shift sits in my piece on SAP’s API policy and what it means for integration, where the same pattern, control over the data flow moving to the wrong layer, plays out from a different direction.

Frequently Asked Questions About Data Act Access by Design

Does the Data Act apply to machines we have already sold?

No. The access-by-design obligation in Article 3(1) of Regulation (EU) 2023/2854 applies only to connected products placed on the market after 12 September 2026. Installed machines already in the field are not covered, and there is no retrofit mandate. The general applicability of the Data Act from 12 September 2025 governs other duties, such as access to already available data on request, not the design obligation.

Does the obligation sit with the machine or control-system supplier, or with us?

The data is generated at the machine, but Article 3(1) requires structured, secure, machine-readable provision to the user, which is a permission and interface logic in the backend (ERP, MES, integration platform), not a firmware feature. Park it with the control-system supplier alone and you anchor a standing requirement in the wrong system, then pay for it again at every integration.

Do we really have to hand over all our data, including trade secrets?

No. The obligation covers the product and service data generated by the connected product and its related service, not your entire corporate data estate. Articles 4 and 5 of Regulation (EU) 2023/2854 set the trade-secret limit, and a blanket refusal is permitted only in exceptional cases. That limit belongs in the backend permission model, not in the machine control.

What does access by design have to deliver in concrete technical terms?

The user must be able to access the generated data by default, easily, securely, free of charge, and in a commonly used, structured, machine-readable format, directly from the product or through a related service where technically feasible (Article 3(1)). In practice that means a documented interface, a permission concept, and a format standard, all fixed before the product reaches the market.

Who enforces the Data Act in Germany, and what happens on breach?

The German Data Act implementation act (DADG) entered into force on 30 May 2026, following the Bundestag resolution of 26 March 2026. The Bundesnetzagentur (Federal Network Agency) is the central enforcement and coordination authority. Section 15 DADG provides a catalogue of administrative offences with fines up to 500,000 euros, within the scope of the agency’s competence.

Next step

Who in your house actually owns the Article 3 data path, and is it the right system?

I am happy to sit down with you and your product and ERP teams, walk the data route for one connected product line, and pin the access obligation to the system that should hold it before the September deadline forces the decision for you. No pitch, no deck.

Write to me to book a free initial consultation. If you would rather read more first, the groundwork sits under IT strategy and system selection and requirement engineering and interfaces.

Sources and links: Regulation (EU) 2023/2854, Art. 3(1) (13 December 2023) · Data Act, Art. 4 and 5 (13 December 2023) · DIHK: Data Act next stage from 12 September 2026 · European Commission Data Act FAQ (2025) · Greenberg Traurig: Action required for connected devices (September 2025) · Heuking: Bundestag passes DADG (26 March 2026) · Haufe: DADG in force (30 May 2026) · HÄRTING: Section 15 DADG, fines up to 500,000 euros · KPMG: Data Act governance for connected products

Further reading on pfisterer.xyz: SAP’s API policy and the integration question · Cloud Exit in the Mittelstand · Why projects fail at the data-preparation stage