Data Act for connected medical devices

The EU Data Act has been in force since 11 January 2024 and has applied since 12 September 2025. Since then, users of connected products have been able to require the data holder to make the data generated by their use available to them or to pass it on to a third party they name – including for devices that were already in the field. In addition, it must be clear before a contract is concluded which data a product generates and how they can be accessed.

The second stage follows on 12 September 2026: connected products and related services placed on the market for the first time after that date must enable access through their design (access by design). Data and metadata are to be available by default, easily, securely, free of charge and in a structured, commonly used, machine-readable format – and, where relevant and technically feasible, directly to the user. In the Commission’s reading, what counts is each individual device, not the device type: even a model that has carried the CE marking for years is affected as soon as a unit is placed on the market for the first time after the cut-off date.

Medical devices are explicitly covered

The regulation’s preamble explicitly mentions medical devices, and according to the Commission’s FAQ the Data Act also applies to products that undergo their own conformity assessment. Before it is placed on the market, a medical device must therefore comply with the Data Act as well as the MDR.

Who is exempt

Micro and small enterprises are exempt from the access obligations, provided they are not linked to a larger company or involved as its partner and do not manufacture or develop on behalf of another company. Medium-sized enterprises only get a one-year grace period: in the first year after reaching that size, and for each product in the first year after it is placed on the market. Irrespective of this, the hospital’s access rights cannot be waived by contract to its detriment; such clauses are not binding on it.

Why this is a security issue

Every additional interface enlarges the attack surface. In the ManiMed study published in 2020 by Germany’s Federal Office for Information Security (BSI), more than 150 vulnerabilities were reported for ten connected medical devices from five categories – often in the supporting infrastructure, rarely in the medical device itself. That is precisely where portals, application programming interfaces and cloud storage for data access are now being built. In Germany, breaches of the design or provision obligation can result in fines of up to €500,000; since 30 May 2026, the competent authority has been the Federal Network Agency.

Two subtleties matter. Processors within the meaning of the GDPR are not data holders – this applies to cloud providers as well as to the manufacturer, insofar as it processes patient data solely on the hospital’s instructions. And the manufacturer may use non-personal device data for its own purposes, such as product improvement, only on the basis of a contract with the hospital; how far this affects the post-market surveillance analyses required by law needs to be clarified case by case.

Which data are covered

Covered are raw and pre-processed data that are available without disproportionate effort, together with metadata as well as status and error messages. Anything that only arises through additional investment, such as complex proprietary algorithms, is generally excluded unless otherwise agreed – an exemption that follows only from the regulation’s preamble and leaves grey areas. Pseudonymisation or encryption does not turn data into derived data. Exploiting gaps in the device’s protection is not a permissible way to obtain the data.

The reference model consists of four building blocks. An imaging diagnostic device supplies images and measurements. Planning software derives therapy parameters from them, which medical staff review and approve. A therapy device executes the approved plan and records the procedure. Added to this is a manufacturer cloud with separate tenants for each hospital, user management, update delivery and a web portal with an application programming interface (API).

Two design principles are common in such systems: the connection to the cloud is established from inside the hospital, so no inbound access from the internet is needed, and the cloud is decoupled so that it cannot interfere with a therapy in progress. In this model, the data door within the meaning of the Data Act comprises:

• the web portal for viewing and downloading
• the API for automated retrieval by the hospital’s systems
• export paths for large data packages
• a delegation function through which the hospital names third parties as recipients
• where applicable, local access on the device or on a gateway

Direct access, where the hospital retrieves data itself, or indirect access, where the manufacturer provides data on request – this design decision has security consequences. Direct access requires a permanently reachable, robustly secured interface, while indirect access shifts risks into manual processes.

Is the cloud service itself a medical device?

That depends on the intended purpose. A service that only stores and forwards data is usually not medical device software; one that performs medical analysis or returns results to the planning stage often is. Companion software without medical device status, such as an installable service or export application, may in individual cases fall under the Cyber Resilience Act; purely web-based services without an associated product, by contrast, are not covered by it.

The safety and security handbrake

The hospital and the manufacturer can restrict or exclude access to, use or further sharing of data by contract if processing them could undermine security requirements for the connected product laid down by law and thereby have serious adverse effects on the health, safety or security of people. For medical devices, the MDR’s cybersecurity requirements are the obvious candidates – a plausible reading, but not one that is explicitly regulated. The Commission’s draft of non-binding model contractual terms, so far published only in English, includes an option to name the specific security requirement in the contract.

If the manufacturer refuses to share data, it must inform the competent authority – in Germany, the Federal Network Agency, using its forms. The hospital can lodge a complaint there or turn to a dispute settlement body. In the reference model, there would be good grounds for the therapy device not to answer live queries during an ongoing treatment and for safety-critical configurations not to leave the system. By contrast, it would be hard to justify withholding read access to error and event logs from the hospital. In any case, the Data Act does not require write access to planning or control.

Trade secrets in three stages

• Label and agree: the manufacturer marks trade secrets, including in the metadata, and agrees safeguards with the recipient – such as confidentiality agreements, strict access protocols, standards or codes of conduct.
• Withhold or suspend: if no agreement is reached, agreed measures are not implemented or confidentiality is breached, the manufacturer may withhold or suspend the sharing of data.
• Refuse: only in exceptional circumstances and on a case-by-case basis, if the manufacturer demonstrates on the basis of objective criteria that, despite safeguards, it is highly likely to suffer serious economic damage.

In the second and third stages, the decision must be justified in writing and notified to the authority. If secrets are disclosed without protection, their status under the German Trade Secrets Act may also suffer. The threat model and the risk management file provide robust justifications for both handbrakes.

What the Digital Omnibus would change

The Commission’s “Digital Omnibus” amending proposal of November 2025 would add a further ground for refusal under trade secret protection where there is a high risk of secrets leaking to third countries with weaker protection; it leaves the safety and security handbrake unchanged. It has not been adopted: Parliament has not voted, and by mid-October 2026 the Council had not agreed a negotiating mandate – trade secret protection is one of the contested points.

GDPR and medical confidentiality

Where personal data are involved, data protection law takes precedence; the Data Act does not create a legal basis of its own. If the hospital is the user and the patient the data subject, making data available requires a legal basis under the GDPR and, for health data, one of the exceptions for special categories as well. The hospital usually remains the controller, is responsible for data protection by design and will generally need a data protection impact assessment for connected therapy systems.

On top of this comes the medical duty of confidentiality, backed by criminal law, which the Data Act does not lift. Unless the patient has released the duty or a statutory permission applies, patient data may only flow to service providers to the extent necessary, and only to those who work on the hospital’s behalf and have committed to confidentiality. In our assessment, this does not cover analyses for the manufacturer’s own purposes.

IEC 81001-5-1 requires a product-specific threat model for health software but does not prescribe a method. The starting point is a data flow diagram of the overall system with its trust boundaries. The Data Act adds a boundary to external recipients selected by the hospital. The boundary around the therapy device remains the one most in need of protection. The MDCG 2019-16 guidance already expects a complete overview of network data flows for connected devices.

The STRIDE method examines every data flow for six threat categories: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. An attack tree additionally breaks an attacker’s goal – such as “manipulated planning data reach the therapy device” – down into individual steps.

Assess and transfer to the risk management file

For systems whose cloud connects many hospitals, the cybersecurity guidance issued by the US Food and Drug Administration (FDA) in February 2026 recommends a dedicated architecture view of harm to many patients at once; it rates security risks by exploitability rather than by a probability that can hardly be estimated. Threats with possible hazardous consequences are recorded as causes in the risk management file under ISO 14971. Whenever interfaces or new types of recipients are added, the model must be updated.

The MDR does not use the term penetration test. The MDCG 2019-16 guidance, however, describes testing as the most important means of security verification and explicitly mentions testing of security functions, fuzzing with malformed inputs, vulnerability scans and penetration tests. IEC 81001-5-1 requires testers to be sufficiently independent. The test scope is derived from attack surfaces, system boundaries and the scenarios of the threat model.

Test priorities at the data door

• Tenant isolation: using test accounts for two hospitals, the team checks whether other tenants’ records can be retrieved by altering identifiers – the 2023 OWASP API Security Top 10 ranks missing object-level authorisation first.
• Login and sessions in the portal and API, including the lifetime, binding and reusability of access tokens.
• Function permissions: can read access be escalated to write or control functions?
• Delegation to third parties: can an attacker register as a recipient or enlarge the approved data scope?
• Export paths: are data packages complete and correctly pseudonymised, and are trade secrets labelled?
• Input handling: how do the API and import functions respond to malformed or maliciously crafted formats (fuzzing)?
• Logging: are approvals and retrievals recorded completely and in a tamper-proof way?
• Load limits and decoupling: do planning and device operation remain available during mass retrievals?

Test conditions and report

Testing is carried out as a grey-box test with partial knowledge of the system, using synthetic data sets and in a production-equivalent environment – never on a device in patient use. As the FDA expects, the report states independence, scope, period, methodology and results and justifies any vulnerabilities left open. Findings are rated by exploitability and possible impact on patients; remediation runs as a corrective and preventive action (CAPA) with a retest and is filed in the technical documentation and post-market surveillance. Repeated regularly, the test also demonstrates the effectiveness of the safeguards required by the GDPR and the BSI Act.

At the data door, the Data Act, the MDR, the GDPR, the BSI Act and the German Trade Secrets Act all meet. If regulatory affairs, information security, data protection and legal maintain separate catalogues and risk scales, contradictions surface in the audit or during an incident at the latest. A natural anchor is the quality management system under ISO 13485, which already governs suppliers, risks, vigilance and changes. Because ISO 13485 does not follow the common harmonised structure of the other ISO management system standards, ISO/IEC 27001, ISO/IEC 27701 and, where applicable, ISO/IEC 42001 are connected via a mapping table.

Coordinating parallel reporting channels

An incident at the data door can trigger several reporting obligations at once, coordinated by a Product Security Incident Response Team (PSIRT): under the BSI Act, 24 hours, 72 hours and one month to the joint reporting office of the BSI and the Federal Office of Civil Protection and Disaster Assistance (BBK); under the GDPR, 72 hours to the supervisory authority and, as a processor, without undue delay to the hospital; under the MDR, 2, 10 or 15 days if a serious incident has occurred. If the manufacturer then suspends data sharing, this must be notified to the Federal Network Agency; for companion software, reports under the Cyber Resilience Act may be added.

Under the BSI Act, senior management is responsible for implementing and monitoring the security measures. The person responsible for regulatory compliance (PRRC) required by the MDR does not take on the role of the information security officer or the data protection officer; a product security function has proven effective as the link between them. If a hospital names an AI service as a recipient, for example, this makes it possible to clarify in a single pass which data are shared, on what legal and contractual basis, with what residual risk and with what evidence.

1. 1
   Determine applicability

   Record connected products and services, check the SME exemptions and identify the devices placed on the market for the first time after 12 September 2026.

2. 2
   Create a data catalogue

   Record all available product and service data and classify them as data to be made available, derived data, personal data or data requiring confidentiality.

3. 3
   Fulfil information obligations

   Supplement offers, contracts and instructions for use so that the type, scope, format and access route of the data are clear before the contract is concluded.

4. 4
   Prepare contracts

   Draft data-use agreements for the manufacturer’s own analyses as well as clauses on the security handbrake and trade secret protection; the draft model contractual terms serve as guidance.

5. 5
   Design the data door

   Define the access route, separate the data and control planes, and specify tenant isolation, delegation and logging as security requirements.

6. 6
   Update the threat model

   Analyse new trust boundaries and data flows with STRIDE, transfer safety-relevant causes to the risk management file and document the justification for the handbrakes.

7. 7
   Test and demonstrate

   Carry out a penetration test focusing on authorisation, delegation and export paths; close and document findings via CAPA.

8. 8
   Align change and reporting channels

   Discuss the interface with the notified body at an early stage and rehearse the reporting channels to the Federal Network Agency, the BSI, the data protection authority and the vigilance authority in a tabletop exercise.

This page reflects the situation as of October 2026. It does not replace legal advice; questions of interpretation, in particular on where derived data begin and how to handle legacy devices, must be clarified case by case.