Does FDA require penetration testing for every medical device?

FDA does not require penetration testing for every device, but it does expect cybersecurity testing commensurate with risk. For any device with network, wireless, or removable-media interfaces — which is most modern devices — penetration testing by qualified testers is now the de facto standard, and submissions without it are commonly issued deficiencies.

What is the difference between an SBOM and a SOUP analysis?

An SBOM is a machine-readable inventory of every software component in the device. A SOUP (Software of Unknown Provenance) analysis goes further: it justifies the security posture of components you did not author and cannot fully verify, including residual risk acceptance and any compensating controls.

Can I use one cybersecurity package for FDA, EU MDR, and TGA submissions?

Yes, with discipline. If you align documentation to IMDRF Principles and Practices for Medical Device Cybersecurity and MDCG 2019-16, and design to the strictest jurisdiction in your launch plan, the same underlying evidence — threat model, SBOM, risk report, test reports, postmarket plan — can support FDA, MDR, MHRA, TGA, and increasingly NMPA and PMDA submissions with region-specific cover documents.

How long does FDA cybersecurity review typically take?

Cybersecurity review is integrated into the standard 510(k), De Novo, or PMA review timeline, not a separate clock. The risk is not the review itself — it is the deficiency-letter cycle. A clean first submission keeps you on the standard timeline. A submission that triggers a major cybersecurity deficiency typically adds 60–120 days, depending on how quickly you can produce the missing artifacts.

What is Section 524B and why does it matter?

Section 524B of the FD&C Act, enacted in late 2022 and effective March 2023, gave FDA explicit statutory authority to require cybersecurity documentation in premarket submissions for cyber devices and to refuse-to-accept submissions that do not include it. Before 524B, cybersecurity expectations were guidance-based. After 524B, they are enforceable. That is the regulatory shift that changed the cost of doing it badly.

Where can I read the FDA's own guidance?

The current authoritative document is the FDA's [Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions), finalized in September 2023, along with the FDA's ongoing premarket cybersecurity Q&A and the underlying AAMI TIR57 standard.

Article

What the FDA Actually Wants in a 2026 Premarket Cybersecurity Submission

Key takeaways

The 2023 Section 524B authority gave FDA the explicit power to refuse-to-accept submissions that lack cybersecurity documentation — and they are using it.
Threat models that do not name the asset, the threat actor, the entry point, and the mitigation rarely survive review.
SBOMs are table stakes; what reviewers actually scrutinize is your SOUP / third-party component analysis and how you justify residual risk.
Penetration testing is now expected, not optional, for any device with network or wireless interfaces — and reviewers want methodology, scope, and findings, not just an attestation.
Postmarket cybersecurity plans are reviewed as part of premarket. You cannot defer them.
International alignment (IMDRF, MDCG 2019-16, TGA, NMPA) is increasingly the path of least resistance — design once, submit everywhere.

Why this matters

When I founded Blue Goat Cyber in 2022, premarket cybersecurity was still treated by many manufacturers as a checklist item near the end of the project. By 2024, after the FDA gained Refuse-to-Accept authority under Section 524B of the FD&C Act, that approach started costing companies six-figure delays per submission. In 2025 my team cleared more than 250 FDA cybersecurity submissions, and the pattern is unambiguous: the manufacturers who pass on the first round are the ones who treat cybersecurity as a Total Product Lifecycle (TPLC) discipline, not a documentation drill at the end.

For a connected device today, a single deficiency letter typically delays clearance 60–120 days and costs the program more than the entire cybersecurity engagement would have. Compound that across an EU CRA, MDR, IMDRF, and a multi-region launch, and the math is brutal. Getting the premarket package right the first time is now the single highest-ROI cybersecurity investment a MedTech company can make.

What documents does an FDA premarket cybersecurity submission actually require?

At minimum, FDA reviewers expect a Secure Product Development Framework (SPDF) description, a security architecture view, a threat model, a cybersecurity risk management report aligned to AAMI TIR57, a Software Bill of Materials (SBOM) with vulnerability and SOUP analysis, evidence of cybersecurity testing (penetration testing and vulnerability scanning), labeling that informs users of cybersecurity controls and responsibilities, and a postmarket cybersecurity management plan.

The FDA's Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions guidance enumerates the expectations. What it does not tell you is how reviewers actually read these documents. They read for traceability: every identified threat must trace to a control, every control to a verification, every residual risk to a justification. If those threads break anywhere in the package, you get a deficiency.

What does a threat model that survives FDA review look like?

A threat model that survives review names the asset, identifies the entry point, classifies the threat using a structured methodology like STRIDE, scores the likelihood and impact, and ties the mitigation back to a verifiable design control.

Reviewers do not want a STRIDE table copied from a tutorial. They want to see the intended-use context, the network and trust boundaries drawn explicitly, every external interface (wired, wireless, USB, service-port) enumerated, and a defensible argument for why each identified threat is either mitigated or accepted with justification. "Out of scope" is not an answer for an entry point that physically exists on the device.

How thorough does the SBOM and third-party component analysis need to be?

Reviewers want a complete SBOM in a machine-readable format (SPDX or CycloneDX), a vulnerability assessment against known CVEs at time of submission, and a Software of Unknown Provenance (SOUP) analysis for any component you did not author and cannot fully verify.

In practice, the SBOM is the easy part — modern build pipelines produce one in minutes. The hard part is the SOUP analysis, where you have to justify the security posture of each third-party component, including any open-source library, embedded RTOS, or chipset firmware blob. Reviewers are now actively cross-referencing submitted SBOMs against the CISA Known Exploited Vulnerabilities Catalog. If a critical KEV is in your bill of materials and your report does not address it, you will hear about it.

What kind of cybersecurity testing does FDA expect?

For any device with network, wireless, or removable-media interfaces, FDA expects credentialed and uncredentialed penetration testing performed by qualified testers, plus vulnerability scanning of the device and any companion software. The report should describe scope, methodology, tools, tester qualifications, findings with severity, and remediations.

An attestation that "penetration testing was performed" is not a penetration test report. Reviewers want to see what was actually attempted — fuzzing of the wireless stack, attempts to bypass authentication, manipulation of update mechanisms, exploitation of exposed services — and what was found. Negative findings ("no exploitable vulnerabilities identified at this scope") are acceptable, but only when the scope is itself credible.

What does the postmarket cybersecurity plan need to cover?

The postmarket plan must describe how the manufacturer will monitor for new vulnerabilities affecting the device or its components, how it will coordinate disclosure with researchers and regulators, how it will patch deployed devices (and within what timeframe), and how it will communicate with users when a cybersecurity event affects safety or effectiveness.

Reviewers want concrete commitments: who runs the monitoring, what feeds you subscribe to, how triage decisions get made, and how a patch reaches a fielded device without breaking validated functionality. A postmarket plan that ends at "we will issue updates as needed" is a deficiency waiting to happen.

How does this map to EU, UK, and Asia-Pacific submissions?

If you build the package to FDA expectations and align documentation language to IMDRF Principles and Practices for Medical Device Cybersecurity and MDCG 2019-16, you can submit the same evidence base to Notified Bodies under MDR, to the MHRA, to the TGA in Australia, and increasingly to the NMPA in China and PMDA in Japan with minimal rework.

The EU Cyber Resilience Act adds horizontal cybersecurity obligations for connected products that already overlap heavily with MDR Annex I requirements. Designing for the strictest jurisdiction in your launch plan and back-mapping documentation is almost always cheaper than reverse-engineering compliance for each region after the fact.

How Christian approaches this

My team at Blue Goat Cyber has cleared more than 250 FDA cybersecurity submissions across Class II and Class III devices, including SaMD, IoMT, wearable monitors, infusion systems, imaging platforms, and implantables. We treat cybersecurity as a Total Product Lifecycle discipline from concept through postmarket, and we map every artifact in the submission to the underlying FDA guidance, AAMI TIR57, IMDRF, and (where it applies) the EU MDR and CRA.

The approach in my 2026 book — Medical Device Cybersecurity: An In-Depth Guide — codifies what we have learned. It is the playbook I wish had existed when I was first navigating these submissions with my own product clients in 2022.

Frequently asked questions

Does FDA require penetration testing for every medical device?: FDA does not require penetration testing for every device, but it does expect cybersecurity testing commensurate with risk. For any device with network, wireless, or removable-media interfaces — which is most modern devices — penetration testing by qualified testers is now the de facto standard, and submissions without it are commonly issued deficiencies.
What is the difference between an SBOM and a SOUP analysis?: An SBOM is a machine-readable inventory of every software component in the device. A SOUP (Software of Unknown Provenance) analysis goes further: it justifies the security posture of components you did not author and cannot fully verify, including residual risk acceptance and any compensating controls.
Can I use one cybersecurity package for FDA, EU MDR, and TGA submissions?: Yes, with discipline. If you align documentation to IMDRF Principles and Practices for Medical Device Cybersecurity and MDCG 2019-16, and design to the strictest jurisdiction in your launch plan, the same underlying evidence — threat model, SBOM, risk report, test reports, postmarket plan — can support FDA, MDR, MHRA, TGA, and increasingly NMPA and PMDA submissions with region-specific cover documents.
How long does FDA cybersecurity review typically take?: Cybersecurity review is integrated into the standard 510(k), De Novo, or PMA review timeline, not a separate clock. The risk is not the review itself — it is the deficiency-letter cycle. A clean first submission keeps you on the standard timeline. A submission that triggers a major cybersecurity deficiency typically adds 60–120 days, depending on how quickly you can produce the missing artifacts.
What is Section 524B and why does it matter?: Section 524B of the FD&C Act, enacted in late 2022 and effective March 2023, gave FDA explicit statutory authority to require cybersecurity documentation in premarket submissions for cyber devices and to refuse-to-accept submissions that do not include it. Before 524B, cybersecurity expectations were guidance-based. After 524B, they are enforceable. That is the regulatory shift that changed the cost of doing it badly.
Where can I read the FDA's own guidance?: The current authoritative document is the FDA's [Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions), finalized in September 2023, along with the FDA's ongoing premarket cybersecurity Q&A and the underlying AAMI TIR57 standard.