5 Costly Misconceptions About Medical Device Cybersecurity

Misconception 01

“My device isn’t a cyber device.”

Reality

Section 524B defines a cyber device by three conditions, all of which must be met: (1) it includes software validated, installed, or authorized by the sponsor; (2) it has the ability to connect to the internet; and (3) it contains technological characteristics that could be vulnerable to cybersecurity threats. If your device meets all three, the full cybersecurity package is mandatory in your 510(k), De Novo, or PMA, regardless of risk class or clinical use. There is no soft path.

Why it matters

The 2023 omnibus expanded the definition so broadly that nearly every modern medical device qualifies. A Bluetooth-enabled thermometer, a USB-charged hearing aid, and a cloud-connected infusion pump are all in scope. Reviewers will request the full cybersecurity package regardless of how clinical your team views the product.

What FDA actually expects

The FDA's February 3, 2026 final guidance (carrying forward the §524B definition) defines a cyber device as one that (1) includes software validated, installed, or authorized by the sponsor, (2) has the ability to connect to the internet, and (3) contains technological characteristics that could be vulnerable to cybersecurity threats. All three are easy to meet.

Christian on this misconception

“Almost every modern medical device meets the §524B definition of a cyber device. Teams discover this when the FDA asks for the cybersecurity package they didn't budget for.”

Cybersecurity in MedTech: FDA Compliance, Patient Safety, & the Hidden Risks You're Missing·Global Medical Device Podcast (Greenlight Guru) · Ep. 407

What we hear in kickoff calls

“It’s just Bluetooth - that doesn’t count.”
“We don’t store PHI, so we’re fine.”
“The cloud piece is a separate product.”

FDA premarket cybersecurity package

Misconception 02

“My software developers know cybersecurity.”

Reality

Reviewers want artifacts your developers do not produce in normal SDLC: a threat model that traces each cyber risk to a specific patient-harm scenario in your ISO 14971 file, a CycloneDX SBOM with VEX statements for every unresolved CVE, and an independent third-party penetration test report with named testers and methodology. We have seen submissions where the dev team handed over a clean SAST report and a vulnerability scan, and FDA still issued an AI letter for missing threat-to-harm traceability. Secure coding is necessary; it is not the deliverable.

Why it matters

Medical-device cybersecurity is a regulatory discipline that intersects ISO 14971 risk, AAMI TIR57/SW96, IEC 62304, and §524B. Even excellent application-security engineers rarely know how to map a cyber risk to a patient-harm scenario, build a CycloneDX SBOM with VEX, or write a postmarket monitoring plan the FDA will accept.

What FDA actually expects

“Insufficient third-party penetration testing” is one of the top 5 reasons the FDA issues AI letters on cyber. Self-attestation by your dev team isn’t accepted as objective evidence.

Christian on this misconception

“Your developers writing secure code is necessary, but it isn't what the FDA is asking for. They want independent third-party testing, an SBOM, a threat model tied to patient harm - that's a different discipline.”

Cybersecurity in Medical Devices with Christian Espinosa·Alpha Sophia Spotlight · Ep. 23

What we hear in kickoff calls

“Our engineers do code reviews - we’re covered.”
“We ran a vulnerability scanner; that’s a pen test.”
“Cyber is part of QA.”

Medical device penetration testing

Misconception 03

“It’s about protecting data.”

Reality

The FDA does not frame medical device cybersecurity as data protection. It is patient safety, device availability, and the integrity of clinical function. This is not HIPAA, and it is not data privacy. The February 3, 2026 premarket guidance (Section V) and AAMI TIR57 require every cyber risk to be traced to a specific patient-harm scenario in your ISO 14971 file. A submission that argues in CIA-triad and CVSS terms without linking to clinical hazard gets held, every time.

Why it matters

Confidentiality, integrity, and availability matter only insofar as their compromise can hurt a patient. A submission written in pure InfoSec language (CIA triad, CVSS scores) without linking to clinical harm gets held. Reviewers want to see: vulnerability → exploit scenario → clinical hazard → severity to patient.

What FDA actually expects

“Failure to align risk methodologies with patient safety” is one of the top 5 deficiencies cited in FDA premarket cyber holds. The cyber risk register must feed directly into your hazard analysis.

Christian on this misconception

“In healthcare, a cybersecurity failure is a patient safety failure. Every shortcut eventually finds a patient.”

Founder profile · Christian Espinosa·bluegoatcyber.com

What we hear in kickoff calls

“We don’t handle PHI - cyber doesn’t apply.”
“Our CVSS scores are all low.”
“This is an IT problem, not a clinical one.”

Threat modeling that maps to patient harm

Misconception 04

“We’re not ready for cybersecurity yet - we’ll iterate later.”

Reality

The Secure Product Development Framework cannot be retrofitted. SPDF requires unbroken traceability from architecture decisions, through security requirements and threat model, to test evidence and unresolved-anomaly disposition. Reviewers can see when that chain was assembled after the fact: dates do not line up, threat model assumptions contradict the as-built design, and the design history file has no security entries before V&V. Once that pattern is visible, expect a Major Deficiency on SPDF and a request to redo the design controls.

Why it matters

FDA’s Secure Product Development Framework (SPDF) expects threat modeling, SBOM tracking, and security requirements to start at concept - not after V&V. Late-stage retrofits trigger rework, schedule slip, and design-history-file gaps that surface as 510(k) holds. The earlier security enters the design, the cheaper and faster clearance becomes.

What FDA actually expects

“Late-stage cybersecurity considerations” is one of the top 5 deficiencies cited by FDA reviewers. SPDF, IEC 81001-5-1, and AAMI TIR57 all require lifecycle integration - not a final-stage audit.

Christian on this misconception

“Cybersecurity in MedTech has to be iterative - you bake it in at concept and revisit it at every milestone. Waiting until you're ready to submit is the most expensive way to do this.”

The Importance of Iterative Cybersecurity in MedTech·Paradigm Shift of Healthcare · May 27, 2025

What we hear in kickoff calls

“We’ll add security after the prototype works.”
“Cyber is a pre-submission task.”
“We’ll bolt it on at design freeze.”

Build security into the product lifecycle

Misconception 05

“Traditional IT cybersecurity will work for MedTech.”

Reality

Medical device pen testing is not enterprise pen testing. Testers must work under availability constraints (you cannot crash a pacemaker, an infusion pump, or an imaging system mid-test), exercise firmware and hardware interfaces (BLE pairing, USB, JTAG, OTA update path, service ports) the way an attacker would, and produce a signed Letter of Attestation that names the testers, their independence, scope, methodology, and findings. FDA's February 3, 2026 guidance is explicit on these points. A SOC 2 pen test or a web-app scan rebadged for the device will be rejected as insufficient evidence.

Why it matters

You can’t reboot a pacemaker for a patch. You can’t install an EDR agent on a 32-bit RTOS. You can’t require MFA on a sterile-field surgical tool. Medical-device cybersecurity demands constrained-resource cryptography, deterministic update paths, safe-state design, and patient-safety-aware risk acceptance - none of which exist in NIST 800-53 or CIS Controls.

What FDA actually expects

FDA, AAMI SW96, and IEC 81001-5-1 all explicitly recognize that medical devices require their own cybersecurity framework. Borrowing IT playbooks wholesale is a frequent root cause of submission deficiencies.

Christian on this misconception

“You can't take an enterprise IT playbook - patch Tuesdays, EDR agents, MFA everywhere - and apply it to a pacemaker or an infusion pump. The constraints and the consequences are completely different.”

Securing Medical Devices and Saving Lives with Christian Espinosa·MILCOM Founders Podcast · Ep. 4

What we hear in kickoff calls

“Our IT team handles cyber.”
“We use NIST 800-53 - we’re good.”
“We’ll just put EDR on the device.”

Medical-device-specific cybersecurity

5 costly misconceptions delaying FDA clearance.

“My device isn’t a cyber device.”

“My software developers know cybersecurity.”

“It’s about protecting data.”

“We’re not ready for cybersecurity yet - we’ll iterate later.”

“Traditional IT cybersecurity will work for MedTech.”

Think you’ve avoided all five?

FDA premarket cybersecurity services

Threat modeling services

Medical device penetration testing

Cost-of-delay calculator

FDA cybersecurity readiness quiz

Cybersecurity FAQ

5 costly misconceptions delaying FDA clearance.

“My device isn’t a cyber device.”

“My software developers know cybersecurity.”

“It’s about protecting data.”

“We’re not ready for cybersecurity yet - we’ll iterate later.”

“Traditional IT cybersecurity will work for MedTech.”

Think you’ve avoided all five?

Related resources

FDA premarket cybersecurity services

Threat modeling services

Medical device penetration testing

Cost-of-delay calculator

FDA cybersecurity readiness quiz

Cybersecurity FAQ