RegCatalog

Last updated: 11 September 2026

One of the most commercially important rights in the EU Data Act is not simply the right to receive connected-product data yourself.

It is the right to ask the data holder to make the data available directly to a third party of your choice.

That third party might be:

  • an independent repair provider;
  • a predictive-maintenance company;
  • a fleet-management provider;
  • an energy-optimization service;
  • a smart-building analytics company;
  • an agricultural advisory service;
  • a research organization;
  • another professional service provider using the data for a purpose agreed with the user.

Article 5 creates that user-directed data-sharing route. Article 6 then controls what the third-party recipient may and may not do with the data.

This guide provides a practical EU Data Act third-party data sharing request template, explains the obligations of the data holder and recipient, covers trade secrets/GDPR/gatekeeper restrictions, and shows how manufacturers should operationalize the workflow.

Important: This is informational guidance, not legal advice. The exact data, personal-data basis, recipient status, trade-secret measures, compensation and security conditions can vary by case.

Quick answer: what does Article 5 do?

Article 5(1) says that, at the request of a user or a party acting on behalf of a user, the data holder must make available to a third party:

  • readily available data;
  • relevant metadata necessary to interpret and use those data.

The data must be made available:

  • without undue delay;
  • of the same quality available to the data holder;
  • easily;
  • securely;
  • free of charge to the user;
  • in a comprehensive, structured, commonly used and machine-readable format;
  • continuously and in real time where relevant and technically feasible.

The data holder makes the data available to the third party in accordance with Articles 8 and 9, which govern conditions/compensation when data are made available to data recipients.

Primary source:

Regulation (EU) 2023/2854 — Article 5

Article 4 vs Article 5

The distinction is simple but operationally important.

Article 4

The data holder makes the data available to the user.

Example:

An industrial machine operator downloads its own machine telemetry.

Article 5

The user asks the data holder to make the data available to a third party.

Example:

The machine operator asks the manufacturer/data holder to provide telemetry directly to an independent predictive-maintenance service.

For direct user access, see:

EU Data Act Data Access Request Template: Article 4 Guide

What is a “third party” under Article 5?

The Data Act uses third-party sharing broadly.

A third party can be a natural or legal person receiving data at the user's request, subject to the regulation's restrictions.

Recital 33 gives examples including:

  • consumers;
  • enterprises;
  • research organizations;
  • non-profits;
  • professional entities.

In commercial connected-product markets, likely recipients include:

  • repairers;
  • maintenance contractors;
  • analytics companies;
  • energy managers;
  • aftermarket service providers;
  • insurers where legally appropriate;
  • fleet operators/providers;
  • consultants;
  • integrators.

But Article 5 includes a major exclusion:

undertakings designated as gatekeepers under the Digital Markets Act are not eligible third parties for this Article 5 route.

Gatekeepers are not eligible Article 5 recipients

Article 5(3) says a DMA-designated gatekeeper is not an eligible third party.

The Article also prohibits gatekeepers from, among other things:

  • soliciting or financially incentivizing users to give them data obtained through Article 4 access;
  • incentivizing users to request that data holders share data with one of their services under Article 5;
  • receiving data from users that users obtained through Article 4.

This is a specific structural limit intended to prevent the new access right from simply reinforcing existing gatekeeper power.

For a real request, confirm that the selected third-party recipient is legally eligible.

Copyable Article 5 third-party sharing request template

This is a practical RegCatalog drafting aid, not an official EU form.

Subject: Request to make connected-product data available to a third party under Article 5 of Regulation (EU) 2023/2854

Dear [Data holder / Data Act contact],

I am requesting that you make the readily available product data and/or related-service data identified below available to the third-party recipient named in this request, under Article 5 of Regulation (EU) 2023/2854 (EU Data Act).

User / requester

Name or organization: [User]

Contact: [Email / account]

Relationship to product/service: [Owner / renter / lessee / authorized business user]

Product: [Product name]

Manufacturer / brand: [Manufacturer]

Model / identifier: [Model / serial / VIN / device ID]

Related service/account: [If applicable]

Third-party recipient

Recipient legal/trading name: [Third party]

Recipient contact: [Email / technical contact]

Recipient address: [Where appropriate]

Purpose agreed with the user: [Maintenance / repair / analytics / optimization / other]

Recipient delivery endpoint: [Secure API / portal / transfer location, if agreed]

Data requested for sharing

Period: [Date/time range]

Data categories: [Specific categories / all readily available data relevant to agreed purpose]

Please include the relevant metadata necessary for the recipient to interpret and use the data, such as field descriptions, units, timestamps, schema/code lists or equivalent documentation where necessary.

Delivery requirements

Where applicable, please make the data available to the third party:

  • without undue delay;
  • at the same quality available to the data holder;
  • easily and securely;
  • free of charge to me as the user;
  • in a comprehensive, structured, commonly used and machine-readable format;
  • continuously and in real time where relevant and technically feasible.

Preferred technical method where available:

[API / secure download / stream / other]

Authority and verification

I authorize this third party to receive the identified data for the purpose stated above.

Please request only information necessary to verify:

  • my status as the user;
  • the recipient's identity/eligibility;
  • the secure execution of the request.

Personal data

Where the requested dataset includes personal data, please apply the applicable GDPR/ePrivacy requirements. If I am not the data subject for all personal data in the requested dataset, please identify any lawful-basis or authorization requirements that must be satisfied before disclosure.

Trade secrets / confidentiality

If identified data contain trade secrets, please identify those specific data and propose the proportionate technical and organizational confidentiality measures required under the Data Act.

If sharing is withheld, suspended or refused, please provide the written substantiation required under the applicable Data Act provisions and information about the relevant redress routes.

Please confirm receipt of this request and the next steps required for the third-party data transfer.

Kind regards, [User / authorized representative]

What should an Article 5 request contain?

A practical Article 5 request needs enough information to identify four things:

  1. the user;
  2. the connected product/related service;
  3. the third-party recipient;
  4. the requested data and purpose.

Identify the recipient clearly

For business recipients, use:

  • legal/trading name;
  • contact;
  • technical endpoint/contact where relevant;
  • purpose.

This is especially important because the data holder has obligations to verify eligibility and secure the transfer.

Identify the agreed purpose

Article 6 says the third party may process the data only for the purposes and under the conditions agreed with the user.

So avoid vague language such as:

for any business purpose.

Prefer:

predictive maintenance for the user's industrial pumps at Site A.

or:

energy optimization analysis for the user's building-management system.

The purpose defines the recipient's permitted processing and can also affect trade-secret/personal-data safeguards.

What data can be shared?

For product-scope definitions and examples, see the Connected Product Guide.

Article 5 uses the same key concept as Article 4:

readily available data plus relevant metadata.

That can include relevant product data and related-service data the data holder lawfully obtains/can obtain without disproportionate effort beyond a simple operation.

It does not automatically include:

  • every inferred insight;
  • every proprietary analytic model;
  • content;
  • data that are technically unavailable without disproportionate new processing.

For the definition, see the EU Data Act.

The recipient should receive metadata too

A third-party maintenance or analytics provider often needs context such as:

  • units;
  • timestamps;
  • schema;
  • sampling interval;
  • event/error codes;
  • device identifiers;
  • data dictionary;
  • API specification.

Article 5(1) explicitly includes relevant metadata necessary to interpret and use the data.

A transfer of opaque values without interpretation metadata may defeat the practical purpose of the right.

User does not pay, but the third party may face compensation terms

Article 5 says the data must be made available free of charge to the user.

That does not mean every B2B third-party transfer is economically free to the data recipient.

Articles 8 and 9 govern conditions and compensation when data holders are obliged to make data available to data recipients.

The Commission has also developed non-binding Model Contractual Terms (MCTs) covering:

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

These are intended as voluntary implementation aids, particularly useful for SMEs.

Commission source:

Model Contractual Terms for Data Act data access and use

Do not confuse:

free of charge to the user

with:

no commercial conditions can ever exist between the data holder and professional data recipient.

Third-party recipient obligations under Article 6

Article 6 is essential to Article 5 implementation.

The third party must process received data only for the purposes/conditions agreed with the user and must respect data-protection law where personal data are involved.

For non-personal data, the recipient must erase the data when they are no longer necessary for the agreed purpose unless otherwise agreed with the user.

Article 6 also restricts several practices.

No manipulative user interface

The third party must not make exercising the user's Article 5/6 choices unduly difficult through coercive, deceptive, manipulative or non-neutral design.

Profiling restrictions

The third party must not use the data for profiling unless profiling is necessary to provide the service requested by the user, subject to the regulation/GDPR context.

Further sharing is controlled

The recipient cannot simply redistribute data freely.

Further transfer requires a contract with the user and, where trade secrets are involved, appropriate confidentiality measures.

No sharing to DMA gatekeepers

The recipient must not make the received data available to a designated gatekeeper.

No competing connected product

The recipient must not use the data to develop a connected product that competes with the connected product from which the data originate.

This restriction protects product-development incentives while still allowing competitive services around the product.

No harmful use against the data holder

Third parties must not use non-personal product/related-service data to derive insights about the data holder's economic situation, assets, production methods or use in the prohibited way.

No adverse security impact

The recipient must not use the data in a manner that adversely impacts the security of the connected product/related service.

Aftermarket competition: what is allowed?

The Data Act deliberately supports aftermarket services.

A third party can potentially use product data to provide services that compete with services offered by the manufacturer/data holder, such as:

  • independent repair;
  • independent maintenance;
  • diagnostics;
  • optimization;
  • analytics.

The key prohibition is not:

you may not compete with the manufacturer at all.

It is:

the data may not be used to develop a competing connected product.

That distinction is fundamental to the Data Act's policy goal of enabling new data-driven services.

Verification limits

Article 5(4) limits the information that can be demanded to verify whether the person qualifies as a user or third party.

The user/third party should not be required to provide information beyond what is necessary.

The data holder also must not retain information about the third party's access beyond what is necessary for:

  • sound execution of the access request;
  • security and maintenance of the data infrastructure.

Manufacturers should therefore avoid overbuilding a Know-Your-Customer-style process where a simpler verification route is enough.

Personal data when the user is not the data subject

This is one of the most important Article 5 complications.

Article 5(7) says that where the user is not the data subject whose personal data are requested, the data holder may make those personal data available only where there is a valid GDPR legal basis and, where relevant, other applicable conditions.

Example:

A logistics company is the Data Act user of a connected vehicle fleet.

The vehicle data include:

  • vehicle telemetry;
  • driver identifiers;
  • location data relating to employees.

The company's user status does not by itself create a legal basis to disclose every driver's personal data to an analytics vendor.

The data holder/user/recipient need an appropriate data-protection analysis.

For more:

EU Data Act vs GDPR for Connected Products

Trade secrets under Article 5

Article 5 includes a specific trade-secret protection process.

At a high level:

  1. trade secrets must be preserved;
  2. trade-secret data should be identified;
  3. the data holder/trade-secret holder and third party agree proportionate technical/organizational safeguards;
  4. specific trade-secret data can be withheld/suspended if safeguards are not agreed/implemented or confidentiality is undermined;
  5. in exceptional circumstances, a trade-secret holder can refuse specific data case by case if it can objectively demonstrate a high likelihood of serious economic damage despite safeguards;
  6. the refusal must be substantiated/written and the competent authority notified;
  7. the third party has redress routes.

The dedicated Guide is here:

EU Data Act Trade Secrets: Articles 4 and 5 Guide

Prototype/testing data exception

Article 5(2) says Article 5(1) does not apply to readily available data in the context of testing new connected products, substances or processes that have not yet been placed on the market, unless third-party use is contractually permitted.

That prevents Article 5 from becoming a general right to access pre-market R&D/test data.

Do not confuse this with data from an already marketed connected product being used in normal operation.

Article 5 request workflow for manufacturers

For the wider operational role behind this workflow, see the Data Holder Obligations Guide.

A scalable workflow might be:

User request
   ↓
Verify user authority
   ↓
Verify third-party identity/eligibility
   ↓
Identify datasets + metadata
   ↓
Personal data review
   ↓
Trade secret / security review
   ↓
Data-holder ↔ recipient terms where required
   ↓
Secure transfer / API access
   ↓
Monitor purpose/security constraints

Request intake

Collect only what is needed:

  • user/account;
  • product/service;
  • recipient;
  • purpose;
  • data/time range;
  • technical endpoint.

Recipient terms

For recurring B2B access, one-off support emails are not scalable.

Consider standard contractual workflows consistent with the Commission's Model Contractual Terms.

Technical delivery

Possible mechanisms:

  • REST API;
  • streaming API;
  • SFTP/secure transfer;
  • scheduled structured export;
  • customer-authorized data portal.

The format should match the Article 5 machine-readable standard and the practical use case.

Article 5 vs GDPR portability

Article 5 and GDPR Article 20 can overlap but are not identical.

Data Act

  • connected-product / related-service context;
  • can include non-personal data;
  • user-directed third-party sharing;
  • specific data-holder/recipient safeguards.

GDPR portability

  • personal data;
  • data subject;
  • GDPR-specific conditions/scope.

A user that is not the data subject cannot treat Article 5 as a shortcut around GDPR legal-basis requirements.

Common mistakes

1. Sending the data to the user when the request is to send it to the third party

Article 5 is designed for direct user-directed sharing.

2. Treating Article 5 as unlimited data portability

It concerns readily available product/related-service data and relevant metadata, subject to safeguards.

3. Charging the user

Article 5 access is free to the user, even though professional recipient compensation rules may apply separately.

4. Accepting a gatekeeper as recipient

DMA-designated gatekeepers are excluded from Article 5 eligibility.

5. Ignoring Article 6 recipient restrictions

The recipient does not receive unrestricted rights over the data.

6. Blanket trade-secret refusal

Use the Article 5 safeguard/refusal process.

7. Sharing personal data without GDPR basis

User status is not automatically enough where the user is not the data subject.

8. Treating competitive aftermarket service as prohibited

The prohibition is on developing a competing connected product, not all competing services.

9. Collecting excessive verification information

Article 5 limits verification data.

10. Leaving recipient purpose undefined

Article 6 ties processing to the purpose/conditions agreed with the user.

Article 5 checklist — user

  • You are the Data Act user of the product/service.
  • Product/account is identified.
  • Recipient is identified.
  • Recipient is not an ineligible DMA gatekeeper.
  • Purpose is documented.
  • Data/time range is defined.
  • Metadata are requested.
  • Preferred technical delivery is stated.
  • Personal-data implications are considered.
  • Trade-secret safeguards can be agreed if needed.

Article 5 checklist — data holder

  • Simple request channel exists.
  • User verified proportionately.
  • Third party verified proportionately.
  • Recipient eligibility checked.
  • Readily available datasets identified.
  • Metadata identified.
  • Personal data lawful-basis check exists.
  • Trade-secret process exists.
  • Security restrictions evaluated correctly.
  • Recipient terms/compensation workflow exists where applicable.
  • Structured machine-readable transfer route exists.
  • Request/access logs are limited to what is necessary.
  • Refusal/suspension decisions are substantiated and documented.

Frequently asked questions

What is Article 5 of the EU Data Act?

It gives users a right to request that a data holder make readily available connected-product/related-service data and relevant metadata available to a third party of the user's choice, subject to the Data Act's conditions.

Is there an official Article 5 request form?

No universal form is prescribed. The template in this Guide is a practical RegCatalog drafting aid.

Can I ask the manufacturer to send my machine data to an independent repairer?

Potentially yes, where the Article 5 conditions are met and the data are in scope. Independent aftermarket services are an important Data Act use case.

Can the recipient be another commercial company?

Yes, subject to eligibility and the applicable Article 5/6 restrictions.

Can a DMA gatekeeper be the Article 5 third party?

No. Article 5 expressly excludes designated gatekeepers as eligible third parties.

Does the user pay for the transfer?

Article 5 says the data are made available free of charge to the user. Separate compensation rules can apply between data holder and professional data recipient under Articles 8/9.

What data are included?

Readily available product/related-service data plus relevant metadata necessary to interpret and use them.

Does the recipient have to delete the data later?

Article 6 says the third party must erase the data when no longer necessary for the agreed purpose, unless otherwise agreed with the user for non-personal data.

Can the recipient use the data for any purpose?

No. Processing is limited to the purposes and conditions agreed with the user, plus the legal restrictions in Article 6.

Can the recipient build a competing product?

Article 6 prohibits using the data to develop a connected product that competes with the connected product from which the data originate.

Can it provide a competing service?

The Data Act is designed to enable third-party/aftermarket services. The competing-product restriction is not a blanket ban on service competition.

Do trade secrets block sharing automatically?

No. Article 5 provides a confidentiality safeguard process and exceptional refusal route for specific trade-secret data.

What if the data include employee or customer personal data?

GDPR continues to apply. If the Data Act user is not the data subject, a valid GDPR legal basis is required for the personal-data disclosure.

Does the request need metadata?

Yes. Article 5 includes relevant metadata necessary to interpret and use the data.

Can access be continuous or real-time?

Where relevant and technically feasible, Article 5 contemplates continuous and real-time access.

Primary sources and further reading

  1. Regulation (EU) 2023/2854 — EU Data Act
  2. European Commission — Data Act explained
  3. European Commission — Data Act FAQ v1.4 page
  4. European Commission — Model Contractual Terms for data access/use
  5. European Commission — Data Act Legal Helpdesk
  6. ADAC — Article 5 data-sharing request example and automotive implementation

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