Medical Device Cybersecurity Penetration Testing & Vulnerability Assessment: FDA & EU MDR Requirements for 2026

Why Cybersecurity Testing Is Now a Regulatory Gatekeeper

On February 3, 2026, the FDA reissued its final guidance "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," aligning it with the new Quality Management System Regulation (QMSR). The guidance builds on Section 524B of the FD&C Act (enacted via FDORA in December 2022), which made cybersecurity documentation a legal requirement for "cyber devices" — defined broadly as any device with software that can connect to the internet, including via USB, Bluetooth, serial ports, NFC, or Wi-Fi.

The FDA has identified 479 vulnerabilities and managed 17 safety alerts through its cybersecurity team. In 2026 submissions, the most common reason for cybersecurity-related delays is insufficient penetration testing evidence — not missing documentation, but testing that fails to demonstrate real-world device resilience.

In the EU, cybersecurity is evaluated through MDR general safety and performance requirements (GSPRs), clinical evaluation, and risk management. Notified Bodies increasingly scrutinize cybersecurity testing evidence during conformity assessments, and weak linkage between cybersecurity controls and patient safety is a frequent audit finding.

What the FDA Requires in Premarket Submissions

The Testing Triad

The FDA expects three categories of cybersecurity testing evidence:

Penetration Testing Requirements

Penetration testing must be performed on the final, production-equivalent version of the device. The FDA is explicit about this in recent deficiency trends — testing on prototypes or development builds is insufficient.

A compliant penetration test must:

• Cover all system elements, not just the regulated software component — including mobile apps, cloud backends, hospital network interfaces, and any third-party integrations
• Test all communication channels — Bluetooth/BLE, Wi-Fi, USB, Ethernet, HL7, DICOM, proprietary RF protocols
• Address all five security objectives — authenticity, authorization, availability, confidentiality, and secure updatability
• Be conducted by qualified testers with medical device or embedded systems expertise (general IT pen testing is not sufficient)
• Document findings with risk disposition — every finding must have a documented mitigation, acceptance rationale, or "by-design" justification

Testing Approaches: White-Box, Gray-Box, and Black-Box

The FDA does not prescribe a specific testing methodology, but reviewer experience shows a clear preference hierarchy:

The FDA values white-box and gray-box testing because medical device vulnerabilities often exist in the interaction between software components, communication protocols, and safety-critical functions — areas that black-box testing alone cannot reach. Most successful submissions use a gray-box or combined approach.

UL 2900-2-1 Alignment

Although the FDA does not explicitly mandate UL 2900-2-1 ("Standard for Software Cybersecurity for Network-Connectable Products, Part 2-1: Particular Requirements for Medical Devices"), structuring your testing against this standard pre-empts reviewer follow-up questions. UL 2900-2-1 provides a structured framework for:

• Risk-based vulnerability assessment
• Penetration testing methodology
• Software bill of materials analysis
• Threat mitigation verification

Manufacturers who align their testing methodology with UL 2900-2-1 report smoother FDA reviews, as the standard's output maps directly to the FDA's premarket submission expectations.

CVSS vs. ISO 14971: Don't Mix Your Risk Scoring

A common mistake is using CVSS (Common Vulnerability Scoring System) scores to assess patient safety impact. The FDA expects separate assessments:

• CVSS — Measures technical severity of a vulnerability (exploitability, impact on confidentiality/integrity/availability). Used for cybersecurity risk prioritization.
• ISO 14971 — Assesses clinical patient harm probability and severity. Used for safety risk management.

These are fundamentally different frameworks. A vulnerability with a high CVSS score may have low clinical impact (e.g., an information disclosure bug that does not affect therapy delivery). Conversely, a low-severity technical vulnerability could have high patient safety impact if it affects a safety-critical function.

Every cybersecurity finding should be scored using both frameworks independently. The penetration testing report documents the CVSS score. The security risk management file documents the ISO 14971 patient safety assessment.

Common Vulnerability Patterns in Medical Devices

Based on FDA deficiency data and industry testing experience, these vulnerability categories account for the majority of findings:

Engineering teams should proactively address these patterns during design rather than waiting for testing to find them.

Tester Credentials and Report Timeliness

The FDA expects penetration test reports to document:

• Tester qualifications (certifications, relevant experience with medical devices or embedded systems)
• Testing tools and equipment used
• Testing methodology and scope
• Date of testing — reports older than one year may be questioned during review

Medical device penetration testing requires specialized expertise beyond general IT security. Testers should understand real-time operating systems, safety-critical software constraints, healthcare network protocols (HL7, DICOM), and the unique threat model of connected medical devices. Expect to pay a 20–50% premium over general IT pen testing for this specialization.

What the FDA Is Actually Flagging in 2026

Based on publicly reported deficiency trends from FDA reviewers in 2026:

1. Unresolved penetration test findings — Even "Low" or "Medium" risk findings without documented mitigation or acceptance criteria trigger requests for additional information (RFAI)
2. Missing retest evidence — If a High-risk finding was mitigated, the FDA expects to see retest results confirming the fix
3. Incomplete SBOM disclosure — SBOMs must include software support level, end-of-support dates, and cross-reference against CISA's Known Exploited Vulnerabilities Catalog
4. Missing Appendix 1 controls — The premarket guidance Appendix 1 lists 8 control categories that FDA treats as a de facto checklist: authentication, authorization, cryptography, code/data integrity, confidentiality, event detection/logging, resiliency, and updatability

Required Documentation for FDA Submissions

EU MDR Cybersecurity Testing Expectations

How EU Requirements Differ

The EU MDR does not prescribe specific cybersecurity testing methodologies in the way the FDA does. Instead, cybersecurity is evaluated through:

• GSPR compliance (Annex I) — cybersecurity risks must be managed as part of general safety and performance
• Risk management file (ISO 14971) — cybersecurity risks must be integrated and linked to patient harm scenarios
• Clinical evaluation — cybersecurity must be considered as a factor affecting clinical safety and performance
• Post-market surveillance — ongoing vulnerability monitoring and incident response

What Notified Bodies Expect in Practice

Despite the absence of prescriptive testing rules, Notified Bodies increasingly expect manufacturers to demonstrate:

• Evidence of penetration testing or equivalent security assessment
• Vulnerability scanning results covering all software components
• Integration of cybersecurity findings into the ISO 14971 risk management file
• Clear linkage between cybersecurity controls, patient safety scenarios, and clinical impact
• Documented vulnerability monitoring and patch management processes as part of PMS

Common audit findings in EU conformity assessments include weak linkage between cybersecurity controls and patient safety outcomes, and insufficient evidence that post-market vulnerability monitoring is operational.

IEC 81001-5-1 as the Bridge Standard

IEC 81001-5-1:2021 "Health software and health IT systems — Security activities in the product lifecycle" is emerging as the de facto standard that bridges FDA and EU expectations. It provides a lifecycle framework for security activities that maps to both ISO 13485 quality system requirements and ISO 14971 risk management.

Manufacturers who align their cybersecurity testing with IEC 81001-5-1 are well-positioned for both FDA and EU submissions.

Building a Cybersecurity Testing Program

Scope Definition

Before testing begins, define the scope to cover:

1. Device hardware — physical access risks, debug ports (JTAG, UART), tamper evidence
2. Embedded software and firmware — code vulnerabilities, authentication flaws, privilege escalation
3. Network communication — encryption analysis, protocol vulnerabilities, man-in-the-middle scenarios
4. Mobile and cloud integration — API security, authentication flows, data storage, remote access
5. Hospital network interaction — segmentation bypass, lateral movement testing, integration with HL7/DICOM systems
6. Real-time operating system (RTOS) — low-level firmware interactions, safety-critical operation impacts

Threat Modeling Before Testing

The FDA requires a separate threat model from the ISO 14971 safety risk assessment. Threat modeling should:

• Use exploitability-based methods (not probabilistic) — focus on whether a vulnerability can be exploited, not the likelihood
• Consider multi-patient harm scenarios (e.g., one compromised device affecting multiple patients via network)
• Address all communication interfaces and data flows
• Identify trust boundaries between device components, cloud services, and hospital systems
• Feed directly into the security risk management report

Recommended threat modeling frameworks: STRIDE, Attack Trees, or PASTA.

Testing Methodology

Penetration Testing

Vulnerability Scanning

• Use automated tools (e.g., Nessus, OpenVAS, Qualys) against all software components
• Cross-reference SBOM against NVD, CISA KEV, and vendor security advisories
• Document all findings including CVE IDs, CVSS scores, and device-specific impact assessment
• Include both the device firmware/software and any connected mobile apps or cloud services

Fuzz Testing

• Target all device input channels: network protocols, file parsers, API endpoints, USB/serial interfaces
• Use both protocol-aware and protocol-agnostic fuzzing approaches
• Run for sufficient duration to achieve meaningful code path coverage
• Document all crashes, hangs, or unexpected behaviors with root cause analysis

Managing Test Results

Every finding from penetration testing, vulnerability scanning, or fuzz testing must be dispositioned through the security risk management process:

The FDA expects to see a direct trace from each finding to a risk assessment entry, and from there to either a mitigation action or a documented acceptance with justification.

Security Architecture Documentation

The FDA requires four specific architecture views in premarket submissions:

These views should be generated as part of the design control process (ISO 13485 Subclause 7.3) and maintained in the Design History File.

Common Reasons for FDA Cybersecurity Delays

EU vs. FDA Cybersecurity Testing: Convergence and Differences

Manufacturers targeting both markets should build one unified cybersecurity testing program that satisfies FDA prescriptive requirements (which are the higher bar) while ensuring the documentation structure also supports EU technical file organization.

Cost and Timeline Considerations

Note: Medical device specialization adds a 20–50% premium over general IT penetration testing costs.

These costs are significantly lower than the cost of an FDA Refuse-to-Accept decision or submission delay, which can add 6–12 months and $200,000–$500,000+ to a product launch timeline.

Practical Steps for Manufacturers

If You Are Preparing a Submission Now

1. Audit your penetration test against the criteria above — ensure it covers all system elements, not just the device firmware
2. Disposition every finding through your security risk management process
3. Retest any mitigated High/Critical findings and include retest evidence
4. Verify your SBOM includes support levels, end-of-support dates, and CISA KEV cross-reference
5. Map your documentation to the FDA guidance Appendix 1 checklist

If You Are Starting a New Development Project

1. Integrate cybersecurity into your ISO 13485 design controls from the start
2. Conduct threat modeling during design input phase, not at the end
3. Budget for cybersecurity testing as a line item in your development plan
4. Select testing partners with medical device or embedded systems expertise
5. Build your SBOM as a living document, updated with each software release

If You Have Devices Already on the Market

1. Conduct a gap assessment against current FDA and EU cybersecurity expectations
2. Implement vulnerability monitoring processes as part of your PMS plan
3. Develop a coordinated vulnerability disclosure program
4. Plan for post-market cybersecurity testing as part of device lifecycle management
5. Prepare for FDA inspections that may test cybersecurity processes under the new QMSR inspection manual (CP 7382.850)

Sources and References

• FDA, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions" (Final Guidance, February 2026)
• Section 524B, Federal Food, Drug, and Cosmetic Act (FDORA, December 2022)
• FDA Compliance Program Manual #7382.850 (effective February 2026)
• IEC 81001-5-1:2021 — Health software security activities in the product lifecycle
• ISO 14971:2019 — Medical devices — Application of risk management to medical devices
• EU MDR Regulation (EU) 2017/745, Annex I (GSPRs)
• MITRE, "Cybersecurity Risk Analysis for Medical Devices in the Era of Evolving Technologies" (April 2026)
• MITRE, "Considerations for Managing Challenges in Software Bill of Materials (SBOM) Data Normalization" (April 2026)
• CISA Known Exploited Vulnerabilities Catalog