The recurring misunderstanding: "We can charge for data access under the EU Data Act"​

Over the past months, I have repeatedly heard the same statement in conversations with manufacturers, platform providers, and even advisors:

"We can charge businesses for data access under the EU Data Act."

Often, this claim is backed up by a reference to Recital 46 of the EU Data Act. At first glance, this seems plausible. But it is also one of the most persistent and consequential misunderstandings around Data Act data access and data act monetization.

This article explains where the confusion comes from, why it matters, and how companies should rethink their monetization strategies in light of the EU Data Act.

---

What Recital 46 actually says and why it is misleading when read in isolation​

Recital 46 states, among other things, that:

In business-to-business relations, data holders may request reasonable compensation when obliged to make data available to a data recipient.

This single sentence is often interpreted as a general permission to charge for data access under the EU Data Act, including towards business users of connected products.

That interpretation is incorrect.

The key to understanding Recital 46 lies in one specific legal term: data recipient.

---

"Data recipient" does not mean "user" under the EU Data Act​

Under the EU Data Act, the terms user and data recipient are clearly defined and deliberately separated. They are not interchangeable.

A user is the natural or legal person that owns, rents, or leases a connected product or receives a related service.

A data recipient, by contrast, is a third party to whom data is made available at the request of the user.

This distinction is foundational for understanding Data Act data access obligations.

---

Articles 3 and 4: Data access for users must be free of charge​

Articles 3 and 4 of the EU Data Act are explicit and unambiguous.

They require that users of connected products and related services are granted access to the data generated by those products and services free of charge.

This applies regardless of whether the user is:

• a consumer (B2C), or
• a business customer (B2B).

The EU Data Act does not distinguish between consumer users and business users when it comes to the principle of free data access.

If a company is the user of a connected product, it has a statutory right to access its data without being charged for that access.

This is precisely why Recital 46 cannot be used to justify charging users for data access.

---

So when can money be charged under the EU Data Act?​

Charging becomes possible only in a very specific scenario:

When data is transferred to a third party, acting as a data recipient, and only at the explicit request of the user.

Even then, the compensation must be:

• reasonable,
• cost-oriented,
• and non-discriminatory.

In other words, the EU Data Act allows cost recovery and modest margins for third-party data transfers. It does not allow monetizing user access to raw product data.

---

Is this unfair to manufacturers who invested in IoT infrastructure?​

This question comes up frequently as well.

Manufacturers argue that they invested heavily in sensors, connectivity, cloud infrastructure, data pipelines, and APIs. From that perspective, free data access can feel like a forced giveaway. And this perspective is very much valid, in my opinion

However, the European Union prioritizes its strategic bet on a data economy. While I see the downside for manufacturers, I would like to advocate for making the best out of this scenario. In fact, the introduction, or rather, the adoption of the EU Data Act by both manufacturers and users could very well be a door-opener for real data monetization opportunities. But let's first analyze what data a manufacturer or data holder can actually charge for.

---

What can be monetized: enriched, processed, and value-added data​

The EU Data Act focuses on access to raw and directly generated data.

It does not prohibit monetization of:

• enriched data,
• aggregated datasets,
• predictive insights,
• benchmarks,
• analytics results,
• AI-based recommendations,
• or domain-specific optimizations.

These value-added outputs are not the same as the raw data a user is entitled to access for free.

This distinction opens the door to sustainable data act monetization strategies. Strategies which in many cases have not been implemented due to manufacturers being too hesitant to think in data ecosystems rather than their vertically integrated applications. APIs have not been productized and cannot be exposed to public audiences easily. Pricing models around data access are prohibitively expensive or lacking in flexbility, therefore prevening user adoption.

---

A pragmatic monetization strategy under the EU Data Act​

A robust approach for many companies will look familiar from SaaS and platform economics.

One effective pattern is a freemium-style model and the EU Data Act enforces exactly that:

• Provide free, compliant data access via a Data Act API to users.
• Use the same technical infrastructure to offer additional, enriched data products.
• Charge for advanced insights, automation, forecasting, optimization, and integrations.
• But do it on a consumption-based model

In this model, the EU Data Act functions as a facilitator for a distribution channel rather than a threat.

It forces companies to expose data access, but it also dramatically lowers the friction for building data-driven services on top of that access. Consuption-based models are key, because the value of data is vastly depending on the respective use case. A flat-rate pricing usually is not satisfactory for the business case of the manufacturer or respectively the user.

---

The EU Data Act as a catalyst for data monetization maturity​

Ironically, the obligation to provide free data access may accelerate data monetization rather than hinder it.

Companies that previously struggled to justify investments into data platforms now have a regulatory reason to build them. Once the infrastructure exists, extending it towards monetizable offerings is much more straight forward.

Seen this way, the EU Data Act creates a unique opportunity:

• to standardize data access,
• to professionalize data products,
• and to transition from hardware-centric to data-augmented business models.

---

Conclusion​

The EU Data Act does not allow charging users for access to their own product data. Articles 3 and 4 make this clear, and Recital 46 does not change that reality.

However, the regulation reshapes the data monetization environment.

Companies that focus on enriched data, insights and value-added services can turn Data Act compliance into a strategic advantage.

The winners will be those who embrace data access with user-friendly and cost-effective data provisioning infrastructure which allows for a robust data up-sell channel.

---

Sources​

• Recital 46, EU Data Act
• Definition of data recipient, EU Data Act
• Articles 3, EU Data Act

On 1 December 2025, the German Data Act implementation draft (Bundestag Document 21/2998) was introduced in the German Bundestag. With this national implementation law, the Federal Government defines how the EU Data Actwill be supervised, enforced, and sanctioned in Germany from 2025 onwards.

For the first time, it becomes clear which oversight structures, penalties, documentation requirements, and technical obligations will apply to manufacturers of connected products, IoT providers, and data holders. The draft makes one thing evident: Data Act compliance will become a core element of corporate governance.

---

Full version only available in German

The EU Data Act is set to create significant new rules for the digital economy, particularly for data generated by connected products-the Internet of Things (IoT). From smart appliances and wearables to industrial machinery and vehicles, these devices produce a constant stream of valuable information. At the very heart of this regulation is Article 4, a provision that redefines the relationship between the users of these products and the companies that manufacture or service them (the "data holders").

Article 4 establishes a clear right for users to access the data they help create. For a long time, this data was often treated as the exclusive property of the manufacturer, locked away in proprietary systems. This regulation changes that, mandating that data holders make this information available to the user. This isn't just about transparency; it's about enabling users-who can be individuals or businesses-to use their data for third-party services, like independent repair, analytics, or switching providers. This post will break down what Article 4 demands and explore the practical steps for implementing a system that is secure, compliant, and user-friendly.

---

What Article 4 Demands: The User's Right to Access​

Article 4, Paragraph 1, lays down the fundamental new right. It states that when a user cannot directly access data from their connected product, the data holder must make that data available. This isn't a vague suggestion; the law is highly specific about the conditions for this access. The data must be provided "without undue delay" and "free of charge." This implies that data holders cannot create long waiting periods or erect paywalls that would make access difficult.

Furthermore, the data provided must be of the "same quality as is available to the data holder" and must include the "relevant metadata necessary to interpret and use" it. This is a critical point. It prevents a data holder from offering the user a lower-quality, summarized, or incomplete dataset while keeping the high-value, detailed data for themselves. The format is also specified: "comprehensive, structured, commonly used and machine-readable." This requirement moves us beyond simple, non-usable data dumps and pushes for formats that can be easily processed by other software, such as through an API or a structured file export (like JSON or CSV). Where technically feasible, this access should even be continuous and in real-time.

From Legal Text to User Interface: Building the Data Access Journey​

Complying with Article 4 isn't just a backend legal challenge; it's a front-end design challenge. The regulation puts the user's experience at the center of the process. In practice, this begins with a clearly defined activation process for a new product. From the very start, the user's journey should include transparent notifications about what data is being collected and their new rights to access it. This means integrating data access options directly into the product's user interface, whether that's a mobile app, a web portal, or another customer touchpoint.

This is where Article 4, Paragraph 4, becomes directly relevant. This provision effectively bans "dark patterns." It states that data holders "shall not make the exercise of choices or rights... unduly difficult," for example, by "subverting or impairing the autonomy, decision-making or choices of the user." This means the design must be clear and neutral. Hiding the "data export" button in an obscure menu or using confusing language to discourage a user from sharing their data with a third party is explicitly forbidden. The entire journey-from activation to data sharing to revoking access-must be coherent, intuitive, and straightforward.

Delivering the Data: Secure, Configurable, and Auditable Channels​

Once a user requests their data, how should it be delivered? Article 4(1) requires a "simple request through electronic means." This points to the need for robust, accessible export tools. Users should be met with clear instructions, not technical jargon, ensuring they can get their data without friction. These tools must operate through secure, interoperable channels. For many data holders, this will mean developing APIs that allow users (or third parties they authorize) to pull data in a structured, continuous way. For other use cases, simple file downloads or direct batch exports might be more appropriate.

The key is offering configurable access options. A user should be able to manage the frequency and scope of their data sharing. They might want a one-time file download of their smart thermostat's history, or they might want to grant near real-time API access to a third-party energy optimization service. This flexibility allows users to tailor data sharing to their specific needs while respecting the principle of data minimization. On the backend, this entire system must be governed by strong access controls, detailed usage logs, and audit-ready records. This is essential not only for proving compliance to regulators but also for maintaining security and trust with the user.

Balancing Access: Security, Personal Data, and Trade Secrets​

Article 4 does not create an unconditional, absolute right to all data. It provides important and necessary exceptions to protect other legitimate interests. The first major exception is for product security. Paragraph 2 allows a data holder to "restrict or prohibit" data access if that access "could undermine security requirements... resulting in a serious adverse effect on the health, safety or security of natural persons." This is a high bar and is not a blanket excuse to deny access. Any such refusal must be documented and notified to the relevant national authority.

The second major consideration is personal data. If the user requesting the data (e.g., a company owning a fleet of vehicles) is not the data subject (e.g., the employee driving the vehicle), Paragraph 12 makes it clear that GDPR rules apply. Any personal data can only be shared if there is a valid legal basis for processing it under GDPR. This reinforces that the Data Act works alongside, not in place of, existing data protection laws.

The most complex balance, however, is with trade secrets. Paragraphs 6 through 9 deal with this directly. Data holders can, and should, protect their trade secrets. But they cannot use "trade secrets" as a simple excuse to deny all data access. Instead, the law creates a process of "cooperation." The data holder must first identify which data is protected as a trade secret. Then, the data holder and the user must "agree on... necessary measures to preserve [their] confidentiality." This could involve confidentiality agreements (NDAs) or specific technical protocols that limit how the data can be used or seen. Only if the user fails to implement these measures, or in "exceptional circumstances" where the holder can prove a high likelihood of "serious economic damage" despite the measures, can the holder refuse the request.

New Rules for Both Sides: User and Data Holder Obligations​

Finally, Article 4 introduces new rules of engagement that apply to both the user and the data holder, creating a more level playing field. For the user, Paragraph 10 provides a key limitation: a user who obtains data cannot use it "to develop a connected product that competes with the connected product from which the data originate." This rule is designed to prevent a company from simply buying a competitor's machine, extracting all its operational data via an Article 4 request, and using that data to reverse-engineer their own competing product.

On the other side, data holders face a similar and equally important restriction. Paragraph 13 states that a data holder cannot use the user's non-personal data "to derive insights about the economic situation, assets and production methods of... the user" in a way that "could undermine the commercial position of that user." For example, a manufacturer of industrial smart-factory machines cannot analyze the output data from its clients' factories to then enter the market and compete directly with those clients. Furthermore, data holders are generally prohibited from sharing this data with other third parties for their own commercial purposes. These "dual-restraint" clauses are intended to ensure that the data access right is used for its intended purpose-user benefit and third-party services-not as a weapon for anti-competitive behavior.