Ab dem 12. September 2026 gilt für neue vernetzte Produkte die „Access by Design“-Pflicht aus dem EU Data Act. Was nach Brüsseler Papierkram klingt, ist in Wahrheit eine Konstruktionsanforderung — und für viele Maschinen im Feld ein Problem. In diesem Artikel zeige ich, was Artikel 3 konkret verlangt und wie eine praxistaugliche Architektur dafür aussieht. Mit Bausteinen, die es komplett als Open Source gibt.
Was der Data Act verlangt
Artikel 3 des Data Act (Verordnung (EU) 2023/2854) ist erfreulich klar formuliert: Vernetzte Produkte müssen so konzipiert und hergestellt werden, dass der Nutzer — also der Betreiber der Maschine — auf die erzeugten Produktdaten zugreifen kann. Und zwar:
▪ einfach und sicher — kein Anruf beim Service-Techniker, kein Sonderprojekt ▪ unentgeltlich — das „Premium-Datenpaket“ gegen Aufpreis ist damit Geschichte ▪ in einem strukturierten, gängigen, maschinenlesbaren Format — inklusive der Metadaten, die man zur Auslegung der Daten braucht ▪ soweit technisch machbar: direkt und in Echtzeit
Dazu kommt Absatz 2, der gerne übersehen wird: Schon vor Vertragsschluss — beim Kauf, bei Miete oder Leasing — muss der Verkäufer offenlegen, welche Daten die Maschine erzeugt, in welchem Format, ob kontinuierlich und in Echtzeit, wo sie gespeichert werden und wie der Nutzer darauf zugreift. Das Datenblatt zur Maschine bekommt also ein Kapitel „Daten“.
Und der Nutzer entscheidet, wer mitliest: Nach Artikel 5 kann er verlangen, dass die Daten an Dritte weitergegeben werden — an den Instandhalter seiner Wahl, an einen Versicherer, an einen Energieberater. Der Hersteller selbst darf die Daten dagegen nur noch auf vertraglicher Grundlage nutzen.
Der Stand im Feld
Wer regelmäßig an Maschinen steht, kennt die Realität:
▪ Ein OPC-UA-Server ist vorhanden — aber nur der Inbetriebnehmer kennt die NodeIDs ▪ Die Daten liegen in proprietären Formaten der Steuerung ▪ Wer als Betreiber an seine eigenen Prozessdaten will, braucht den Service-Techniker des Herstellers ▪ Eine Dokumentation, welche Daten die Maschine überhaupt erzeugt? Fehlanzeige.
Genau dieser Zustand reicht ab September 2026 für neu in Verkehr gebrachte vernetzte Produkte nicht mehr aus. Ein OPC-UA-Server allein ist noch kein „Access by Design“ — es fehlen Nutzerverwaltung, definierte Datenprodukte, Dokumentation und die Möglichkeit, Dritten kontrollierten Zugriff zu geben.
Die Referenzarchitektur
Die gute Nachricht: Das ist kein Hexenwerk. Die Architektur, die ich hier vorstelle, besteht zu 100 % aus Open-Source-Bausteinen — und sie folgt konsequent dem Zonen-und-Conduits-Modell der IEC 62443. Wer meine Serie dazu verfolgt hat, erkennt das Muster wieder: Das Edge-Gateway aus der Security-Architektur kann beides.
Zone A — Die Maschine. Steuerung (S7, Beckhoff, B&R), Sensorik, OPC-UA-Server. Hier ändert sich nichts an der Maschine selbst — die Daten sind ja da, sie sind nur nicht zugänglich.
Conduit 1 — read-only. Der Übergang von der Maschine zum Edge-Gateway läuft ausschließlich lesend über OPC UA. Kein Schreibzugriff Richtung Steuerung. Der Datenzugang für den Betreiber darf niemals ein Einfallstor in die OT werden — Data-Act-Compliance und IEC 62443 sind hier keine Gegensätze, sondern zwei Seiten derselben Architektur.
Zone B — Das Edge-Gateway. Ein Industrie-PC oder LXC-Container direkt an der Maschine, mit drei Aufgaben: OPC-UA-Client mit sauberem Mapping von NodeIDs auf sprechende MQTT-Topics, MQTT-Publisher mit TLS und Client-Zertifikaten, Store & Forward als Puffer bei Netzausfall. Damit ist auch die Metadaten-Anforderung aus Artikel 3 abgedeckt: Das Topic-Mapping ist die Dokumentation der Datenpunkte.
Conduit 2 — nur ausgehend. MQTT über TLS 1.3 in die DMZ. Es gibt keine eingehende Verbindung in die Produktionszone.
Zone C — Das Datenzugangs-Portal. Hier passiert die eigentliche Data-Act-Arbeit, bei mir auf Frappe-Basis mit PostgreSQL:
▪ Rechteverwaltung: Der Betreiber legt Nutzer an und entscheidet, welche Drittpartei welche Daten sieht — Artikel 5, umgesetzt als Rollenkonzept ▪ Live-Daten: Dashboard je Maschine, in Echtzeit ▪ Export: REST-API, CSV, JSON — strukturiert, gängig, maschinenlesbar, kostenlos für den Betreiber ▪ Maschinen-Datenblatt: Automatisch generiert aus dem Topic-Mapping — genau das Dokument, das Absatz 2 vor Vertragsschluss verlangt
Was Hersteller jetzt tun sollten
- Bestandsaufnahme: Welche Daten erzeugen die eigenen Maschinen heute, und wo liegen sie? Ohne diese Inventur ist weder das Datenblatt noch der Zugang machbar.
- Datenprodukte definieren: Nicht jeder interne Diagnosewert muss raus — aber die Produktdaten, die beim Nutzer entstehen, gehören ihm zugänglich gemacht. Diese Abgrenzung (auch zu Geschäftsgeheimnissen nach Art. 4) sollte man bewusst treffen, nicht zufällig.
- Architektur festlegen: Edge-Gateway plus Portal als Standardkomponente in die Maschinenauslegung aufnehmen — einmal sauber gebaut, skaliert das über jede ausgelieferte Maschine.
- Vertriebsunterlagen anpassen: Das Daten-Kapitel im Datenblatt und die Zugangsbedingungen müssen stehen, bevor der nächste Vertrag unterschrieben wird.
Die schlechte Nachricht zum Schluss: Wer im September 2026 anfängt, darüber nachzudenken, liefert ab September nicht mehr konform aus. Die Vorlaufzeit für Konzept, Pilotmaschine und Doku liegt realistisch bei mehreren Monaten.
Fazit
Der Data Act zwingt Maschinenhersteller zu etwas, das gute MDE/BDE-Projekte seit Jahren tun: Maschinendaten raus aus proprietären Silos, rein in offene, dokumentierte Schnittstellen. Wer das als reine Compliance-Übung abarbeitet, verschenkt die Chance — denn dieselbe Architektur, die Artikel 3 erfüllt, ist die Basis für Condition Monitoring, Service-Verträge und datengetriebene Geschäftsmodelle.
Die Bausteine liegen bereit. Die Frist steht. Und die Demo läuft bei mir bereits.
Sie sind Maschinenhersteller und der Data Act steht bei Ihnen noch unter „schauen wir uns später an“? Sprechen Sie mich an — von der Bestandsaufnahme bis zur Pilotmaschine.
Quellen: ▪ Art. 3 Data Act im Wortlaut: https://data-act-law.eu/de/artikel/3/ ▪ Art. 5 Data Act (Weitergabe an Dritte): https://data-act-law.eu/de/artikel/5/