Medical device cybersecurity for FDA submissions.

“My device isn’t a cyber device.”

All three Section 524B(c) conditions must be met: sponsor-validated, installed, or authorized software; the ability to connect to the internet; and technological characteristics that could be vulnerable to cybersecurity threats. USB charging alone does not establish internet connectivity. Assess actual direct or indirect internet connections, including those through companion systems. Statutory duties and the FDA's guidance recommendations are distinct.

“My developers know cybersecurity.”

Secure coding alone does not document the device's cybersecurity evidence. Our threat-modeling scope includes data flow diagrams, trust boundaries, entry points, STRIDE analysis, attack trees, and the Threat Table. The four security architecture views are separate deliverables, not included in standalone threat modeling. A broader premarket proposal can include those views alongside the risk assessment, SBOM, and security testing. Trace threats to controls, applicable tests, and manufacturer-supplied patient-harm context.

“It’s about protecting data.”

The FDA's February 2026 final premarket guidance (Section IV) frames cybersecurity as patient safety, device availability, and data integrity, in that order. HIPAA and data confidentiality language alone gets flagged as a scope gap. Your threat model has to show how a compromise could harm a patient, render the device unavailable, or corrupt the data it acts on. That is the lens reviewers apply.

“We’ll add cybersecurity later.”

The FDA recommends an SPDF with traceability from architecture and threats through security requirements, test evidence, and unresolved-anomaly disposition. Late documentation gaps can require rework; the impact depends on the device and the gaps identified.

“Traditional IT cybersecurity works.”

IT pen testing assumes you can take a system offline. Medical device pen testing has to respect availability constraints, you cannot brick an infusion pump mid-test. The Test Report documents tester independence, scope, methods, and results, alongside firmware-level testing the FDA increasingly expects (secure boot verification, OTA update path, debug interfaces). A SOC 2 report or a generic vulnerability scan rebadged for the device will be rejected.