This guide helps scope and operate Data Act access rights for connected-product and related-service data, including direct access, request-based access, and transfers to user-chosen third parties.
Use this guide with the EU Data Act and current Commission materials, then validate the access route against the product, data, user relationship, and applicable law.
The Data Act access and portability rights cover from connected products and related services, plus the metadata needed to interpret and use that data. Users may access the data themselves or ask the to make it available to a third party, subject to limits for security, trade secrets, personal data, recipient misuse, and the Article 7 enterprise exclusions. A privacy export follows a separate legal test.
1
Section 1
Which connected product and related service data must be made available to users under the EU Data Act?
Start with the Chapter II data categories. Product data is data generated by the use of a connected product that was designed to be retrievable through an electronic communications service, physical connection, or on-device access. data is data representing user actions or events connected with the product during the related service.
The practical access package is narrower than all data a company holds. It focuses on product data and data that the lawfully obtains or can lawfully obtain without disproportionate effort beyond a simple operation. The package should include relevant metadata needed to interpret and use the data.
Representative connected products include connected vehicles, industrial machinery, medical and fitness devices, and smart-home equipment. These are examples, not automatic classifications: the item must meet the Article 2 connected-product test, and the particular data must still meet the product-data, related-service-data, and availability tests.
Include raw and pre-processed data that is stored, retrievable, or transmitted externally by the product or .
Include basic context such as timestamp, units, identifiers, format, quality limits, and other metadata needed to make the data usable.
Do not treat inferred or derived analytics from proprietary, complex algorithms as automatically in scope unless a separate agreement or law requires it.
Do not treat unrelated textual, audio, or audiovisual content as connected-product data merely because the device records, displays, or plays it.
How should direct access and request-based access work?
For connected products and related services placed on the market after 12 September 2026, Article 3(1) requires product data, data, and necessary metadata to be accessible by default. Access must be easy, secure, free to the user, comprehensive, structured, commonly used, and machine-readable, and direct where relevant and technically feasible.
Article 4 is a separate request route and is not postponed by the Article 3(1) transition. When the user cannot directly access the data from the product or , the must provide and necessary metadata without undue delay, at the same quality available to the data holder, free of charge, and through a simple electronic request where technically feasible.
Use direct access for interfaces where the user can stream, download, or retrieve the data without a data-holder approval step.
Use indirect access for portals or request workflows where the must process the request before making data available.
Avoid interface designs that make Data Act choices unduly difficult or manipulate the user's choices.
Ask only for information necessary to verify that the requester qualifies as the user, and keep access logs only as necessary for request execution, infrastructure security, and maintenance.
What must be disclosed before purchase, lease, rental, or a related-service contract?
The Data Act access workflow starts before the user asks for data. For connected products, the seller, rentor, or lessor must tell the user the type, format, and estimated volume of product data the product can generate, whether it can generate data continuously and in real time, whether data is stored on-device or on a remote server, the intended retention duration where applicable, and how the user may access, retrieve, or erase the data where relevant.
For related services, the provider must give comparable information about product data it expects to obtain and related-service data it expects to generate. The service disclosure also needs the identity and contact route for the prospective , whether the data holder expects to use itself, whether third-party use is intended for purposes agreed with the user, and how the user can request or end third-party sharing.
Keep product and related-service disclosures aligned with the actual data inventory, retention configuration, and access channel.
Name the and any other data-processing parties clearly enough for a user to contact the right actor.
Describe API terms, quality of service, formats, and retention in operational language that support and product teams can implement.
Update user-facing information when product updates or service changes add accessible data or restrict initially accessible data.
How does a user direct the data holder to share data with a third party?
Article 5 gives the user the right to ask the to make and necessary metadata available to a third party. The transfer must be without undue delay, of the same quality available to the data holder, easy, secure, free of charge to the user, and in a comprehensive, structured, commonly used, machine-readable format. Where relevant and technically feasible, it should support continuous and real-time availability.
Third-party sharing is not limited to situations where the user lacks direct access. Commission FAQs state that a user can still request transfer to a third party even when the user already has direct access, provided there is a with .
Capture the user request, the authorized third party, the requested dataset, and the purpose agreed between the user and the third party.
Separate the user-facing request from the 's arrangements with the under Articles 8 and 9.
Do not treat Digital Markets Act gatekeepers as eligible third parties for the mandatory Article 5 mechanism.
Do not assume the Data Act obliges sharing with an operator outside the Union; the Commission FAQs say Chapter II mandatory sharing is limited to EU entities and persons.
What limits apply to users and third-party recipients?
The access right is not a right to misuse data. A user may not use Article 4 data to develop a connected product that competes with the product from which the data originates, share the data with a third party for that purpose, or use the data to derive insights about the manufacturer's or 's economic situation, assets, or production methods.
A third party that receives data under Article 5 may process it only for the purposes and conditions agreed with the user and subject to data protection law where personal data is involved. Article 6 also prohibits specific conduct, including manipulative user interfaces, unnecessary profiling, onward sharing without the required contract and safeguards, sharing with DMA gatekeepers, competing-product development, security-harming use, and undermining agreed trade-secret measures.
Article 7 excludes Chapter II data generated through products manufactured or designed, or related services provided, by qualifying microenterprises and small enterprises, subject to partner, linked-enterprise, and subcontracting conditions. A temporary rule also covers certain newly medium-sized enterprises and their connected products. Record the enterprise-group facts instead of assuming that a small supplier or product label settles the exclusion.
Put the agreed purpose in the user authorization and recipient terms before transfer.
Require deletion when data is no longer necessary for the agreed purpose, unless the user has agreed otherwise for non-personal data.
Block recipient use cases that would create a competing connected product from the accessed data.
Preserve consumer users' ability to make received data available to other parties where Article 6 protects that ability.
How should trade secrets be protected without a blanket refusal?
The Data Act preserves trade-secret protection but makes it procedural. For user access under Article 4, and third-party transmission under Article 5, the or trade-secret holder must identify protected data, including protected metadata, and agree proportionate technical and organizational measures before disclosure.
Withholding, suspension, or refusal should be exceptional and documented. If agreed measures are missing, not implemented, or confidentiality is undermined, the may withhold or suspend the sharing of identified trade-secret data and must provide a substantiated written decision without undue delay. A case-by-case refusal is available only in exceptional circumstances where serious economic damage is highly likely despite the measures taken, and the competent authority must be notified.
Identify trade-secret fields and metadata at field level instead of labelling an entire export as secret.
Use proportionate measures such as confidentiality terms, strict access controls, technical standards, codes of conduct, or model contractual terms.
Keep the objective basis for any serious-economic-damage assessment, especially confidentiality level, uniqueness, novelty, and enforceability concerns.
Give the user or third party a written, substantiated reason for withholding, suspension, or refusal, and preserve the complaint or dispute-settlement route.
Where is the GDPR boundary when the shared data is personal data?
The Data Act complements data protection law; it does not supersede it or create a new GDPR legal basis. The Commission FAQs state that the GDPR applies to all personal data processing under the Data Act and prevails in the event of conflict.
When the user is not the data subject whose personal data is requested, the may make personal data available to the user or third party only where there is a valid legal basis under Article 6 GDPR and, where relevant, the conditions for special-category data and terminal-equipment access are fulfilled. Users that are not data subjects, such as enterprises requesting personal data from IoT devices, may themselves be controllers and must meet GDPR obligations.
Classify each field as personal data, non-personal data, mixed data, trade secret, or other protected material before release.
When several people use the same product, avoid exposing another data subject's personal data unless the GDPR basis and safeguards are satisfied.
Use anonymization or narrower disclosure where that is the lawful way to respect other data subjects' rights, but do not use privacy-preserving processing as a pretext to avoid Data Act sharing.
Preserve the data protection authority route for issues concerning personal data processing under the Data Act.
A useful Data Act access record connects the legal trigger to the dataset, actor, channel, safeguards, and outcome. It should be specific enough to show why a user received data, why a third party was authorized, why a field was excluded, or why sharing was suspended or refused.
The record should also support future portability. If telemetry, account structure, retention, APIs, or related-service contracts change, the access package and user-facing disclosures should be reviewed against the same source rules.
Data inventory: product or related-service event, field name, raw or pre-processed status, metadata, format, source system, retention, and whether it is readily available.
Actor record: user identity or authority, product or service relationship, third-party recipient, EU-presence check where relevant, and agreed purpose.
Outcome record: direct access route, indirect request decision, delivery receipt, format, timestamp, refusal or partial-delivery reason, authority notification where required, and dispute or complaint status.
Use the access scope, recipient terms, GDPR checks, trade-secret safeguards, and delivery records from this guide to structure product, support, legal, and engineering work.
Supports the practical framing that users of connected devices can access, use, and share raw device data for repair, maintenance, industrial, and other services.