EU Data Act Direct Access by Design FAQ

The Data Act context is the starting point for this answer. Direct access by design means the connected product and any related service must be built so the user can access product data and related-service data by default. Article 3 requires the access path to include relevant metadata, use a comprehensive, structured, commonly used and machine-readable format, and be easy, secure, and free of charge.

The obligation is not just a helpdesk process. 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. Where direct access is relevant and technically feasible, it should be available without making the user ask support to manually extract the data.

The Data Act context is the starting point for this answer. The design should cover product data and related-service data that are readily available to the data holder. The Commission explains this as raw and pre-processed data generated from use of a connected product or related service that can be accessed without disproportionate effort, including relevant metadata.

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.

The Data Act context is the starting point for this answer. 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.

The Data Act context is the starting point for this answer. 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.

The Data Act context is the starting point for this answer. 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.

The Data Act context is the starting point for this answer. 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. That is narrower than a general preference not to share data.

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 4 and 5, but that is distinct from the user's own free access by design, which the product must support without charge.

Under the Data Act, the Article 3 design obligation applies to connected products and related services placed on the market after 12 September 2026, so products designed before that date are not retrofitted by the rule but may still owe Article 4 access on request. Teams should map each product to the date it was or will be placed on the market.

A product roadmap crossing that date should bake direct access into the design rather than relying on a manual export, so the access path is easy, secure, and free of charge from launch.