Blue Goat CyberBlue Goat CyberSMMedical Device Cybersecurity
    ⌘K
    Reality check

    5 costly misconceptions delaying FDA clearance.

    After 250+ 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

    If it has software, firmware, a wireless radio, a USB port, or talks to anything else - the FDA considers it a cyber device under Section 524B of the FD&C Act.

    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 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

    Secure coding ≠ medical-device cybersecurity. The FDA expects an SPDF, threat models, SBOM hygiene, and independent third-party penetration testing - none of which are part of standard SDLC training.

    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 FDA will accept.

    What FDA actually expects

    “Insufficient third-party penetration testing” is one of the top 5 reasons 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

    It’s about protecting patients. The FDA evaluates cybersecurity as a patient-safety discipline - every cyber risk must be traced to a potential patient-harm scenario in your ISO 14971 risk file.

    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

    Cybersecurity is supposed to be designed in across the Total Product Life Cycle (TPLC). Bolting it on at design freeze is the single most expensive mistake a MedTech team can make.

    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

    Enterprise cybersecurity practices (patch Tuesdays, EDR, MFA everywhere) don’t map to constrained, embedded, life-critical devices. MedTech needs a discipline of its own.

    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 FDA gets the chance to flag it.