The EU Data Act and LoRaWAN: Who Owns Your Sensor Data?

The EU Data Act turns the ownership question for IoT data on its head: it is no longer the manufacturer or the cloud platform that controls the sensor data, but the user (the operator) of the connected product who gains a right to access, use and share it. From 12 September 2026, products newly placed on the market must enable this technically from the outset (access by design). That shift strikes at the core of a LoRaWAN network's architecture: an operator sitting on an opaque third-party cloud platform depends on that provider's data provisioning. A self-controlled, open-source ChirpStack stack, by contrast, puts the raw data, payload decoders and export interfaces in your own hands from day one. This article sets out what the Data Act requires, who owns the data, and why data control becomes a practical compliance edge here. As of June 2026.

Table of Contents

• What the EU Data Act regulates, and why LoRaWAN operators are affected
• Who owns the sensor data? Users, data holders and the new data licence
• The deadlines: 12 Sep 2025, 12 Sep 2026 and the German implementation act
• Access by design: what Articles 3 and 4 technically require of an IoT stack
• Cloud LoRaWAN platform vs. a self-controlled ChirpStack stack
• How a ChirpStack stack meets the Data Act requirements in practice
• Fines, supervision and trade secrets: the risk frame
• Checklist: what LoRaWAN operators should prepare by 12 Sep 2026
• Conclusion: data control as a compliance edge
• Sources

What the EU Data Act regulates, and why LoRaWAN operators are affected

The EU Data Act is Regulation (EU) 2023/2854 of the European Parliament and of the Council of 13 December 2023 on harmonised rules on fair access to and use of data. It entered into force on 11 January 2024 (the 20th day after publication in the Official Journal of 22 December 2023) and has been generally applicable since 12 September 2025. At its core it regulates three things: access to and use of data from connected products and related services, the sharing of that data with third parties, and switching between data-processing services (cloud switching) along with interoperability.

This is precisely where LoRaWAN operators are affected. A LoRaWAN sensor is a connected product within the meaning of the regulation, and the data it generates (readings, metadata, status information) is product data. Whether smart metering, asset tracking, building automation or environmental sensing: as soon as a device produces data that flows to a server, a data chain emerges with roles, rights and duties. The interesting question is no longer whether this data is collected, but who controls it and who must hand it over. If you want to understand the fundamentals of building your own network, see the guide Building a private LoRaWAN network.

Note: this article is a technical and organizational classification, not legal advice. For a binding assessment of your data flows and your role under the Data Act, please consult your data protection and legal counsel.

Who owns the sensor data? Users, data holders and the new data licence

The Data Act deliberately avoids the term data ownership. Instead of ownership it speaks of rights, and that fundamentally shifts the logic. Two roles are central: the user and the data holder. The user is the natural or legal person who owns or uses the connected product, in the LoRaWAN context typically the operator of the sensor network. The data holder is the entity that exercises legal or factual control over the generated data, often the device manufacturer or the provider of a related service.

The novelty: the user gains the right to use the generated product and related service data and to share it with third parties. The data holder may use the same data for its own purposes only on a contractual basis, that is on the basis of an agreement with the user that in practice reads as a data licence. Effective data control thus moves away from the manufacturer or platform toward the operator. For LoRaWAN this means: running your own or a managed network-server instance is not only a sovereignty question, it also shapes how easily you can actually exercise your rights as a user.

To ease EU-wide data sharing in practice, the European Commission has published non-binding, voluntary Model Contractual Terms (MCT) and Standard Contractual Clauses (SCC), in mid to late November 2025 (19/20 Nov 2025), initially in English; translations into all EU languages are expected within roughly three to four months. These templates are an aid for drafting the data licence, not an obligation.

The deadlines: 12 Sep 2025, 12 Sep 2026 and the German implementation act

Three dates structure the timeline. First, 12 September 2025: since that day the Data Act has been generally applicable under Article 50, so most obligations already apply. Second, 12 September 2026: from this date the design obligation under Article 3(1) takes effect. It applies to connected products and related services placed on the EU market after that date. Existing products already on the market are not automatically covered, but new ones certainly are. So anyone bringing a LoRaWAN-based product to market in 2026 or later must plan for data accessibility from the outset.

Third, national transposition in Germany. The Data Act Implementation Act (DA-DG) was adopted by the Bundestag on 26 March 2026, promulgated on 29 May 2026 as Federal Law Gazette 2026 I No. 157, and has been in force since 30 May 2026 (the day after promulgation). It mainly governs the competent authorities and the penalties, but changes nothing about the EU-wide core deadline of 12 September 2026.

A common misconception concerns the Digital Omnibus. This package was unveiled on 19 November 2025, remains in the legislative process (not yet adopted, adoption expected mid-2026) and does not move the 12 September 2026 deadline for the Article 3 design obligation. It does, however, propose other changes to the Data Act, such as consolidating several legal acts, stronger trade-secret protection, exemptions for SMEs and small mid-caps, and easier cloud switching. Anyone waiting for a general deadline extension is therefore planning on shaky ground. This too is not legal advice; check status and scope before binding decisions.

Access by design: what Articles 3 and 4 technically require of an IoT stack

Article 3(1) is the provision that decides the technical architecture. It requires connected products to be designed and manufactured so that the 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. This is not a vague aspiration but a concrete requirement for interfaces and data formats.

Article 4 covers the case where data is not directly accessible from the product. Then the data holder must make it available to the user without undue delay, of the same quality as available to the holder, easily, securely and free of charge, in a comprehensive, structured, commonly used and machine-readable format, where technically feasible continuously and in real time, upon a simple electronic request. Translated into the language of an IoT stack, this describes an open, documented data interface: an API or messaging channel that delivers structured data in a common format, without the user depending on the goodwill of a closed platform.

Article 4 also protects trade secrets, but not absolutely. Disclosure presupposes that confidentiality measures have been agreed beforehand. The data holder may withhold or suspend sharing if the user fails to implement those measures, and may refuse it in specific cases by demonstrating that, despite protective measures, serious economic harm is highly likely. So anyone worried that sensor data reveals proprietary processes has graduated protection, but no blanket licence to refuse outright.

Cloud LoRaWAN platform vs. a self-controlled ChirpStack stack

This is where the architecture question becomes a compliance question. A third-party, fully managed cloud LoRaWAN platform takes operations off your hands, but necessarily sits in the data path. Which raw data is handed over, in what format and at what latency, depends on what the provider offers through its console, exports or APIs. If those interfaces are narrow, proprietary or chargeable, the easy, structured and machine-readable provision the Data Act demands becomes a matter of negotiation with the platform operator. How such cloud dependence looks in the case of a US hyperscaler is examined in AWS IoT Core for LoRaWAN Alternative.

A self-controlled ChirpStack stack reverses this relationship. ChirpStack is an open-source LoRaWAN Network Server under the MIT licence, written mostly in Rust and developed by Orne Brocaar since 2015 (originally as "LoRa Server"). Version 4 unifies the previously separate network-server and application-server components; its dependencies include PostgreSQL or SQLite, Redis and an MQTT broker. The current stable version is v4.18.0, released on 11 May 2026. The point that matters for the Data Act: raw data, payload decoders and export interfaces live in your own instance, not behind a third party's console. To weigh how much operational effort is reasonable, see the comparison ChirpStack Hosting: Managed vs. Self-Hosted; for functional comparisons against commercial platforms, see ChirpStack vs. The Things Stack and ChirpStack vs. Actility ThingPark.

How a ChirpStack stack meets the Data Act requirements in practice

The bridge between legal text and technology is surprisingly short. What Articles 3(1) and 4 describe as a "comprehensive, structured, commonly used and machine-readable format" is covered by a ChirpStack stack through several open paths:

• MQTT, an always-active messaging channel, delivers uplinks in a structured form and in near real time, technically mapping the requirement of "continuously and in real time, where technically feasible".
• The gRPC and REST/JSON API allow programmatic export of device, application and measurement data, that is machine-readable provision upon a simple electronic request.
• HTTP webhooks push events to any target system, for example to a third party named by the user.
• The confirmed InfluxDB integration writes device data directly into a time-series database, for instance for visualization with Grafana; further integrations such as ThingsBoard or cloud Pub/Sub are available.

Because payload decoders sit as codecs in your instance, you also retain control over the readability of the raw data: a sensor's raw payload can be turned into a structured, documented format that you define and export yourself. This combination, open interfaces plus your own decoders, is precisely a documentable technical building block for the access-by-design and provision obligations. It does not replace a legal review of your roles, but it considerably lowers the effort of meeting the obligations technically. You should reconcile the exact interface list against the ChirpStack integrations overview and the API documentation before making binding commitments.

If you would rather not run those interfaces yourself, managed ChirpStack hosting with German data residency delivers them pre-configured, including MQTT broker, API access and automatic backups.

Fines, supervision and trade secrets: the risk frame

The risk frame consists of two separate regimes that should not be conflated. The first concerns personal data. Article 40 of the Data Act sets no fixed EU-wide ceiling but obliges Member States to lay down effective, proportionate and dissuasive penalties. For infringements involving personal data it refers to the GDPR penalty regime: via Article 83(5) GDPR, the ceiling is up to EUR 20 million or 4% of worldwide annual turnover of the preceding financial year, whichever is higher.

The second regime is the national fines under the German DA-DG. They are tiered by severity: up to EUR 5 million or 2% of worldwide turnover for breaches by so-called gatekeepers (Art. 5(3) DA), up to EUR 500,000 for breaches of the core data-provision duties (Art. 3(1) and Art. 4(1) DA), up to EUR 100,000 for information duties toward the Federal Network Agency and breaches of Article 11, and up to EUR 50,000 as a catch-all. These ceilings can be exceeded where economic advantages were gained from the breach. So it is wrong to say Germany capped fines at EUR 500,000: that applies only to the data-provision duties, not to gatekeeper breaches or cases involving personal data.

The central competent authority is the Federal Network Agency (BNetzA). For supervision involving personal data, insofar as non-public bodies process it, the BfDI retains sole competence. The trade-secret protection under Article 4 mentioned above completes the picture: it permits a graduated withholding of data, but is tied to evidence and agreement requirements. This is not legal advice; the concrete classification of your organization belongs in qualified hands.

Checklist: what LoRaWAN operators should prepare by 12 Sep 2026

The following list is a pragmatic preparation, not a conclusive compliance guarantee:

• Clarify roles: for each sensor product, determine whether you are user, data holder or both. Your rights and duties depend on it.
• Map data flows: document what data a device generates, where it flows, who has access and where a third-party platform sits in the data path.
• Check interfaces: ensure data can be exported easily, in a structured and machine-readable way, ideally via open paths such as MQTT, API or webhooks.
• Disentangle the data path: assess whether a self-controlled stack reduces dependence on an opaque cloud platform.
• Prepare contracts: clarify the data licence with data holders and third parties; the Commission's voluntary model contractual terms can serve as a template.
• Identify trade secrets: flag data worth protecting and define the necessary confidentiality measures.
• Review new products from 12 Sep 2026: ensure products placed on the market after that date meet access by design.
• Seek advice: have your classification confirmed legally; this checklist does not replace legal advice.

Also of interest: The interoperability obligation reappears in submetering: remote-readable meters by 31 December 2026.

Conclusion: data control as a compliance edge

The EU Data Act turns an abstract sovereignty debate into a concrete obligation: whoever uses a connected product should be able to reach their data easily, in a structured and machine-readable form. For LoRaWAN operators this means the architecture choice between a third-party cloud platform and a self-controlled stack is now also a compliance choice. A closed platform can complicate the required provision; an open-source ChirpStack stack with MQTT, gRPC and REST API, webhooks and InfluxDB integration largely meets it out of the box.

This is exactly where chirphost comes in: managed ChirpStack operations in German data centers, with full data control, open export interfaces and a predictable flat rate, without DevOps overhead and without a third-party provider in the data path. The plan and price structure is set out under ChirpStack hosting pricing. To weigh the operational effort, start with ChirpStack Hosting: Managed vs. Self-Hosted; newcomers find their way in the guide Building a private LoRaWAN network. Data control is thus not an end in itself but an edge: you meet the access-by-design idea technically before the deadline forces you to. This remains a technical and organizational classification, not legal advice.

How data location, processing agreement and exit are handled at chirphost specifically is covered on the security and data locations page.

ChirpStack is a trademark of its respective project owner. This article is not affiliated with or endorsed by the providers or authorities named; references serve objective classification only.

Sources

• EUR-Lex: Regulation (EU) 2023/2854 (Data Act), official text
• European Commission: Data Act (policy page, entry into force and application)
• European Commission: Data Act explained (access by design, user rights)
• EU Data Act: Article 50 (entry into force and application, deadlines)
• EU Data Act: Article 3 (access by design, verbatim wording)
• EU Data Act: Article 4 (data holder duties, format, trade secrets)
• EU Data Act: Article 40 (penalties, reference to Art. 83 GDPR)
• GDPR-info.eu: Fines under Art. 83(5) GDPR (EUR 20 million / 4%)
• Haufe: Data Act Implementation Act adopted and promulgated (Federal Law Gazette, entry into force)
• Osborne Clarke: The Data Act gets teeth: Implementation Act (fine tiers)
• Heuking: German Parliament passes Data Act Implementation Act (DA-DG, BNetzA)
• Osborne Clarke: Digital Omnibus package (12 Sep 2026 stands, proposed changes)
• BCLP: EU Data Act: New Model Contract Terms and Standard Clauses (Nov 2025)
• ChirpStack: Changelog (current stable v4.x versions)
• ChirpStack: GitHub repository (MIT licence, Rust)
• ChirpStack: InfluxDB integration / data export interfaces