Maintaining connected medical devices

Clinical engineering departments have traditionally planned maintenance around inspection deadlines, manufacturer instructions and downtime costs. For connected devices, that is no longer enough: an ultrasound system, a patient monitor or an infusion pump with a network connection contains an operating system, libraries and interfaces whose security posture changes every day – even when nothing happens to the device itself. A device that passes every electrical safety test can therefore still be an open door for attackers.

The BSI’s ManiMed study showed how real the problem is: Germany’s Federal Office for Information Security examined ten network-capable medical devices from five product categories and reported more than 150 vulnerabilities to the manufacturers over the course of the project. The final report was published in December 2020.

What cyber resilience means in operation

Cyber resilience is the ability to keep operating a device safely despite new vulnerabilities and attacks – or to restrict its use on justified grounds. This adds tasks alongside the service schedule:

• an up-to-date inventory of all devices, software versions and third-party components,
• ongoing situational awareness of new vulnerabilities and active attacks,
• an assessment that links technical severity with clinical consequences,
• updates and compensating controls handled as documented, approved changes,
• a channel for vulnerability reports from outside the organisation,
• monitoring, incident response and reporting within the deadlines.

This page summarises the German-language expert article “Instandhaltung vernetzter Medizinprodukte” (maintenance of connected medical devices) from mt|medizintechnik, issue 4.2026, reorganises it and adds developments up to October 2026.

Beyond confidentiality, integrity and availability, medical devices raise a fourth question: could an attack impair the intended performance or harm people? The MDCG 2019-16 guidance stresses that the security risks of medical devices must not be considered in isolation from their safety risks.

How an IT vulnerability becomes a clinical risk

• Integrity: tampered readings, images or findings lead to wrong diagnoses.
• Availability: an encrypted or crashed system delays examinations or procedures.
• Control: anyone able to change therapy or alarm parameters intervenes directly in treatment.
• Confidentiality: leaked health data affect data protection and the trust of patients.

This leads to a central rule for assessment in the field: technical severity alone does not determine urgency – what matters is what an attacker could achieve on the specific device and in the specific care process.

Two risk files, one result

Manufacturers carry out risk management according to ISO 14971, which is harmonised under the MDR as EN ISO 14971. Security risks are often assessed in a separate analysis. What counts is the link between the two: every security scenario with a possible impact on patients or users must appear in the safety risk management file, and every safety measure that relies on software needs a security review. In the field, this check is repeated with every new vulnerability and every incident – including the question of whether the benefit-risk ratio needs to be reassessed.

MDR: the manufacturer’s obligations

The MDR has applied since 26 May 2021. It requires software developed according to the state of the art with risk management that includes information security, protection against unauthorised access, and minimum requirements for IT networks in the instructions for use. Once a device is on the market, the manufacturer operates a post-market surveillance (PMS) system. From class IIa upwards, this includes a periodic safety update report (PSUR) – at least annually for classes IIb and III and at least every two years for class IIa.

MDCG 2019-16: joint responsibility

The MDCG 2019-16 guidance, in its July 2020 revision, carries these requirements across the entire life cycle. It makes clear that cybersecurity is part of the PMS system and also covers third-party components. At the same time, it describes a joint responsibility: legally, the manufacturer is bound; in practice, suppliers, integrators, healthcare providers and authorities share responsibility as well. Changes to the device, including patches and third-party software, are only intended on the basis of explicit, published manufacturer instructions.

Standards as the state of the art

Medical Devices Operator Ordinance: updates are maintenance

For operators in Germany, the Medical Devices Operator Ordinance (MPBetreibV), in force in its revised version since 20 February 2025, specifies what maintenance includes: alongside servicing, inspection and repair, it explicitly covers the installation of security-relevant software updates – in line with the manufacturer’s instructions. If an update significantly changes how a device is operated, staff must be instructed again. For software classified as a class IIb or III medical device, the ordinance has also required healthcare facilities since 1 August 2025 to carry out IT security reviews in line with recognised technical rules, at least every two years and with a written record.

BSI Act: the hospital’s obligations

Since 6 December 2025, the new BSI Act has transposed the NIS2 Directive into German law. Hospitals belong to the health sector. As a rule, entities with 50 or more employees or with more than EUR 10 million in both turnover and balance sheet total are covered. Those with 250 or more employees or more than EUR 50 million in turnover and EUR 43 million in balance sheet total count as particularly important entities, as do hospitals operating critical facilities – so far defined as 30,000 or more inpatient cases per year – regardless of their size. The obligations explicitly include security in the acquisition, development and maintenance of systems, including vulnerability handling and disclosure, as well as supply chain security.

Cyber Resilience Act and FDA in the wider context

The Cyber Resilience Act does not apply to products covered by the MDR or IVDR. It nonetheless reaches into medical technology: suppliers that sell components with digital elements in their own right have been subject to its reporting obligations since 11 September 2026 and will be subject to its main obligations from 11 December 2027. Internationally, the US Food and Drug Administration (FDA) sets benchmarks: since 29 March 2023, it has required premarket submissions for so-called cyber devices to include, among other things, an SBOM, a plan for handling vulnerabilities including coordinated vulnerability disclosure, and updates on a justified schedule.

On the day Log4Shell was disclosed, 10 December 2021, many organisations faced the same question: which of our products contain the affected library? For medical devices, this uncertainty is particularly delicate, because hospitals are generally not allowed to scan or modify devices themselves unless the manufacturer provides for it.

What an SBOM delivers

The Software Bill of Materials (SBOM) lists the software components of a product in machine-readable form – with name, version, supplier, hash and dependencies. Two formats have become established: CycloneDX, standardised as ECMA-424 since June 2024, and SPDX, whose version 2.2.1 has been published as ISO/IEC 5962:2021. In Germany, the BSI’s Technical Guideline TR-03183-2 describes the minimum content an SBOM should have.

Obligation or expectation?

In the US, the SBOM for cyber devices is part of the premarket submission. European medical device law contains no explicit SBOM obligation; MDCG 2019-16 cites the bill of materials as an example of security information for operators. In the EU, the expectation follows from the state of the art as set out in IEC 81001-5-1. For supplier components that fall under the Cyber Resilience Act, an SBOM becomes mandatory as part of the technical documentation from 11 December 2027.

From list to situational picture

An SBOM only becomes effective when the manufacturer regenerates it with every build and continuously matches it against vulnerability data. Because a vulnerable library does not automatically mean a vulnerable device, the manufacturer adds statements on actual exploitability (Vulnerability Exploitability eXchange, VEX). Such information is exchanged in machine-readable form via the Common Security Advisory Framework (CSAF), an OASIS standard in version 2.0 since November 2022.

What hospitals should specify in procurement

• delivery of a machine-readable SBOM with the device and an updated SBOM with every software release,
• security advisories and VEX statements through a fixed channel, ideally in CSAF format,
• information on the support period for security updates and on how they are provided,
• the completed MDS2 form and the minimum requirements for the network environment,
• a named contact for security questions and incidents.

Risks beyond your own code

Supply chain attacks such as the one on SolarWinds Orion at the end of 2020 or the backdoor in XZ Utils in March 2024 show how malicious code can enter through trusted sources. Countermeasures include verifiable builds, signed artefacts, provenance attestations and a deliberately small set of dependencies; Supply-chain Levels for Software Artifacts (SLSA), currently in version 1.2, provides a tiered framework.

Sources for situational awareness

• security advisories from device manufacturers and component suppliers, ideally machine-readable in CSAF format,
• the warning and information service of CERT-Bund at the BSI,
• the Known Exploited Vulnerabilities (KEV) catalogue of the US agency CISA,
• information sharing within Health-ISAC, the international information sharing community of the health sector,
• in-house findings from network monitoring, logs and incidents.

Three technical signals

The technical classification relies on three signals: CVSS, in version 4.0 since November 2023, for severity; EPSS for a daily updated forecast of exploitation within the next 30 days; and the KEV catalogue, maintained since November 2021, for confirmed attacks.

The clinical questions

• Reachability: can the device be accessed from the hospital network, through remote maintenance access or even from the internet?
• Clinical role: does it control or monitor a therapy, does it deliver findings, is it used directly on the patient?
• Consequences of tampering: what impact would a loss of integrity or availability have on diagnosis and treatment?
• Protective measures: are segmentation, access restrictions or monitoring already demonstrably effective?
• Manufacturer statement: does a VEX statement confirm that the device is affected, or is the component not reachable?

Priority classes as a common language

Manufacturers and hospitals benefit from a small number of clearly described priority classes. The following classification is a proposal; each organisation sets specific response times per product.

Two extremes are risky: reflexively installing every available update, or refusing on principle to change anything on medical technology. MDCG 2019-16 expects operators to have patch processes that roll out security-relevant updates promptly, and an operating environment that allows updates without loss of compatibility. The guidance explicitly provides for updates to be made available outside a field safety corrective action as well.

From advisory to documented update

1. 1
   Establish impact

   Match the advisory against the SBOM, device inventory and VEX statements: which devices, software versions and sites are actually affected?

2. 2
   Assess and classify

   Bring together technical signals, clinical role and existing protective measures, set the priority class and document the safety relevance.

3. 3
   Choose the measure

   Update, configuration change or compensating control such as segmentation, hardening, enhanced monitoring or usage restrictions – aligned with the manufacturer’s instructions.

4. 4
   Test and approve

   The manufacturer verifies and validates the update; the hospital tests it in a realistic environment with its own interfaces and approves it against defined criteria.

5. 5
   Roll out in stages

   Pilot devices first, then the fleet, in agreed maintenance windows and with a prepared way back in case of disruption.

6. 6
   Verify and document

   Check the installation status, confirm functionality, record the residual risk and update the inventory, SBOM and risk management file.

Compensating controls are assessed, approved, time-limited and reviewed in the same way as a patch. From the MDR’s perspective, what counts is evidence that a decision was justified, tested and documented together with its residual risk – not the installation alone.

Updates over the network (OTA)

Over-the-air updates bring fixes to many devices faster, but they create a concentration risk: in the worst case, a faulty or manipulated package reaches the entire fleet. The IETF firmware update architecture, described in RFC 9019 of April 2021, sets out the key principles:

• a signed manifest describing the origin, compatibility and checksums of the package,
• verification of authenticity and integrity before installation and again at start-up by a bootloader with a root of trust (secure boot),
• a fallback image in a separate memory area (A/B scheme), so that a failed update does not disable the device,
• downgrade protection using sequence numbers, so that attackers cannot install an older, vulnerable but validly signed version,
• robustness against power failure or loss of connection.

Fallback image and downgrade protection solve different problems: one safeguards availability, the other prevents an attack. On top of this come encrypted transmission, staged rollout waves and telemetry on success rates – and in clinical operation, agreed maintenance windows and clear information for users. If an update significantly changes safety or performance characteristics, a new assessment involving the notified body may be required, depending on the classification.

Prepared for the zero-day

A zero-day is a vulnerability for which no patch is available at the time it becomes known. For medical devices, this is particularly difficult: the device has to keep supporting patient care, an approved update is missing, and unilateral interventions by the hospital are ruled out. Four precautions have proven effective:

• a documented escalation path that defines who decides in the first hours – product ownership, security, hospital IT, clinical engineering and regulatory affairs,
• immediate measures agreed in advance, such as network isolation, disabling services that are not needed and targeted monitoring for signs of attack,
• prepared and clinically validated fallback configurations for safety-critical device classes,
• templates for safety communications to users (field safety notices) that are technically correct and clinically understandable.

Under the MDR, a field safety corrective action must in principle be reported to the authority before it is carried out; only in urgent cases may the report follow afterwards. If a vulnerability is already being actively exploited, the situation becomes even more serious – technically as well as from a regulatory perspective.

Coordinated vulnerability disclosure

Many vulnerabilities are discovered by researchers, penetration testers, integrators or users. Without a visible reporting channel, such reports are left unanswered or become public in an uncoordinated way. Coordinated vulnerability disclosure (CVD) brings order to the process: the report is received, verified and fixed, and the vulnerability is then disclosed jointly. The framework is set by ISO/IEC 29147:2018 for receiving reports and publishing advisories and by ISO/IEC 30111:2019 for internal handling.

What hospitals should check

Without a working CVD process, a manufacturer’s ability to respond is hard to gauge. Telling indicators are a published policy, a reachable PSIRT and a traceable history of security advisories.

Monitoring beyond availability

Monitoring that only checks whether a device is reachable will not detect attacks. Meaningful indicators include unusual connections, repeated failed logins, unexpected configuration changes and failed integrity checks. Because no additional software may be installed on many medical devices, passive network monitoring in segmented device zones is a suitable approach.

Incident response across organisational boundaries

Anomalies must be turned into an actionable process – with roles, escalation criteria and interfaces to clinical engineering, hospital management, data protection and the manufacturer. MDCG 2019-16 explicitly expects operators to inform the manufacturer without delay of any suspected security incident. At the manufacturer, the PSIRT coordinates analysis, prioritisation and remediation and supports communication with CERTs, information sharing communities and authorities.

Four reporting channels compared

For MDR vigilance, it makes no difference whether an event stems from an attack, a vulnerability or a software bug. What matters is whether the device’s safety or performance was or could have been impaired. MDCG 2019-16 contains examples that distinguish incidents from serious incidents; for coding, the International Medical Device Regulators Forum (IMDRF) provides problem codes such as “Software Security Vulnerability”. If it is unclear whether a report is required, report within the deadline – an initially incomplete report is permitted.

What the revision proposal would change

On 16 December 2025, the Commission proposed revising the MDR and IVDR. Under the proposal, manufacturers would report actively exploited vulnerabilities and severe security incidents within 30 days via the European database EUDAMED to the competent CSIRTs and to ENISA; in addition, the general vigilance deadline for other serious incidents would be extended from 15 to 30 days. The proposal has not yet been adopted. Until then, the current deadlines apply.

Post-market surveillance, vulnerability management and incident response depend on one another: new risks only become visible if security intelligence feeds into post-market surveillance; priorities are only right if the safety assessment is part of the process; deadlines are only met if regulatory affairs is involved early on. The target state links these strands into a cycle with clear ownership.

Starter plan for the first months

• Inventory and owners: record all connected medical devices with software version, network connection, manufacturer contact and end of support.
• Close gaps in manufacturer information: request SBOMs, MDS2 forms, security advisories and patch instructions, and anchor them in contracts.
• Define priority classes and internal response times that combine technical and clinical criteria.
• Set up a change process for updates and compensating controls with testing, approval and documentation steps, and align it with the maintenance and inspection duties under the Operator Ordinance.
• Create and rehearse a reporting matrix for MDR vigilance, user reports, the BSI Act and data protection, with templates, responsibilities and deputies.
• Introduce KPIs, such as the share of devices with an up-to-date SBOM, lead time per priority class and the number of time-limited compensating controls.

Organisations that connect these building blocks early respond faster, can justify their decisions and strengthen trust in digital medical technology. A securely developed device only stays secure if it is maintained just as carefully in the field.

The information on this page does not replace legal advice. Which obligations apply in an individual case depends on the classification, role and size of the organisation.