The EU Data Act creates a layered system of data access rights. At its core, Chapter II establishes that users of connected products and related services have the right not only to access the data generated by their own devices but also to direct that data to third parties of their choosing. This right to instruct third-party data sharing is one of the most commercially significant provisions in the entire regulation, and for US manufacturers selling into European markets, it reshapes the assumptions that have governed data strategy for the past decade.
Understanding this chapter requires grasping three interlocking questions: Who is a third party entitled to receive data? How does the user exercise their right to direct data sharing? And what can a third party do with that data once it receives it? Each of these questions has specific answers under the Data Act, and the answers carry practical obligations that will affect how you design your products, draft your contracts, and structure your data infrastructure.
The User’s Right to Direct Data Sharing
The starting point is Article 5 of the Data Act, which grants users the right to instruct the data holder — typically the manufacturer or service provider — to share data with a third party nominated by the user. This is not a right the third party holds independently; it flows from the user’s underlying right of access established in Article 4. The user must affirmatively invoke it, and the third party they designate must meet certain qualifications.
The right applies to data generated by the use of connected products and related services. This encompasses sensor data, usage logs, performance metrics, diagnostic outputs, and any other data that the product generates as a result of the user interacting with it or the product operating in its environment. It does not cover data that the data holder derives through its own analytical work — so if a manufacturer takes raw sensor data and produces a proprietary performance score using its own algorithms, the proprietary score itself is not necessarily subject to sharing obligations. But the underlying raw data that feeds those algorithms generally is.
Critically, this right exists regardless of whether the user has any contractual relationship with the third party. The user can instruct sharing with any qualifying third party — a competitor of the manufacturer, an independent repair shop, a data aggregator, a research institution, or any other entity. The manufacturer has no general right to veto the user’s choice of recipient, though specific protections do apply when the nominated third party is a gatekeeper under the Digital Markets Act, as discussed below.
Who Qualifies as a Third Party
The Data Act defines a third party, in this context, as any natural or legal person other than the user and the data holder to whom the user directs data sharing. This is a deliberately broad definition. It captures commercial enterprises, non-profit organizations, research bodies, platform operators, and individuals. There is no requirement that the third party be established in the EU, though it must agree to the obligations the Data Act imposes on data recipients before receiving data.
The key constraint on third parties is that they must agree to use the data only for the purposes the user has specified when making the sharing request, and they must comply with the use restrictions imposed by Article 6 of the Data Act. These restrictions are not negotiable between the data holder and the third party — they are imposed by law on any entity that receives data through a user-directed sharing instruction.
There is one categorical exclusion from who can receive data through this mechanism: gatekeepers designated under the Digital Markets Act. The Data Act includes specific provisions that limit the ability of these large platform companies to accumulate data through user-directed sharing requests. This exclusion and its mechanics are addressed in detail in a later section of this page.
The Mechanics of Instructing Data Sharing
The Data Act requires that the process for users to instruct data sharing must be easy to use, technically feasible, and not create unnecessary friction. The regulation does not prescribe the exact mechanism — it may be a setting within an app, a request submitted through a web portal, or an API-level instruction — but whatever mechanism is used must meet the principle of non-discrimination. The data holder cannot make the third-party sharing request more burdensome than the process the user would follow to access data for themselves.
Once a valid sharing instruction is received, the data holder must act without undue delay. The Data Act does not set a fixed maximum response time for Article 5 requests in the way that GDPR sets a one-month deadline for data subject requests, but the underlying principle of effectiveness demands timely action. A data holder who processes internal data requests rapidly but imposes artificial delays on third-party sharing instructions would be in violation of the non-discrimination principle.
The data holder is permitted to require that any sharing instruction include basic identifying information about the third party and a statement of the purpose for which the data is sought. This is reasonable and allows the data holder to fulfill its own obligation to confirm that the third party has committed to the Article 6 use restrictions. However, the data holder cannot use this verification step as a pretext to delay or obstruct sharing requests it finds commercially inconvenient.
Format and Technical Requirements for Data Sharing
One of the most practically demanding requirements in Chapter II is the obligation on format. Article 4 requires that data be made available in a structured, commonly used, machine-readable, and interoperable format. When data is shared with a third party under Article 5, this same standard applies. The data holder cannot fulfill its sharing obligation by dumping a proprietary binary format that only its own software can read.
The interoperability requirement is particularly significant for manufacturers of complex industrial or technical products. If your device generates data in a proprietary format — which is common across sectors like industrial machinery, medical devices, and precision agriculture equipment — you will need to develop a translation layer or export function that outputs that data in a form that standard tools can process. XML, JSON, CSV, and similar open formats are the paradigmatic cases of what is expected, though the Data Act also contemplates that sector-specific interoperability standards may be developed under implementing acts.
The data must also be transmitted securely. While the Data Act does not specify the exact security protocols required, it operates against the backdrop of the EU’s broader cybersecurity framework, including the NIS2 Directive and the Cyber Resilience Act. Data holders will be expected to implement transmission security appropriate to the sensitivity of the data being shared — at a minimum, encrypted transport protocols are baseline compliance.
Where direct continuous data streams are technically feasible — as is the case with many IoT devices that maintain live connectivity — the data holder must make real-time or near-real-time data transmission available. This is a significant departure from a world in which manufacturers controlled the cadence of data delivery. Under the Data Act, if your device can stream data continuously, your obligation is to enable third parties to receive it on the same basis.
The Prohibition on Using Shared Data to Compete
Article 6(2)(e) of the Data Act contains a restriction that is easy to overlook but has major strategic implications: a data holder who provides data to a third party pursuant to a user sharing instruction is prohibited from using that same data to compete against the third party. More specifically, the data holder cannot use insights derived from the shared data to build competing products or services targeting the third party’s line of business.
This provision was inserted to address a specific competitive dynamic that regulators identified in digital markets: the situation where a manufacturer shares data with a service provider at the user’s request, then uses its privileged position as the data source to extract competitive intelligence and undercut that service provider in its own market. The prohibition creates a zone of protection around the third party’s use of the shared data.
In practice, this creates information barrier requirements within data holder organizations. If your engineering team and your competitive intelligence team both have access to outgoing data streams, you need governance controls that prevent the competitive intelligence function from drawing on data being transmitted to third-party recipients. This is a new kind of compliance obligation that most manufacturers have not previously had to consider.
The prohibition is not a blanket restriction on the data holder using the same categories of data for its own purposes. A manufacturer can continue to use device telemetry to improve its own products. What it cannot do is specifically use data that has been shared with a third party — particularly data shared in response to a user instruction — to build products or services that compete directly with what that third party does with the data. The line between permissible internal use and prohibited competitive use will require careful legal analysis in specific contexts.
What Third Parties Can and Cannot Do With the Data
Article 6 imposes a set of binding obligations on third parties that receive data through a user-directed sharing instruction. These obligations apply by operation of law and cannot be contracted away, either by the data holder or by the user.
The most fundamental obligation is purpose limitation. The third party must use the data only for the purpose the user specified when making the sharing request. If a user instructs their smart home device manufacturer to share energy consumption data with an energy auditing firm for the purpose of conducting an efficiency audit, the energy auditing firm cannot use that same data for marketing profiling, credit scoring, or any other purpose. The stated purpose of the sharing request defines the outer limit of permissible use.
Third parties are prohibited from sharing the data with further downstream parties without express authorization from the user. This is a strict prohibition — it is not enough that the user gave general consent to data sharing when they signed up for the third party’s service. The user must specifically authorize onward disclosure of data received through a Data Act sharing instruction.
Third parties are also prohibited from using the data to build profiles of the user for the purpose of making decisions that affect the user — particularly decisions related to employment, credit, insurance, healthcare, or similar high-stakes domains — unless the user has specifically consented to that use. This is a safeguard against the commoditization of personal data flowing through Data Act channels.
Where the data contains personal data, GDPR applies in full alongside the Data Act. The third party receiving personal data must have a valid legal basis under GDPR Article 6 for processing that personal data. The user’s instruction to share data under the Data Act does not automatically constitute GDPR consent for the third party’s processing — those are separate legal frameworks operating in parallel. US companies managing this intersection will need to ensure that their data sharing workflows correctly identify the applicable GDPR legal basis before any personal data flows to a third party.
Special Rules for Gatekeepers Under the Digital Markets Act
The Data Act includes a structural concern that goes beyond individual data transactions: the risk that large platform companies will use the data access framework to further consolidate their dominance. This concern is addressed through Article 5(2), which prohibits users from directing data sharing to entities that have been formally designated as gatekeepers under the Digital Markets Act.
The Digital Markets Act identifies gatekeepers as large digital platforms that serve as essential infrastructure for business users — companies like major search engines, social networks, app stores, cloud computing services, and messaging platforms. As of 2025, the European Commission has designated a specific list of companies and their core platform services as gatekeepers. This list includes several major US technology companies.
The prohibition is not an absolute bar on gatekeepers ever receiving IoT data. It specifically prohibits the use of Chapter II — the user-directed sharing mechanism — as the channel for that data transfer. If a business relationship between a manufacturer and a gatekeeper is established on independent commercial terms, data sharing may occur through other channels. What the Data Act prevents is the use of the user’s sharing instruction as a pipeline that feeds data to gatekeepers who already have significant informational advantages.
This distinction has practical implications for manufacturers who have existing commercial relationships with large platform companies. If you have a cloud analytics contract with a major technology company that happens to be a designated gatekeeper, you cannot use user sharing instructions under Article 5 to feed that arrangement. You would need to establish data flows through separately negotiated, direct contractual channels — and those channels may be subject to different regulatory scrutiny.
Implications for US Manufacturers’ Data Governance Frameworks
The combined effect of Chapter II’s third-party sharing provisions is to remove the data holder’s unilateral control over where device-generated data flows. For US manufacturers accustomed to treating their connected product data as proprietary inventory, this requires a fundamental rethinking of data governance.
At the product design level, the obligation to share data in interoperable formats means that proprietary data architectures that have served as moats will need to be supplemented — if not replaced — with open export capabilities. This is not merely an API requirement; it touches the core data model of your product. If your device stores data in a format that cannot be readily exported in a machine-readable open format, compliance will require engineering investment.
At the contractual level, you need to build mechanisms for receiving, validating, and executing user sharing instructions. You also need contracts or at least terms-of-service provisions that bind third parties receiving data to the Article 6 obligations before data is actually transmitted. This is analogous to the data processing agreement framework under GDPR — you need a documented record that the receiving party has committed to the statutory use restrictions.
At the organizational level, you need information barriers that prevent your competitive intelligence and product teams from using outgoing data streams as competitive intelligence against the third parties you are sharing with. This is a new category of compliance control that will require both policy and technical implementation.
Ultimately, the Data Act’s third-party sharing framework represents a regulatory bet that users, not manufacturers, should control the downstream use of the data generated by their own interactions with connected products. US manufacturers entering the EU market after September 12, 2025 will be entering a market where that principle is law.