Blue Goat CyberSMMedical Device Cybersecurity
    ⌘K
    Reality check

    5 costly misconceptions delaying FDA clearance.

    After 250+ FDA submissions, these are the five beliefs we see crater MedTech timelines. Each one ends in an FDA hold, an AI letter, or a launch slip - and each one is preventable.

    “In healthcare, a cybersecurity failure is a patient safety failure. Every shortcut eventually finds a patient.”
    - Christian Espinosa, Founder & CEO, Blue Goat Cyber

    The five misconceptions

    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

    Think you’ve avoided all five?

    Take the 5-minute FDA cybersecurity readiness quiz and see exactly where your submission stands - before a reviewer does.

    Take the readiness quiz
    Go deeper

    Each misconception above maps to a service or tool that fixes it before the FDA gets the chance to flag it.

    FDA premarket cybersecurity services

    Full §524B-aligned package: SPDF, threat model, SBOM, pen test, postmarket plan.

    Read FDA premarket cybersecurity services

    Threat modeling services

    STRIDE-based threat models that trace cyber risk to patient harm - the way the FDA expects it.

    Read Threat modeling services

    Medical device penetration testing

    Independent, full-scope third-party testing aligned with FDA expectations.

    Read Medical device penetration testing

    Cost-of-delay calculator

    See exactly what one cyber deficiency costs you in lost revenue and resubmission overhead.

    Read Cost-of-delay calculator

    FDA cybersecurity readiness quiz

    5-minute quiz that scores your submission readiness across all FDA cyber dimensions.

    Read FDA cybersecurity readiness quiz

    Cybersecurity FAQ

    Straight answers on §524B, SBOMs, pen testing, and the SPDF.

    Read Cybersecurity FAQ