Medical Device Penetration Testing: The FDA Premarket Cybersecurity Guide

Medical device cybersecurity stopped being optional in 2023. Section 524B of the Federal Food, Drug, and Cosmetic Act now requires manufacturers of “cyber devices” to demonstrate cybersecurity in their premarket submissions, and the FDA’s premarket cybersecurity guidance names penetration testing as one of the forms of testing it expects to see. Hospitals, for their part, ask for the same evidence during procurement and route it into their own HIPAA programs.

This guide explains what the law and the guidance require, what a medical device penetration test actually covers, how to run one safely, and how to write the results into a submission a reviewer will accept.

Who this applies to

Two audiences need medical device penetration testing for different reasons.

Manufacturers need it for FDA premarket submissions (510(k), De Novo, and PMA), for postmarket vulnerability management, and for the security questionnaires health systems send before they buy. The evidence is part of the product’s regulatory file.

Health delivery organizations (hospitals, imaging centers, physician groups) need it to understand what a device exposes on their clinical network, to satisfy the HIPAA Security Rule’s evaluation requirement for systems that handle electronic protected health information, and to support procurement decisions. Our HIPAA penetration testing service covers that side; this guide focuses mostly on the device itself.

What section 524B requires

Section 524B, added by the Consolidated Appropriations Act of 2023 and effective March 29, 2023, applies to any “cyber device”: a device that includes software, can connect to the internet, and could be vulnerable to cybersecurity threats. Since October 1, 2023 the FDA has enforced it through its refuse-to-accept policy, which means a submission missing the required cybersecurity content may not even reach substantive review.

For a cyber device, the manufacturer must:

1. Submit a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure.
2. Design, develop, and maintain processes that provide reasonable assurance the device and related systems are cybersecure, and make postmarket updates and patches available, on a regular cycle and out of cycle for critical vulnerabilities.
3. Provide a software bill of materials covering commercial, open-source, and off-the-shelf components.
4. Comply with any other requirements the FDA may add by regulation.

Penetration testing is not named in the statute. It is named in the guidance that tells reviewers what “reasonable assurance” looks like.

What the FDA premarket guidance expects

The FDA’s final guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (issued September 2023 and updated in June 2025 to incorporate the 524B provisions), describes a secure product development framework and the documentation reviewers expect. The elements that matter most for testing:

• Threat modeling for the device and the system it operates in, which is where the penetration test’s scope comes from.
• A cybersecurity risk assessment that is distinct from the safety risk assessment, because an exploitable vulnerability is a risk even when no patient harm has yet occurred.
• Security architecture views, including the interfaces, trust boundaries, and data flows the test will exercise.
• Cybersecurity testing, which the guidance breaks into security requirements testing, threat mitigation testing, vulnerability testing, and penetration testing. Reviewers expect to see the test reports, the findings, and how they were resolved, and the guidance emphasizes independence of the testers from the development team.
• The SBOM, with known vulnerabilities in listed components assessed.
• Labeling that tells users what security features the device has and how to operate it securely.

In short, the submission has to show that someone competent tried to break the device and that what they found was fixed. That is the penetration test, and its report becomes an exhibit.

What a medical device penetration test covers

A connected medical device is an IoT device with a regulatory file attached, so the layered approach in our IoT penetration testing guide applies. The clinical context changes the emphasis.

Surface	What is tested	Why it matters clinically
Device hardware and debug ports	UART, JTAG, SWD, USB service ports, storage	Physical access in a ward or service bay is realistic
Firmware and embedded software	Credentials, keys, update verification, secure boot	Compromise persists across the fleet and across patients
Wired interfaces	Serial, USB, Ethernet, DICOM and HL7 endpoints	Integration protocols were designed for trusted networks
Wireless interfaces	Bluetooth Low Energy, Wi-Fi, proprietary RF	Attacks from the parking lot or the next bed
Network services	Web interfaces, remote support, telemetry	Default credentials and unauthenticated control are common
Companion and clinician apps	Mobile and desktop applications	Often the easiest path to the device or to patient data
Cloud and integration backends	Device management, data platforms, EHR integrations	Cross-patient and cross-device authorization failures
Update and provisioning	Over-the-air, USB, and service-tool updates	An unsigned update path makes every other fix reversible

Two clinical protocols deserve specific attention. DICOM, used by imaging systems, and HL7 version 2, used by most clinical integrations, were designed for trusted networks and generally offer no authentication or encryption on their own. A test checks what an attacker on the clinical network can do with them: query or alter studies, inject messages, or reach the systems behind the interface. Modern FHIR APIs are tested the way any API penetration test treats authorization and data exposure.

Testing safely: the rules that differ

Medical device testing has constraints that a web application test does not.

• Never test a device in clinical use. Testing happens on bench units, engineering samples, or a manufacturer test environment. A hospital that wants to test a deployed device does so on a spare unit in a lab segment, never on the ward.
• Patient safety is the first rule of engagement. Techniques that could alter therapy delivery, corrupt a study, or crash a device are agreed in advance and executed only where they cannot reach a patient.
• Validated environments stay validated. Where the manufacturer’s test infrastructure is under design controls, the test plan is coordinated with quality and regulatory teams so evidence is captured without disturbing the validated state.
• Findings feed the risk file. Every finding is written with the cybersecurity risk assessment in mind: exploitability, the patient-harm scenario it could enable, and the mitigation, so the regulatory team can update the assessment rather than translate a generic report.

Writing the results into the submission

Reviewers look for a coherent chain from threat model to test to fix. The report should therefore include:

• A test plan that references the threat model and security architecture, so it is clear why each interface was tested.
• Methodology and tester independence, stating who tested, their qualifications, and that they were independent of development.
• Findings with severity, exploitability, and clinical impact, mapped to the relevant standard (OWASP ISVS, IEC 62443-4-2, or the FDA guidance’s own categories).
• Resolution evidence: what was fixed, what was accepted with justification, and the retest confirming the fixes.
• SBOM cross-references, where a finding relates to a third-party component, so the postmarket monitoring plan can track it.

Manufacturers that treat the report as part of the design history file, rather than a one-time deliverable, have a much easier time with postmarket obligations, because the same document explains what was tested and why when a new vulnerability appears in a listed component.

For hospitals and health systems

A health delivery organization cannot open every device on its network, but it can do three things well. First, ask manufacturers for their penetration test summary and the MDS2 (Manufacturer Disclosure Statement for Medical Device Security) during procurement, and treat a missing test as a finding. Second, run an internal penetration test that includes the clinical network segments, because the realistic attack on a medical device is from a compromised workstation on the same VLAN, and segmentation is the control that limits it. Third, keep device findings inside the HIPAA risk analysis, since a monitoring device that exposes patient data is an ePHI system under the Security Rule. Our guide to healthcare penetration testing covers the organization-wide view.

Standards and references that reviewers recognize

• FD&C Act section 524B (cyber device requirements) and the FDA premarket cybersecurity guidance (2023, updated 2025).
• FDA postmarket cybersecurity guidance (2016) for vulnerability management after clearance.
• IEC 81001-5-1, the health software security life cycle standard the FDA recognizes.
• AAMI TIR57 and AAMI SW96 for medical device security risk management.
• UL 2900-2-1 for network-connectable healthcare product testing.
• OWASP ISVS and IEC 62443-4-2 for component-level technical requirements.
• NIST SP 800-30 for the risk assessment methodology most submissions cite.

Frequently asked questions

Does the FDA require a penetration test for every device? The statute requires reasonable assurance of cybersecurity for every cyber device, and the guidance names penetration testing as one of the testing types reviewers expect. In practice, a submission for a connected device without independent testing evidence invites deficiency letters.

When in development should we test? Late enough that the design is stable, early enough that a hardware change is still possible. Testing an engineering sample before design freeze, then retesting the production candidate, is the pattern that avoids both a redesign and a deficiency.

Can the test cover our companion app and cloud platform? Yes, and the submission should cover them, because the guidance treats the device and its related systems together.

How long does it take? One to three weeks of testing for a typical device and its companion systems, followed by reporting and a free retest of the fixes, so the timeline fits inside a normal submission preparation window.

What does it cost? Our hardware and IoT penetration testing starts at $5,200 for a small device, fixed before work begins. Engagements that include the app, cloud platform, and integration interfaces are quoted after scoping. Starting prices for every service are on our pricing page.

Preparing a premarket submission, or evaluating a device before it joins your clinical network? Scope a medical device assessment and we will map the test plan to your threat model and your reviewer’s expectations.