EU Data Act und LoRaWAN: Wem gehören Ihre Sensordaten?

Der EU Data Act dreht die Eigentumsfrage bei IoT-Daten um: Nicht mehr der Hersteller oder die Cloud-Plattform kontrolliert die Sensordaten, sondern der Nutzer (also der Betreiber) des vernetzten Produkts erhält ein Recht auf Zugriff, Nutzung und Weitergabe. Ab dem 12. September 2026 müssen neu in Verkehr gebrachte Produkte das technisch von vornherein ermöglichen (access by design). Diese Verschiebung trifft die Architektur eines LoRaWAN-Netzes im Kern: Wer als Betreiber auf einer fremden, intransparenten Cloud-Plattform sitzt, ist auf deren Datenbereitstellung angewiesen. Ein selbst kontrollierter, quelloffener ChirpStack-Stack legt Rohdaten, Payload-Decoder und Export-Schnittstellen dagegen von Anfang an in die eigene Hand. Dieser Beitrag ordnet ein, was der Data Act verlangt, wem die Daten gehören und warum Datenhoheit hier zum praktischen Compliance-Vorsprung wird. Stand: Juni 2026.

Inhaltsverzeichnis

• Was der EU Data Act regelt, und warum LoRaWAN-Betreiber betroffen sind
• Wem gehören die Sensordaten? Nutzer, Dateninhaber und die neue Datenlizenz
• Die Fristen: 12.09.2025, 12.09.2026 und das deutsche Durchführungsgesetz
• Access by design: was Artikel 3 und 4 technisch von einem IoT-Stack verlangen
• Cloud-LoRaWAN-Plattform vs. selbstkontrollierter ChirpStack-Stack
• Wie ein ChirpStack-Stack die Data-Act-Anforderungen praktisch erfüllt
• Bußgelder, Aufsicht und Geschäftsgeheimnisse: der Risikorahmen
• Checkliste: Was LoRaWAN-Betreiber bis zum 12.09.2026 vorbereiten sollten
• Fazit: Datenhoheit als Compliance-Vorsprung
• Quellen

Was der EU Data Act regelt, und warum LoRaWAN-Betreiber betroffen sind

Der EU Data Act ist die Verordnung (EU) 2023/2854 des Europäischen Parlaments und des Rates vom 13. Dezember 2023 über harmonisierte Vorschriften für einen fairen Datenzugang und eine faire Datennutzung. Sie trat am 11. Januar 2024 in Kraft (am 20. Tag nach der Veröffentlichung im Amtsblatt vom 22. Dezember 2023) und ist seit dem 12. September 2025 allgemein anwendbar. Im Kern regelt sie drei Dinge: den Zugang zu und die Nutzung von Daten aus vernetzten Produkten und zugehörigen Diensten, die Weitergabe dieser Daten an Dritte sowie den Wechsel zwischen Datenverarbeitungsdiensten (Cloud-Switching) und die Interoperabilität.

Genau hier sind LoRaWAN-Betreiber betroffen. Ein LoRaWAN-Sensor ist ein vernetztes Produkt im Sinne der Verordnung, und die Daten, die er erzeugt (Messwerte, Metadaten, Statusinformationen) sind Produktdaten. Ob Smart Metering, Asset-Tracking, Gebäudetechnik oder Umweltmessung: Sobald ein Gerät Daten produziert, die an einen Server fließen, entsteht eine Datenkette mit Rollen, Rechten und Pflichten. Die spannende Frage ist nicht mehr, ob diese Daten erhoben werden, sondern wer sie kontrolliert und wer sie herausgeben muss. Wer den grundsätzlichen Aufbau eines eigenen Netzes verstehen möchte, findet die Schritte im Leitfaden Privates LoRaWAN-Netzwerk aufbauen.

Hinweis: Dieser Beitrag ist eine technisch-organisatorische Einordnung und kein Rechtsrat. Für eine verbindliche Bewertung Ihrer Datenflüsse und Ihrer Rolle im Data Act ziehen Sie bitte Ihre Datenschutz- und Rechtsberatung hinzu.

Wem gehören die Sensordaten? Nutzer, Dateninhaber und die neue Datenlizenz

Der Data Act vermeidet bewusst den Begriff des Dateneigentums. Statt von Eigentum spricht er von Rechten, und das verschiebt die Logik grundlegend. Im Zentrum stehen zwei Rollen: der Nutzer und der Dateninhaber. Der Nutzer ist die natürliche oder juristische Person, die das vernetzte Produkt besitzt oder nutzt, im LoRaWAN-Kontext also typischerweise der Betreiber des Sensornetzes. Der Dateninhaber ist die Stelle, die rechtlich oder faktisch die Kontrolle über die erzeugten Daten ausübt, oft der Hersteller des Geräts oder der Anbieter eines zugehörigen Dienstes.

Die Neuerung: Der Nutzer erhält das Recht, die erzeugten Produkt- und Servicedaten zu nutzen und an Dritte weiterzugeben. Der Dateninhaber darf dieselben Daten für eigene Zwecke nur auf vertraglicher Grundlage verwenden, also auf Basis einer Vereinbarung mit dem Nutzer, die sich in der Praxis als Datenlizenz lesen lässt. Damit wandert die faktische Datenhoheit weg vom Hersteller oder der Plattform hin zum Betreiber. Für LoRaWAN heißt das: Der Betrieb einer eigenen oder verwalteten Network-Server-Instanz ist nicht nur eine Souveränitätsfrage, sondern entscheidet mit, wie einfach Sie Ihre Rechte als Nutzer tatsächlich ausüben können.

Um die EU-weite Datenweitergabe praktisch zu erleichtern, hat die Europäische Kommission unverbindliche, freiwillige Mustervertragsklauseln (Model Contractual Terms, MCT) und Standardvertragsklauseln (Standard Contractual Clauses, SCC) veröffentlicht, Mitte bzw. Ende November 2025 (19./20.11.2025), zunächst auf Englisch; Übersetzungen in alle EU-Sprachen sollen binnen rund drei bis vier Monaten folgen. Diese Muster sind eine Hilfestellung für die vertragliche Ausgestaltung der Datenlizenz, keine Pflicht.

Die Fristen: 12.09.2025, 12.09.2026 und das deutsche Durchführungsgesetz

Drei Daten strukturieren den Zeitplan. Erstens der 12. September 2025: Seit diesem Tag ist der Data Act nach Artikel 50 allgemein anwendbar, die meisten Pflichten gelten also bereits. Zweitens der 12. September 2026: Ab diesem Datum greift die Designpflicht aus Artikel 3(1). Sie gilt für vernetzte Produkte und zugehörige Dienste, die nach diesem Datum in der EU in Verkehr gebracht werden. Bestehende, bereits im Markt befindliche Produkte fallen nicht automatisch darunter, neue jedoch sehr wohl. Wer also 2026 oder später ein LoRaWAN-basiertes Produkt auf den Markt bringt, muss die Datenzugänglichkeit von vornherein einplanen.

Drittens die nationale Umsetzung in Deutschland. Das Data-Act-Durchführungsgesetz (DA-DG) wurde am 26. März 2026 vom Bundestag beschlossen, am 29. Mai 2026 als BGBl. 2026 I Nr. 157 verkündet und ist seit dem 30. Mai 2026 in Kraft (dem Tag nach der Verkündung). Es regelt vor allem die Zuständigkeit der Behörden und die Sanktionen, ändert aber nichts an der EU-weit geltenden Kernfrist 12. September 2026.

Ein häufiges Missverständnis betrifft den Digital Omnibus. Dieses Paket wurde am 19. November 2025 vorgestellt, befindet sich weiter im Gesetzgebungsverfahren (noch nicht verabschiedet, Verabschiedung wird Mitte 2026 erwartet) und verschiebt die Frist 12. September 2026 für die Artikel-3-Designpflicht nicht. Es schlägt jedoch andere Änderungen am Data Act vor, etwa eine Konsolidierung mehrerer Rechtsakte, einen stärkeren Geschäftsgeheimnisschutz, Ausnahmen für KMU und Small-Mid-Caps sowie Erleichterungen beim Cloud-Switching. Wer auf eine generelle Fristverschiebung wartet, plant also auf unsicherer Grundlage. Auch dies ist kein Rechtsrat; prüfen Sie Stand und Tragweite vor verbindlichen Entscheidungen.

Access by design: was Artikel 3 und 4 technisch von einem IoT-Stack verlangen

Artikel 3(1) ist die Norm, an der sich die technische Architektur entscheidet. Verlangt wird, dass vernetzte Produkte so gestaltet und hergestellt sind, dass die Produktdaten und zugehörigen Servicedaten standardmäßig einfach, sicher, kostenlos, in einem umfassenden, strukturierten, gängigen und maschinenlesbaren Format und, wo relevant und technisch machbar, direkt für den Nutzer zugänglich sind. Das ist kein vager Programmsatz, sondern eine konkrete Anforderung an Schnittstellen und Datenformate.

Artikel 4 ergänzt den Fall, dass die Daten nicht direkt aus dem Produkt heraus zugänglich sind. Dann muss der Dateninhaber sie dem Nutzer ohne unangemessene Verzögerung, in gleicher Qualität wie für ihn selbst verfügbar, einfach, sicher und kostenlos, in einem umfassenden, strukturierten, gängigen und maschinenlesbaren Format bereitstellen, wo technisch machbar fortlaufend und in Echtzeit, auf eine einfache elektronische Anfrage hin. Übersetzt in die Sprache eines IoT-Stacks beschreibt das eine offene, dokumentierte Datenschnittstelle: eine API oder ein Messaging-Kanal, der strukturierte Daten in einem gängigen Format ausliefert, ohne dass der Nutzer auf das Wohlwollen einer geschlossenen Plattform angewiesen ist.

Artikel 4 schützt zugleich Geschäftsgeheimnisse, allerdings nicht absolut. Eine Offenlegung setzt voraus, dass zuvor Vertraulichkeitsmaßnahmen vereinbart wurden. Der Dateninhaber kann die Weitergabe zurückhalten oder aussetzen, wenn der Nutzer diese Maßnahmen nicht umsetzt, und sie im Einzelfall verweigern, wenn er nachweist, dass ihm trotz Schutzmaßnahmen mit hoher Wahrscheinlichkeit ein ernsthafter wirtschaftlicher Schaden droht. Wer also fürchtet, dass Sensordaten Rückschlüsse auf proprietäre Verfahren erlauben, hat einen abgestuften Schutz, aber keinen Freibrief zur pauschalen Verweigerung.

Cloud-LoRaWAN-Plattform vs. selbstkontrollierter ChirpStack-Stack

An dieser Stelle wird die Architekturfrage zur Compliance-Frage. Eine fremde, vollständig verwaltete Cloud-LoRaWAN-Plattform nimmt Ihnen den Betrieb ab, sitzt dafür aber zwingend im Datenpfad. Welche Rohdaten in welchem Format und in welcher Latenz herausgegeben werden, hängt davon ab, was der Anbieter über seine Konsole, Exporte oder APIs anbietet. Sind diese Schnittstellen eng, proprietär oder kostenpflichtig, wird die vom Data Act geforderte einfache, strukturierte und maschinenlesbare Bereitstellung zur Verhandlungssache mit dem Plattformbetreiber. Wie sich eine solche Cloud-Abhängigkeit am Beispiel eines US-Hyperscalers darstellt, vertieft der Vergleich AWS IoT Core for LoRaWAN Alternative.

Ein selbst kontrollierter ChirpStack-Stack dreht dieses Verhältnis um. ChirpStack ist ein quelloffener LoRaWAN Network Server unter der MIT-Lizenz, überwiegend in Rust geschrieben und seit 2015 von Orne Brocaar entwickelt (ursprünglich als „LoRa Server"). Version 4 vereint die zuvor getrennten Network- und Application-Server-Komponenten; als Abhängigkeiten kommen unter anderem PostgreSQL oder SQLite, Redis und ein MQTT-Broker zum Einsatz. Die aktuelle stabile Version ist v4.18.0, veröffentlicht am 11. Mai 2026. Entscheidend für den Data Act: Rohdaten, Payload-Decoder und Export-Schnittstellen liegen in Ihrer eigenen Instanz, nicht hinter der Konsole eines Dritten. Wer abwägen will, wie viel Betrieb dabei zumutbar ist, findet die Gegenüberstellung im Beitrag ChirpStack-Hosting: Managed vs. Self-Hosted; funktionale Vergleiche zu kommerziellen Plattformen bieten ChirpStack vs. The Things Stack und ChirpStack vs. Actility ThingPark.

Wie ein ChirpStack-Stack die Data-Act-Anforderungen praktisch erfüllt

Die Brücke zwischen Rechtstext und Technik ist erstaunlich kurz. Was Artikel 3(1) und Artikel 4 als „umfassendes, strukturiertes, gängiges und maschinenlesbares Format" beschreiben, deckt ein ChirpStack-Stack über mehrere offene Wege ab:

• MQTT als immer aktiver Messaging-Kanal liefert Uplinks strukturiert und in nahezu Echtzeit, was die Anforderung „fortlaufend und in Echtzeit, wo technisch machbar" technisch abbildet.
• gRPC- und REST/JSON-API erlauben den programmatischen Export von Geräte-, Anwendungs- und Messdaten, also die maschinenlesbare Bereitstellung auf einfache elektronische Anfrage hin.
• HTTP-Webhooks pushen Ereignisse an beliebige Zielsysteme, etwa an einen vom Nutzer benannten Dritten.
• Die bestätigte InfluxDB-Integration schreibt Gerätedaten direkt in eine Zeitreihendatenbank, zum Beispiel zur Visualisierung mit Grafana; weitere Integrationen wie ThingsBoard oder Cloud-Pub/Sub stehen bereit.

Weil Payload-Decoder als Codecs in Ihrer Instanz liegen, behalten Sie zudem die Kontrolle über die Lesbarkeit der Rohdaten: Die Roh-Payload eines Sensors lässt sich in ein strukturiertes, dokumentiertes Format überführen, das Sie selbst definieren und exportieren können. Genau diese Kombination, offene Schnittstellen plus eigene Decoder, ist ein dokumentierbarer technischer Baustein für die access-by-design- und Bereitstellungspflichten. Sie ersetzt keine rechtliche Prüfung Ihrer Rollen, senkt aber den Aufwand, die Pflichten technisch zu erfüllen, erheblich. Die genaue Schnittstellenliste sollten Sie vor verbindlichen Zusagen gegen die ChirpStack-Integrations-Übersicht und die API-Dokumentation abgleichen.

Wer diese Schnittstellen nicht selbst betreiben will, bekommt sie bei Managed ChirpStack Hosting mit deutscher Datenhaltung fertig konfiguriert, inklusive MQTT-Broker, API-Zugängen und automatischen Backups.

Bußgelder, Aufsicht und Geschäftsgeheimnisse: der Risikorahmen

Der Risikorahmen besteht aus zwei getrennten Regimen, die man nicht vermischen sollte. Das erste betrifft personenbezogene Daten. Artikel 40 des Data Act nennt keinen festen EU-weiten Höchstbetrag, sondern verpflichtet die Mitgliedstaaten zu wirksamen, verhältnismäßigen und abschreckenden Sanktionen. Für Verstöße mit Personenbezug verweist er auf das DSGVO-Sanktionsregime: Über Artikel 83(5) DSGVO droht ein Rahmen bis zu 20 Mio. EUR oder 4 % des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres, je nachdem, welcher Betrag höher ist.

Das zweite Regime sind die nationalen Bußgelder nach dem deutschen DA-DG. Sie sind nach Schwere gestaffelt: bis zu 5 Mio. EUR bzw. 2 % des weltweiten Jahresumsatzes für Verstöße sogenannter Torwächter (Art. 5(3) DA), bis zu 500.000 EUR für Verstöße gegen die zentralen Datenbereitstellungspflichten (Art. 3(1) und Art. 4(1) DA), bis zu 100.000 EUR für Informationspflichten gegenüber der Bundesnetzagentur und Verstöße gegen Artikel 11 sowie bis zu 50.000 EUR als Auffangtatbestand. Diese Höchstgrenzen können überschritten werden, wenn aus dem Verstoß wirtschaftliche Vorteile gezogen wurden. Es ist also falsch zu sagen, Deutschland habe die Bußgelder pauschal auf 500.000 EUR begrenzt: Das gilt nur für die Datenbereitstellungspflichten, nicht für Torwächter-Verstöße oder für Fälle mit Personenbezug.

Zuständige zentrale Aufsichtsbehörde ist die Bundesnetzagentur (BNetzA). Für die Aufsicht bei personenbezogenen Daten, soweit nicht-öffentliche Stellen verarbeiten, behält der bzw. die BfDI die alleinige Zuständigkeit. Der schon erwähnte Geschäftsgeheimnisschutz aus Artikel 4 ergänzt das Bild: Er erlaubt ein abgestuftes Zurückhalten von Daten, ist aber an Nachweis- und Vereinbarungspflichten gebunden. Dies ist kein Rechtsrat; die konkrete Einordnung Ihrer Organisation gehört in fachkundige Hände.

Checkliste: Was LoRaWAN-Betreiber bis zum 12.09.2026 vorbereiten sollten

Die folgende Liste ist eine pragmatische Vorbereitung, keine abschließende Compliance-Garantie:

• Rollen klären: Bestimmen Sie für jedes Sensorprodukt, ob Sie Nutzer, Dateninhaber oder beides sind. Davon hängen Ihre Rechte und Pflichten ab.
• Datenflüsse kartieren: Dokumentieren Sie, welche Daten ein Gerät erzeugt, wohin sie fließen, wer Zugriff hat und wo eine fremde Plattform im Datenpfad sitzt.
• Schnittstellen prüfen: Stellen Sie sicher, dass Daten einfach, strukturiert und maschinenlesbar exportierbar sind, idealerweise über offene Wege wie MQTT, API oder Webhooks.
• Datenpfad entflechten: Prüfen Sie, ob ein selbst kontrollierter Stack die Abhängigkeit von einer intransparenten Cloud-Plattform reduziert.
• Verträge vorbereiten: Klären Sie die Datenlizenz mit Dateninhabern und Dritten; die freiwilligen Mustervertragsklauseln der EU-Kommission können als Vorlage dienen.
• Geschäftsgeheimnisse identifizieren: Markieren Sie Daten, die schützenswert sind, und definieren Sie die nötigen Vertraulichkeitsmaßnahmen.
• Neue Produkte ab 12.09.2026 prüfen: Stellen Sie sicher, dass nach diesem Datum in Verkehr gebrachte Produkte access by design erfüllen.
• Beratung einholen: Lassen Sie Ihre Einordnung rechtlich bestätigen, diese Checkliste ersetzt keinen Rechtsrat.

Auch interessant: Die Interoperabilitätspflicht kehrt im Submetering wieder: fernablesbare Zähler bis 31.12.2026.

Fazit: Datenhoheit als Compliance-Vorsprung

Der EU Data Act macht aus einer abstrakten Souveränitätsdebatte eine konkrete Pflicht: Wer ein vernetztes Produkt nutzt, soll an seine Daten kommen, einfach, strukturiert und maschinenlesbar. Für LoRaWAN-Betreiber heißt das, dass die Architekturentscheidung zwischen einer fremden Cloud-Plattform und einem selbst kontrollierten Stack nun auch eine Compliance-Entscheidung ist. Eine geschlossene Plattform kann die geforderte Bereitstellung erschweren; ein quelloffener ChirpStack-Stack mit MQTT, gRPC- und REST-API, Webhooks und InfluxDB-Integration erfüllt sie weitgehend von Haus aus.

Genau hier setzt chirphost an: verwalteter ChirpStack-Betrieb in deutschen Rechenzentren, mit voller Datenhoheit, offenen Export-Schnittstellen und planbarem Festpreis, ohne DevOps-Overhead und ohne fremden Anbieter im Datenpfad. Die Plan- und Preisstruktur dazu steht bei den ChirpStack-Hosting-Preisen. Wer den Betriebsaufwand abwägen will, beginnt mit ChirpStack-Hosting: Managed vs. Self-Hosted; Einsteiger finden den Weg im Leitfaden Privates LoRaWAN-Netzwerk aufbauen. Datenhoheit ist damit kein Selbstzweck, sondern ein Vorsprung: Sie erfüllen die access-by-design-Idee technisch, bevor die Frist Sie dazu zwingt. Dies bleibt eine technisch-organisatorische Einordnung und kein Rechtsrat.

Wie Datenstandort, Auftragsverarbeitung und Ausstieg bei chirphost konkret geregelt sind, steht auf der Seite zu Sicherheit und Datenstandorten.

ChirpStack ist eine Marke des jeweiligen Projektinhabers. Dieser Beitrag steht in keiner Verbindung zu und wird nicht unterstützt von den genannten Anbietern oder Behörden; Nennungen dienen ausschließlich der sachlichen Einordnung.

Quellen

• EUR-Lex: Verordnung (EU) 2023/2854 (Data Act), amtlicher Text
• Europäische Kommission: Data Act (Policy-Seite, Inkrafttreten und Anwendung)
• Europäische Kommission: Data Act explained (access by design, Nutzerrechte)
• EU Data Act: Artikel 50 (Inkrafttreten und Anwendung, Fristen)
• EU Data Act: Artikel 3 (access by design, Wortlaut)
• EU Data Act: Artikel 4 (Pflichten Dateninhaber, Format, Geschäftsgeheimnisse)
• EU Data Act: Artikel 40 (Sanktionen, Verweis auf Art. 83 DSGVO)
• GDPR-info.eu: Bußgelder Art. 83(5) DSGVO (20 Mio. EUR / 4 %)
• Haufe: Durchführungsgesetz zum Data Act verabschiedet und verkündet (BGBl., Inkrafttreten)
• Osborne Clarke: Der Data Act wird scharfgestellt: Durchführungsgesetz (Bußgeldstaffel)
• Heuking: German Parliament passes Data Act Implementation Act (DA-DG, BNetzA)
• Osborne Clarke: Digital Omnibus package (12.09.2026 bleibt, vorgeschlagene Änderungen)
• BCLP: EU Data Act: New Model Contract Terms and Standard Clauses (Nov. 2025)
• ChirpStack: Changelog (aktuelle stabile Versionen v4.x)
• ChirpStack: GitHub Repository (MIT-Lizenz, Rust)
• ChirpStack: InfluxDB-Integration / Datenexport-Schnittstellen