Expert article in mt|medizintechnik 4.2026: why maintaining connected medical devices includes cybersecurity
October 19, 2026
Published in mt|medizintechnik, Issue 4.2026
Published in mt|medizintechnik, issue 4.2026
In the trade journal mt|medizintechnik, Valeri Milke explains why maintaining connected medical devices today has to include cybersecurity. His German-language article “Instandhaltung vernetzter Medizinprodukte” (maintenance of connected medical devices), with the strapline “Schwachstellen- und Patchmanagement sind Safety-relevant” (vulnerability and patch management are safety-relevant), appears in issue 4.2026, published in August 2026 with a focus on maintenance. The journal is published by TÜV Media GmbH in Cologne. Author: Valeri Milke, CEO of VamiSec GmbH, Lead Auditor for ISO/IEC 27001 and ISO/IEC 42001. Across five figures and one table, he outlines how manufacturers and operators can run connected devices as one continuous process — from taking stock of software components and assessing and fixing vulnerabilities through to the reporting obligations that follow a security incident. This news item restates the key points in our own words and places them in the regulatory context as of October 2026.
The core argument: working does not mean secure
Traditional maintenance follows service intervals and checks whether a device still performs its function. For connected medical devices, that view is no longer enough: an infusion pump or an imaging system can pass every functional test and still carry an unacceptable risk — for example because a vulnerability disclosed long ago was never assessed, or because an intruder is moving through the network unnoticed. The article builds on a principle of the European guidance MDCG 2019-16 (Revision 1, July 2020): in a clinical environment, information security risks can turn directly into patient safety risks. Typical examples include altered therapy parameters, suppressed alarms or falsified diagnostic results. Vulnerability and patch management, attack detection during operation, post-market surveillance (PMS) and vigilance therefore belong in one joint governance process — with clearly assigned roles for manufacturers, integrators and hospitals.
Transparency first: know your components, assess the situation
If you do not know which libraries, operating systems and firmware a device contains, you cannot tell whether a new vulnerability affects it. The starting point is therefore a machine-readable Software Bill of Materials (SBOM) in SPDX (ISO/IEC 5962) or CycloneDX (ECMA-424) format, updated with every release. Manufacturer statements on exploitability (Vulnerability Exploitability eXchange, VEX) and security advisories in the Common Security Advisory Framework (CSAF) turn it into a usable picture of the current situation. Prioritisation draws on several perspectives: technical severity according to the Common Vulnerability Scoring System (CVSS), the 30-day exploitation forecast of the Exploit Prediction Scoring System (EPSS), confirmed exploitation according to the Known Exploited Vulnerabilities (KEV) catalogue of the US agency CISA — and the clinical context. A medium-severity vulnerability on a therapy platform can be more urgent than a critical one on an isolated device. Log4Shell and XZ Utils show how quickly supply chain risks find their way into a product.
Patching as a controlled change — and what applies while no patch exists
A security update reduces risk, but it can also alter validated states and interfaces. The article therefore treats patch management as a regulated change process: identify affected components via the inventory and SBOM, assess the security and safety consequences in risk management according to ISO 14971, test in a realistic environment, approve, roll out, verify effectiveness and document. Operators should only install updates when the manufacturer has explicitly instructed them to, as MDCG 2019-16 also envisages. If no patch is available — for instance for a zero-day vulnerability that has not yet been fixed — prepared workarounds help: network segmentation, disabling vulnerable services, close monitoring and clinically agreed emergency operating modes. These, too, must be justified and documented. Remote updates (over-the-air, OTA) additionally call for signed packages, a protected boot process (secure boot), a fallback image, protection against rollback to outdated versions and a staged rollout.
Accepting vulnerability reports from outside: CVD and PSIRT
Many vulnerabilities are found not by manufacturers themselves but by security researchers, penetration testers, integrators or users. To ensure such reports neither get lost nor become public in an uncontrolled way, the article argues for a structured coordinated vulnerability disclosure (CVD) process. ISO/IEC 29147 provides guidance on receiving reports and publishing advisories, and ISO/IEC 30111 on internal handling. In practice, this includes a security.txt file according to RFC 9116, a reporting mailbox that can be reached via encrypted channels, committed response times, the manufacturer’s own CVE Numbering Authority (CNA) or cooperation with an existing one, and machine-readable advisories in CSAF format. The process is run by a Product Security Incident Response Team (PSIRT). For hospitals, the maturity of this process is a tangible selection criterion in procurement: without a traceable advisory history, it remains unclear how quickly critical information will reach the operator.
One incident, three reporting channels: MDR, BSI Act and GDPR
When does a cyber event become reportable? Manufacturers are subject to the vigilance obligations of the Medical Device Regulation (MDR): serious incidents must be reported without delay, and at the latest within 2 days of becoming aware of them in the case of a serious public health threat, 10 days in the case of death or an unanticipated serious deterioration in health, and 15 days otherwise. Hospitals that qualify as essential or important entities under the new BSI Act — Germany’s implementation of the NIS2 Directive, in force since 6 December 2025 — must report significant security incidents with an early warning within 24 hours, an incident notification with an initial assessment within 72 hours and a final report no later than one month after that notification. Where personal data are affected, the GDPR generally requires notifying the data protection supervisory authority within 72 hours where feasible. A single attack can trigger all three channels at once — at both the manufacturer and the hospital. The article therefore recommends documented deadlines, clear responsibilities and prepared reporting templates.
Why the topic is pressing now — and what you can do
In December 2025, the European Commission proposed adding to the MDR and IVDR a dedicated obligation to report actively exploited vulnerabilities and severe security incidents — via EUDAMED to CSIRTs and ENISA, no later than 30 days after becoming aware. At the same time, the deadline for other serious incidents would be extended from 15 to 30 days; neither change has been adopted yet. The reporting obligations of the Cyber Resilience Act (CRA) have also applied since 11 September 2026. The CRA excludes medical devices, but supplier components placed on the market in their own right as products with digital elements can fall directly within its scope. Five steps are worth taking: build a device inventory with software versions and SBOMs; require SBOMs, VEX and CSAF advisories from suppliers by contract; introduce a triage that explicitly assesses clinical consequences; rehearse zero-day procedures jointly with hospital IT, clinical engineering and regulatory affairs; and finally merge the reporting channels under the MDR, the BSI Act and the GDPR into one coordinated workflow.
New on vamisec.com: the knowledge page on this topic
New on vamisec.com: the knowledge page “Maintenance of connected medical devices”. It takes up the arguments of the journal article, updates them to reflect the situation as of October 2026 and explores them in depth along the entire maintenance process in the field — from inventory and SBOM through situational awareness, triage, patch and OTA processes, zero-day preparedness and CVD to monitoring, parallel reporting channels and an operational target state, complemented by frequently asked questions and verified sources. You can find the page at https://vamisec.com/en/wissen/secure-software-development/instandhaltung-vernetzter-medizinprodukte. Our consulting services for MDR projects and medical device cybersecurity are described at https://vamisec.com/en/mdr and https://vamisec.com/en/medical-device-cybersecurity — the overarching MDR requirements are summarised at https://vamisec.com/en/wissen/grc/mdr-cybersecurity.
All links
Issue 4.2026 at mt|medizintechnik: https://mt-medizintechnik.de/fokus-auf-instandhaltung/ · Knowledge page Maintenance of connected medical devices: https://vamisec.com/en/wissen/secure-software-development/instandhaltung-vernetzter-medizinprodukte · Category Secure Software & Product Development, medical devices section: https://vamisec.com/en/wissen/secure-software-development#medizinprodukte · MDR cybersecurity at a glance: https://vamisec.com/en/wissen/grc/mdr-cybersecurity · SBOM management: https://vamisec.com/en/wissen/secure-software-development/sbom-management · Vulnerability management: https://vamisec.com/en/wissen/it-security/schwachstellenmanagement · MDR consulting: https://vamisec.com/en/mdr · Medical device cybersecurity: https://vamisec.com/en/medical-device-cybersecurity
Do you have questions about your organization's IT security?
Free Initial Consultation →