EU Data Act access-by-design: what to ask your engineering partner

Who this page is for

This page is for medtech VP Engineering, product owners, and hospital digital buyers of connected devices, or of a service tied to those devices.

Areusdev is an engineering partner that builds and integrates systems. Not a black-box AI vendor. Not a law firm.

This page is not a legal opinion and not a conformity assessment.

What access-by-design requires

The law is Regulation (EU) 2023/2854, the Data Act. Official Journal: OJ L, 2023/2854, 22 December 2023. ELI: http://data.europa.eu/eli/reg/2023/2854/oj (CELEX 32023R2854).

Article 3(1): connected products shall be designed and manufactured, and related services shall be designed and provided, so that product data and related service data, including the relevant metadata necessary to interpret and use those data, are, by default, easily, securely, free of charge, in a comprehensive, structured, commonly used and machine-readable format, and, where relevant and technically feasible, directly accessible to the user.

Free of charge is the user’s access to that data. It is not a statement about the engineering contract.

Direct access is qualified. Commission FAQ version 1.4 (22 January 2026) says Article 3(1) does not oblige manufacturers to design or redesign so users can access data directly in all situations and for all connected products. Direct means the user can access, stream, or download without asking the data holder. Where data cannot be directly accessed, Article 4(1) requires the data holder to make readily available data, and the metadata needed to interpret and use it, accessible to the user without undue delay, on a simple electronic request where technically feasible. Article 4 is not Article 3(1).

Commission FAQ: https://digital-strategy.ec.europa.eu/en/library/commission-publishes-frequently-asked-questions-about-data-act

These are plain-language definitions, not a classification of the buyer’s product.

Article 2(5): a connected product obtains, generates, or collects data concerning its use or environment, can communicate product data via an electronic communications service, a physical connection, or on-device access, and its primary function is not storing, processing, or transmitting data on behalf of anyone other than the user.

Article 2(6): a related service is a digital service, other than an electronic communications service, including software, connected so that its absence would stop the product performing one or more functions, or later connected by the manufacturer or a third party to add to, update, or adapt functions.

Article 2(15): product data is data generated by use that the manufacturer designed to be retrievable. Article 2(16): related service data is the digitisation of user actions or events recorded intentionally or generated as a by-product during the related service. Article 2(12): the user owns the product, or has temporary contractual rights to use it, or receives the related service.

Recital 14: connected products are found across the economy, and the examples include medical and health devices. Prototypes are excepted. The manufacturer’s design choices and, where relevant, Union or national law or a competent authority, determine which data a connected product is capable of making available. That is not a finding that every medical device, or every health software product, is in scope.

Recital 17: a service with no impact on how the connected product operates, and which does not transmit data or commands to it, is not a related service. Examples named there include auxiliary consulting, analytics or financial services, and regular repair and maintenance. Power supply and connectivity supply are not related services. Those examples are not a list of hospital systems that are always out.

Recital 15: information inferred or derived from product or related service data, where that information is the outcome of additional investment in assigning values or insights, in particular by proprietary complex algorithms, should not be treated as within the obligation to make data available to a user or a data recipient, unless the user and the data holder agree otherwise. Content is outside Chapter II (Article 1(2)(a)). This page does not say which of the buyer’s fields are inferred. The partner can show what the device was designed to retrieve. Counsel decides the legal boundary, including trade secrets.

Article 1(5): the Data Act is without prejudice to personal-data and privacy law, in particular the GDPR. Where they conflict, data-protection and privacy law prevails.

The Data Act text does not mention the MDR, the EHDS, the CRA, or the Product Liability Directive. Commission FAQ question 12 says the Data Act applies to connected products that also sit under type approval or conformity assessment, and it names medical devices as an example. It also says the Data Act has no specific conformity-assessment mechanism of its own. Whether a conformity assessment is required is set by other legislation. This page does not treat an MDR assessment as a Data Act assessment.

What changed on 12 September 2026, and what did not

Article 50: the Regulation enters into force on the twentieth day after publication in the Official Journal. It applies from 12 September 2025. The obligation resulting from Article 3(1) applies to connected products and the services related to them placed on the market after 12 September 2026. The Official Journal publication date is 22 December 2023. Entry into force on 11 January 2024 follows that twentieth-day rule. The Commission Data Act explained page states that the Act was published on 22 December 2023 and applies since 12 September 2025: https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained

That Article 3(1) date has passed. For connected products and related services placed on the market after 12 September 2026, the Article 3(1) obligation applies now.

Article 2(22): placing on the market means the first making available of a connected product on the Union market. Article 2(21): making available on the market means any supply for distribution, consumption, or use on the Union market in the course of a commercial activity, whether paid or free. Article 1(3)(a) covers manufacturers of connected products placed on the market in the Union and providers of related services, irrespective of where they are established.

Article 50 uses the word after. This page does not state that a product placed on the market on 12 September 2026 itself is inside Article 3(1). This page does not state a redesign duty for products placed on the market before that date.

Whether a related service first offered after 12 September 2026, for a device placed on the market on or before that date, is inside Article 3(1) stays with counsel. This page does not decide it.

Article 3(2) and Article 3(3) are pre-contract information duties of the seller, rentor, lessor, or related-service provider. They are not delayed by the Article 50 sentence that names only Article 3(1). The partner may have to supply facts: what data the design retrieves, where it is stored, and how the user reaches it. Areusdev does not issue the pre-contract notice and does not decide who the data holder is.

What to ask an engineering partner

Ask for engineering evidence, not a compliance certificate. Four asks:

1. Scope assumption: which items in this engagement the buyer believes are connected products, which are related services, and which are neither (for example a system whose primary function is storing or processing data for someone other than the user, or an analytics service that does not operate the device). The partner documents the assumption. The manufacturer and counsel own the decision. Areusdev does not classify the product.
2. Access design: how product data and related service data, and the metadata needed to interpret them, are available by default in a structured, commonly used, machine-readable form; whether the design gives the user direct access or a request path; and what “where relevant and technically feasible” meant in this design. The partner records the choice. It does not promise direct access in every case.
3. Data boundary in the design: what the manufacturer designed to be retrievable, as against content and as against inferred or derived outputs. The partner shows the data the build actually exposes. Counsel draws the legal line, including trade secrets.
4. Evidence the buyer can review: format, access path (on-device, app, or a request interface), who can retrieve the data, and how that path was tested. That is delivery evidence. It is not a statement that the partner has made the buyer Data Act compliant.

Wider diligence, not the home for this topic: /resources/ai-software-partner-due-diligence/

Sector context only, not Data Act proof: /services/healthcare-technology/

Security of the access path only: /services/cybersecurity-solutions/

How Areusdev fits

Areusdev builds and integrates the software and can work with the buyer’s regulatory and security reviewers on the access path, the data the design retrieves, and the records of that design.

The manufacturer decides the legal role. Areusdev supplies engineering evidence.

That is not a promise of Data Act conformity, MDR conformity, or a company certification.

Frequently asked questions

Talk to an architect

Talk to an architect