EU Data Act Direct Access by Design FAQ

Article 3 requires the product and related service to make product data, related-service data, and the relevant metadata easy, secure, free of charge, comprehensive, structured, commonly used, and machine-readable by default. It requires direct access only where direct access is relevant and technically feasible; otherwise the Article 4 request route applies to readily available data.

Product teams should decide during architecture, release, and UX design whether the user will retrieve data from on-device storage, an app, an account portal, an API, or a remote server. Record why direct access is or is not relevant and technically feasible for each data category. A preference for manual support is not itself a technical-feasibility assessment.

Before applying the design gate, check Article 7. Chapter II does not apply to data from products manufactured or designed, or related services provided, by a qualifying microenterprise or small enterprise unless a non-qualifying partner or linked enterprise is present or the work was subcontracted to a non-qualifying enterprise. A qualifying medium-sized enterprise receives the same treatment for less than one year after it becomes medium-sized, and its connected products receive the treatment for one year after placement on the market. Record enterprise status, partner and linked enterprises, subcontracting, and the relevant dates instead of assuming that every small brand qualifies.

The design should cover product data and related-service data within Article 3, including relevant metadata. For the Article 4 request route, readily available data is product data and related-service data that the data holder lawfully obtains, or can lawfully obtain, without disproportionate effort beyond a simple operation. The covered data includes relevant raw and pre-processed data.

The data map should distinguish raw data, pre-processed data, relevant metadata, personal data, non-personal data, inferred or derived data, trade-secret material, and data that is not stored or transmitted by the product design. Inferred or derived insights produced through additional investment, such as proprietary analytics, should not be mixed into the direct-access dataset unless the parties have agreed otherwise.

Article 4 applies where the user cannot directly access the data from the connected product or related service. In that case, the data holder must make readily available data and necessary metadata accessible to the user without undue delay, with the same quality available to the data holder, and through a simple electronic request where technically feasible.

A product can therefore need both paths: direct access for data that can be exposed by design, and a request-based route for data that cannot be directly accessed. The request route should not be used to compensate for avoidable design gaps in a new product that falls under Article 3.

No. The Commission FAQ states that users can still ask a data holder to transfer data to a third party under Article 5 even where the user already has direct access under Article 3. Direct access helps the user retrieve data, but it does not supersede the separate user right to have a data holder make readily available data available to a chosen third party.

The product design should therefore avoid a dead end where the user can download data but cannot authorize third-party sharing. Teams should provide a clear route for third-party requests, eligibility checks, trade-secret safeguards, and refusal or suspension records where the Data Act allows them.

Before a connected-product contract, Article 3 requires clear and comprehensible information about the type, format, and estimated volume of product data; whether data can be generated continuously and in real time; storage location and retention where applicable; and how the user may access, retrieve, or erase the data.

Before a related-service contract, the provider must explain the expected product data and related-service data, collection frequency, access or retrieval arrangements, storage and retention, intended use of readily available data, third-party sharing routes, complaint rights, relevant trade-secret holder information, and contract termination arrangements. These pre-contract disclosures should match the actual product interface and API behavior.

Security controls can verify that the requester is a user and protect the data infrastructure, but they should not make access unduly difficult. Article 4 limits verification requests to necessary information, and the Commission FAQ points to simple request mechanisms and automatic execution where possible.

Security also has a substantive limit: users and data holders may restrict access, use, or onward sharing if processing could undermine security requirements of the connected product laid down by EU or national law, with serious adverse effects on people's health, safety, or security. A general preference not to share data does not meet that threshold.

The Data Act preserves trade secrets, but it does not allow a blanket trade-secret label to erase user access. The data holder or trade-secret holder must identify protected data, including in relevant metadata, and agree proportionate technical and organisational measures such as confidentiality terms, strict access protocols, technical standards, and codes of conduct.

Withholding, suspension, or refusal should be exceptional and documented. Article 4 requires written substantiation and competent-authority notification when data sharing is withheld, suspended, or refused on trade-secret grounds. Refusal for serious economic damage must be assessed case by case and supported by objective elements.

The Data Act generally applies from 12 September 2025, but Article 50 states that the obligation resulting from Article 3(1) applies to connected products and related services placed on the market after 12 September 2026. Teams should keep those two dates separate in release plans and customer-facing materials.

For products already in the market, other Data Act duties can still matter, including user access under Article 4, data holder contracts for non-personal readily available data, and third-party sharing under Article 5 where the conditions are met. Do not present the later Article 3 design date as a full exemption from the Data Act.

The evidence file should let a reviewer connect the product architecture to the Data Act duty without reconstructing decisions from tickets. Keep a data inventory, Article 3 design specification, pre-contract disclosure, UX/API evidence, security and identity assessment, trade-secret register, request-path procedure, and release approval.

Evidence should also show that the access path works in practice. Useful records include sample exports, API schemas, metadata dictionaries, user journey screenshots, access logs limited to what is necessary, support scripts, test results for machine readability, and records of any security or trade-secret restriction.

Under the Data Act, assign one accountable owner for the design decision itself and separate owners for the supporting work. The accountable owner should be the team that can approve changes to the product or related service, while legal, security, procurement, support, and engineering can supply review and evidence inputs.

For direct-access by design, the workflow should name the owner who signs off on the Article 3 interpretation, the owner who maintains the data map, and the owner who closes any open review trigger. Consulted teams and evidence dependencies should be recorded, but they should not replace a single accountable owner.

Under the Data Act, Article 3 requires direct access to product and related-service data to be provided to the user easily, securely, and free of charge, in a comprehensive, structured, commonly used, machine-readable format with relevant metadata. A data holder cannot put the statutory user access behind a fee or a premium tier.

Compensation can arise in the separate context of sharing with a third party under Articles 5 and 9, but that is distinct from the user's own free access by design, which the product must support without charge.

The Article 3(1) obligation applies to connected products and related services placed on the market after 12 September 2026. The legal trigger is placement on the market, not the date the product was designed. A unit placed on the market after the trigger date is not outside Article 3(1) merely because its design work began earlier.

Map each product and related service to the relevant placement-on-market facts. For data that cannot be made directly accessible because direct access is not relevant or technically feasible, document the assessment and provide the Article 4 request route for readily available data.