EU Data Act Data Holder Obligations: Guide for Connected-Product Manufacturers (2026)

Last updated: 11 September 2026

The term data holder appears throughout the EU Data Act, but it is often used too casually.

Many connected-product manufacturers will be data holders for at least some product data or related-service data. But “manufacturer” and “data holder” are not automatically synonymous.

The role matters because the Data Act assigns significant obligations to data holders, including obligations around:

• pre-contractual transparency;
• user access to readily available data;
• user-directed sharing with third parties;
• data-use contracts;
• restrictions on using data to undermine users or recipients;
• trade-secret safeguards;
• security restrictions;
• personal-data compliance;
• conditions and compensation when data are made available to professional recipients.

This guide explains who qualifies as a data holder, how the role differs from manufacturer/user/data recipient, and what a connected-product business should build operationally to fulfil the role.

Important: This is informational guidance, not legal advice. Data-holder status can depend on the technical architecture, legal rights/obligations, contracts, related-service model and applicable EU/national law.

Quick answer: what is a “data holder” under the Data Act?

Article 2(13) of Regulation (EU) 2023/2854 currently defines a data holder as a natural or legal person that has the right or obligation, under the Data Act, applicable EU law or qualifying national legislation, to use and make available data, including — where contractually agreed — product data or related-service data retrieved or generated during the provision of a related service.

Primary source:

Regulation (EU) 2023/2854 — Article 2 definitions

The practical question is not:

Who owns the device?

It is closer to:

Which party lawfully has the right or obligation to use/make available the relevant product or related-service data?

Is the manufacturer always the data holder?

No.

A manufacturer will often be the data holder because it operates the backend, retrieves product data, provides the related service or has contractual rights to use the data.

But different architectures can separate the roles.

Example 1 — manufacturer is data holder

Manufacturer sells a connected industrial sensor and operates the cloud service that receives its telemetry.

The manufacturer may be the relevant data holder.

Example 2 — service provider is data holder

Manufacturer sells hardware, while another company operates the related service and lawfully retrieves/generates relevant data.

Data-holder responsibilities can sit partly or primarily with that service provider.

Example 3 — several data holders

A connected system can include:

• hardware manufacturer;
• platform provider;
• component manufacturer;
• related-service provider.

Different parties may hold rights/obligations for different datasets.

Recital 21 recognizes situations involving several manufacturers or related-service providers integrated for the same user, and notes that the user may need to turn to each party with which it has a contract.

The lesson:

Build a dataset-by-dataset role map rather than one global “manufacturer = data holder” assumption.

Data holder vs user vs data recipient

The Data Act uses different roles for different functions.

User

A natural or legal person that owns a connected product, has certain temporary rights to use it (for example rental/lease), or receives a related service.

The user exercises Article 4 and Article 5 rights.

Data holder

The party with the relevant legal right/obligation to use and make data available.

Data recipient

A professional recipient to whom the data holder makes data available, including a third party receiving data following the user's Article 5 request or another mandatory legal basis.

Manufacturer

The entity manufacturing/designing the connected product.

It may also be:

• seller;
• data holder;
• related-service provider;

but those roles should be tested rather than assumed.

Data-holder obligations start before the user makes a request

For the product-scope step in this readiness work, see the Connected Product Guide.

Data-holder readiness is not only a support-ticket workflow.

The Data Act expects the business to establish the legal/technical foundation before requests arrive.

For many connected-product businesses, this includes:

1. map connected products and related services;
2. map generated/readily available data;
3. identify data holder(s);
4. establish contractual rights to use non-personal data;
5. publish Article 3 information;
6. provide direct/request-based access;
7. support third-party sharing;
8. protect trade secrets/security/personal data;
9. maintain records and escalation paths.

Obligation 1: Article 3 related-service transparency

Article 3(3) asks prospective users to receive information before entering a contract for a related service.

This includes, among other points:

• the nature/volume/frequency of product data the prospective data holder expects to obtain;
• the nature/estimated volume of related-service data;
• access/retrieval arrangements;
• storage and retention;
• whether the prospective data holder expects to use readily available data itself and for what purposes;
• whether it intends to allow third-party use for purposes agreed with the user;
• identity/geographical address of the prospective data holder;
• other processing parties where applicable;
• efficient contact method;
• how the user can request/end third-party sharing;
• complaint rights;
• trade-secret holder identity;
• contract duration/termination.

For the dedicated guide:

EU Data Act Related Service Data Notice: Article 3(3) Guide

This means the data-holder role must already be understood during contracting/product onboarding.

Obligation 2: Article 4 user access

Where relevant data are not directly accessible from the connected product/related service, Article 4(1) requires the data holder to make readily available data and necessary metadata accessible to the user.

The data must be:

• without undue delay;
• easy and secure;
• free to the user;
• same quality as available to data holder;
• comprehensive;
• structured;
• commonly used;
• machine-readable;
• continuous/real-time where relevant and technically feasible.

The request route should be simple and electronic where technically feasible.

Operationally, a data holder needs:

• request channel;
• user verification;
• dataset mapping;
• export/API;
• metadata;
• privacy/security/trade-secret review;
• response tracking.

See:

EU Data Act Data Access Request Template: Article 4 Guide

Obligation 3: verify users proportionately

Article 4(5) restricts the information the data holder can require to verify user status.

Do not collect more information than necessary.

The data holder also should not keep access-request information/logs beyond what is necessary for:

• sound execution of the request;
• security;
• maintenance of the infrastructure.

This is an important privacy-by-design principle for the request portal itself.

Good implementation

Use existing:

• login/account;
• product registration;
• serial/VIN association;
• contract/lease relationship.

Weak implementation

Create a new form asking for:

• unnecessary identity documentation;
• unrelated company data;
• information already proven by authenticated account.

Obligation 4: support Article 5 user-directed third-party sharing

Article 5 requires the data holder, at the user's request, to make readily available data and metadata available to an eligible third party.

That requires a second operational path:

User
  ↓ requests sharing
Data holder
  ↓ verifies roles + safeguards
Third party / data recipient
  ↓ receives structured data

Important controls include:

• recipient eligibility;
• purpose;
• personal-data legal basis;
• trade-secret safeguards;
• technical transfer;
• Article 8/9 terms/compensation where applicable.

See:

EU Data Act Third-Party Data Sharing Request Template

Obligation 5: do not make rights unnecessarily difficult

Article 4(4) prohibits data holders from making users' exercise of Article 4 rights unduly difficult, including through non-neutral user interfaces or designs that subvert user autonomy/choice.

This matters to UX.

A compliant request portal should avoid:

• hiding the request behind unrelated support flows;
• repeated loops;
• misleading “recommended” choices;
• unclear eligibility statements;
• artificial friction designed to discourage access.

A simple electronic request should look simple.

Obligation 6: contract before using readily available non-personal data

Article 4(13) is one of the most important B2B manufacturer rules.

It says a data holder may use readily available non-personal data only on the basis of a contract with the user.

That means the Data Act does not itself grant the manufacturer a broad new right to use non-personal connected-product data.

Recital 25 reinforces this: where a manufacturer is the data holder, its basis for using non-personal product/related-service data should be a contract with the user.

Potential purposes might include:

• product improvement;
• service improvement;
• developing new services/products;
• aggregation/derived outputs;

but they should be transparent and contractually grounded.

Contract review questions

• Do current sales/lease/related-service terms authorize the intended non-personal data uses?
• Are purposes transparent?
• Are legacy products/users covered?
• Is the actual data holder the contracting party?
• Are third-party uses aligned with the user contract?

The Commission's non-binding Model Contractual Terms can help structure these relationships.

European Commission — Model Contractual Terms

Obligation 7: do not use non-personal data to undermine the user's commercial position

Article 4(13) also prohibits data holders from using readily available non-personal data to derive insights about the user's:

• economic situation;
• assets;
• production methods;
• use;

in a way that could undermine the user's commercial position in its markets.

This rule is especially relevant for industrial products.

Example:

A machine manufacturer sees detailed operational data from factories using its equipment.

It should not exploit those non-personal data to infer commercially sensitive facts about the customer's:

• production capacity;
• utilization;
• financial distress;
• production methods;

in a way that undermines the customer competitively.

Product analytics governance should therefore distinguish:

improving the product/service

from:

exploiting customer operational data against the customer.

Obligation 8: limit other third-party disclosure of non-personal product data

Article 4(14) limits data holders making non-personal product data available to third parties for commercial or non-commercial purposes beyond fulfilment of their contract with the user.

Where relevant, third parties should be contractually bound not to further share data received from the data holder.

This creates a practical data-governance question:

Which vendors/processors/partners receive product data, under what contract, and for which user-agreed purpose?

Do not assume a manufacturer can freely monetize all non-personal telemetry simply because it is non-personal.

Obligation 9: security restrictions must use the actual Article 4 standard

Article 4(2) permits restrictions where access/use/sharing could undermine security requirements of the connected product laid down in EU/national law and create a serious adverse effect on health, safety or security of natural persons.

This is a narrow safeguard, not a generic security override.

A data holder should document:

• security requirement;
• adverse-effect risk;
• affected data/action;
• restriction;
• authority notification where required.

Obligation 10: protect trade secrets without using them as a blanket refusal

Articles 4 and 5 contain detailed trade-secret safeguards.

The data holder/trade-secret holder should:

• identify trade-secret data;
• agree proportionate technical/organizational measures;
• continue sharing non-problematic data;
• withhold/suspend specific secrets only under the regulation's conditions;
• use the exceptional serious-economic-damage refusal case by case;
• provide written substantiation;
• notify the competent authority where required.

Dedicated guide:

EU Data Act Trade Secrets: Articles 4 and 5 Guide

Obligation 11: keep GDPR/ePrivacy separate but integrated

Connected-product datasets can include personal data.

The Data Act does not create a general new legal basis to collect or use personal data.

Where the user is not the data subject whose personal data are requested, Article 4/5 require a valid GDPR legal basis before disclosure.

A data holder should build a joint review model:

Data Act scope
   +
GDPR/ePrivacy check
   +
security/trade-secret check
   =
fulfilment decision

See:

EU Data Act vs GDPR for Connected Products

Obligation 12: third-party recipient terms and compensation

Article 5 sharing to professional third parties can trigger Articles 8 and 9.

The data holder may need contractual terms addressing:

• data transfer;
• technical interface;
• use restrictions;
• confidentiality;
• trade-secret safeguards;
• compensation where permitted;
• service levels;
• liability.

The Commission has published non-binding Model Contractual Terms specifically for:

• Data Holder to User;
• User to Data Recipient;
• Data Holder to Data Recipient.

These are useful implementation references rather than mandatory forms.

Data holder operational architecture

A mature connected-product company should have a map like:

This should be treated as product/data governance, not a one-time legal memo.

Data-holder readiness checklist

Role map

• Manufacturer identified.
• Related-service provider identified.
• Data holder(s) identified by dataset.
• User relationships identified.
• Third-party/data-recipient scenarios mapped.

Data inventory

• Product data mapped.
• Related-service data mapped.
• Readily available data identified.
• Metadata identified.
• Inferred/derived data separated.
• Personal/non-personal classification performed.
• Trade secrets identified.

Contracts

• Non-personal data-use basis exists with users.
• Data-use purposes are transparent.
• Third-party data use is controlled.
• Related-service Article 3(3) disclosure matches reality.

User access

• Direct access route documented.
• Article 4 request route exists.
• Verification is proportionate.
• Machine-readable export/API exists.
• Metadata are supplied.
• No user access charge.

Third-party sharing

• Article 5 request path exists.
• Recipient eligibility checked.
• Recipient terms/compensation workflow exists.
• Article 6 restrictions are addressed.

Safeguards

• GDPR/ePrivacy review exists.
• Security escalation exists.
• Trade-secret safeguards/refusal workflow exists.
• Competent-authority notification workflow exists.
• Redress/dispute routes documented.

Common data-holder mistakes

1. Assuming manufacturer = data holder for every dataset

Map the real rights/technical architecture.

2. Having Article 3 notices but no Article 4 request process

Pre-contractual transparency and post-sale access are different operational obligations.

3. Using telemetry without a contract with the user

Article 4(13) matters for non-personal readily available data.

4. Monetizing non-personal data as if “non-personal” means unrestricted

Article 4 places contractual/use limits on data holders.

5. Building a manual access process with no metadata

Machine-readable data without interpretation can be useless.

6. Over-verifying users

Article 4/5 verification is limited to what is necessary.

7. Treating trade secrets as a blanket exclusion

Use the specific safeguards.

8. Ignoring personal-data lawful basis

The Data Act does not replace GDPR.

9. Failing to distinguish user access and third-party sharing

Article 4 and Article 5 workflows differ.

10. No owner for ongoing changes

Firmware, storage, contracts and APIs evolve.

Frequently asked questions

What is a data holder under the EU Data Act?

A person with the relevant right or obligation under the Data Act/other applicable law to use and make data available, including qualifying product/related-service data in the circumstances described by Article 2(13).

Is every manufacturer a data holder?

No. Manufacturers often are data holders, but the role can sit with a related-service/platform provider or be split across parties/datasets.

Can there be more than one data holder?

Yes. Complex connected systems can involve multiple parties with rights/obligations over different datasets.

Does the Data Act give a data holder the right to use all product data?

No. Article 4(13) requires a contractual basis with the user for the data holder's use of readily available non-personal data, and personal-data use still needs GDPR compliance.

Can a data holder charge the user for Article 4 access?

No. Article 4 access is free of charge to the user.

Can a data holder charge a third-party recipient?

Separate Articles 8/9 compensation rules can apply to professional data recipients, subject to their conditions.

Can a data holder refuse access because of trade secrets?

Only through the Data Act's specific safeguard/withhold/suspend/exceptional-refusal process for identified trade-secret data.

Can it refuse because of security?

Article 4 permits security-based restrictions under the specific serious-adverse-effect standard tied to legal product-security requirements.

Must a data holder offer an electronic request form?

Article 4 says the request should be simple and through electronic means where technically feasible.

Must it provide metadata?

Yes, relevant metadata necessary to interpret and use the requested data are included.

Can the data holder use user telemetry to infer the user's production output?

Article 4(13) restricts use of non-personal readily available data to derive insights about the user's economic situation/assets/production methods/use in ways that undermine the user's commercial position.

Does GDPR still apply to a data holder?

Yes. The Data Act does not replace GDPR/ePrivacy where personal data are involved.

What should a data-holder contract cover?

At minimum, review purposes for non-personal data use, user rights/access, third-party sharing mechanisms, confidentiality and other Data Act/GDPR terms relevant to the product/service.

Are Commission Model Contractual Terms mandatory?

No. They are non-binding implementation aids that can help structure Data Act data-access/data-sharing contracts.

Does the pending Digital Omnibus change the current definition now?

As of 11 September 2026, COM(2025) 837 remains in an ongoing ordinary legislative procedure. This Guide therefore uses the current Data Act text in force.

Primary sources and further reading

1. Regulation (EU) 2023/2854 — EU Data Act
2. European Commission — Data Act
3. European Commission — Data Act explained
4. European Commission — Data Act FAQ v1.4
5. European Commission — Model Contractual Terms
6. European Commission — Data Act Legal Helpdesk
7. Digital Omnibus procedure 2025/0360/COD — EUR-Lex

RegCatalog provides informational product-data tooling and implementation resources. It does not provide legal advice or certification.