The guidance documents governing cybersecurity for medical devices have gaps. Some of those gaps correspond directly to the most common real-world vulnerabilities in devices currently on the market.
Published 4/30/2026
That is the uncomfortable finding at the center of a new paper from researchers at TU Dresden's Else Kröner Fresenius Center for Digital Health, published in Computational and Structural Biotechnology Journal. The study, authored by Ostermann, Freyer, Gilbert and colleagues, does something that is rarer in this space than it should be: it systematically compares what the EU and US cybersecurity guidance documents for medical devices actually require against a structured baseline derived from international standards, and then tests whether following that guidance would have prevented the most impactful known vulnerabilities in medical devices.
The two documents under examination are MDCG 2019-16 (revision 1), the EU Medical Device Coordination Group's guidance on cybersecurity, and the FDA's 2023 premarket cybersecurity guidance. Neither is legally binding - both communicate regulatory expectations rather than hard requirements - but both function as the primary reference point for manufacturers building connected medical devices for the EU and US markets respectively.
The methodology is rigorous. The authors first constructed a 73-item checklist from recognised sources - OWASP, IEC, ISO, AAMI, NIST, the German BSI standard, and the recently published IEEE/UL 2933-2024 IoMT interoperability standard - grouping requirements into twelve thematic areas. They then mapped each guidance document against that checklist and against each other, rating coverage on a three-point scale. Finally, they cross-referenced the guidance against real-world CISA medical device advisories, specifically the ten most impactful vulnerability classes identified in published research, to assess whether following the guidance would have prevented those incidents.
The headline finding is that the FDA guidance performs noticeably better than its EU counterpart across most thematic areas, but neither is adequate in important respects. The MDCG guidance has significant gaps in authentication and access control - it does not address multi-factor authentication or root of trust mechanisms - along with gaps in cryptography, source code and software development practices, and network security principles. It also notably fails to address hard-coded credentials beyond the specific sub-case of hard-coded passwords, which is material because the use of hard-coded credentials is among the most common documented weaknesses in medical devices currently in use. The FDA guidance is stronger on several dimensions, including its treatment of third-party software components and Software Bill of Materials requirements, and its framing of cybersecurity as a patient safety issue rather than a compliance exercise. But it too leaves gaps, particularly around network security principles, detection of unusual behavior, third-party auditing, and the foundational security principle of avoiding security through obscurity.
One finding deserves particular attention from a regulatory standpoint: the incident mapping shows that for the most impactful known CVEs - specific exploit instances in medical devices - the existing guidance, if fully followed, would largely have been sufficient to prevent them. The problem is not primarily that the guidance is wrong about what matters. The problem is that many of the vulnerabilities those CVEs exploit involve weaknesses - hard-coded credentials, improper input validation, insufficiently protected credentials - that are well-understood and have been present in approved devices for years. The guidance existed. The vulnerability existed anyway. This gap between what guidance says and what manufacturers actually implement is, the authors argue, at least as important as any gaps in the guidance documents themselves.
The structural problems they identify in both documents are worth dwelling on. Both suffer from inconsistency in level of detail, with highly specific requirements sitting alongside vague principles with no bridging logic, leaving manufacturers uncertain which standard of treatment applies to their device. Both have unclear scope: it is not always apparent whether requirements apply to the device itself, the broader system it operates within, or both. And both embed critical requirements in running prose rather than structured requirement language, which complicates systematic compliance checking and makes machine-readable implementation - which the authors advocate via "SMART" standards principles - essentially impossible in the current format.
The EU's regulatory landscape adds additional complexity. Medical devices in the EU are subject not just to the MDR and MDCG 2019-16 but also to the Cyber Resilience Act, the NIS2 Directive, the AI Act, and GDPR. The MDR has lex specialis status over more general legislation, but the interaction between these frameworks - and the question of which requirements apply when they overlap or conflict - remains incompletely resolved. The upcoming revision of MDCG 2019-16, which is already underway with input from the Horizon Europe CYMEDSEC project (in which the authors are participants), will need to address this layered complexity rather than continuing to treat cybersecurity guidance as a standalone document.
The practical implications for manufacturers and deployers are concrete. The authors suggest a tiered documentation structure: high-level principles in a general guidance, with device-type-specific technical requirements in separate documents covering web-based applications, mobile devices, stationary devices, and IoMT devices separately. They also recommend that the mere existence of guidance be supplemented with meaningful enforcement. The MDR already permits member states to impose fines for non-compliance under Article 113, and the authors suggest that specific financial penalties for cybersecurity misconduct - analogous to GDPR enforcement - would be a more effective tool than guidance revision alone.
The underlying challenge this paper surfaces is one that regulators in both jurisdictions will recognize. Connected medical devices are genuinely safety-critical systems. A compromised insulin pump, a manipulated remote monitoring device, a ransomware-seized hospital system - these are not abstract threat scenarios; they are documented events. The regulatory frameworks that are supposed to ensure these devices are secure before they reach patients are, by this analysis, adequate in principle but incomplete in practice, and poorly structured to drive consistent manufacturer behavior. Revising guidance documents is necessary but not sufficient. The question of how regulators enforce what exists is as important as what gets written into the next version.
Full paper: https://pmc.ncbi.nlm.nih.gov/articles/PMC12301760/