Is this true: “FDA clearance means my device is secure.”?
No. FDA clearance confirms a device meets premarket submission requirements, it is not a security audit. Threats evolve daily; clearance is a snapshot, not a shield. Manufacturers who equate clearance with security ship devices with exploitable vulnerabilities and miss postmarket obligations under Section 524B of the FD&C Act.
Is this true: “Our device isn't connected, so it can't be hacked.”?
No. ‘Air-gapped’ is a myth. USB ports, service laptops, Bluetooth diagnostics, and supply-chain firmware updates all create attack surface, Stuxnet proved this in 2010. Isolated devices have been compromised through technicians' update tools, infected service media, and embedded radios the design team forgot existed.
Is this true: “We'll bolt on cybersecurity before submission.”?
No. Security cannot be retrofitted. The FDA expects a Secure Product Development Framework (SPDF) integrated from concept through end-of-life. Late-stage security work triggers redesigns, refused submissions (RTAs), and 6–18 month delays, far more expensive than building it in from day one.
Is this true: “An SBOM is just a checkbox for the FDA.”?
No. A Software Bill of Materials is the foundation of vulnerability management. Without it, you cannot answer ‘are we affected by this CVE?’ in the hours regulators and hospitals expect. Manufacturers without a living SBOM lose hospital contracts and cannot meet 524B postmarket monitoring obligations.
Is this true: “Penetration testing is the same as a security assessment.”?
No. A pentest finds exploitable bugs in a finished product. A security assessment evaluates threat models, architecture, SDLC, cryptographic choices, and supply chain, long before code freezes. Teams that only pentest discover architectural flaws too late to fix without restarting verification and validation.
Is this true: “Cybersecurity is the IT department's problem.”?
No. Medical device security is a patient-safety discipline. It belongs in Quality, Regulatory, and Engineering, owned by leadership, not delegated to corporate IT. Devices owned by IT alone fail to integrate security into risk management files (ISO 14971) and design history files, the artifacts the FDA actually reviews.
Is this true: “Encryption alone makes our device secure.”?
No. Encryption protects data in transit and at rest, but doesn't address authentication, authorization, secure boot, key management, or insecure defaults, where most breaches actually occur. ‘We use AES-256’ is not a security architecture. It is one control in a defense-in-depth strategy.
Is this true: “We passed last year, we're still compliant.”?
No. FDA guidance (2023 → 2025 → Feb 2026), EU MDR, and IEC 81001-5-1 evolved significantly. Postmarket requires continuous monitoring, coordinated vulnerability disclosure, and timely patching. Static compliance is non-compliance. The agencies expect a living program with documented evidence of ongoing surveillance.
Is this true: “Our contract manufacturer handles security.”?
No. Legal accountability for device security stays with the legal manufacturer (the name on the label). Supplier controls, audits, and SBOM ingestion are your responsibility. When a third-party component ships a CVE, regulators and hospitals call you, not your CM.
Is this true: “A breach won't happen to us, we're too small.”?
No. Smaller manufacturers are targeted precisely because they have fewer defenses. Ransomware groups now treat MedTech supply chains as soft entry points to hospitals. The average healthcare breach costs $9.77M. For a small device maker, a single incident can be existential.
Is this true: “Once a device ships, security is done.”?
No. FDA expects active postmarket cybersecurity throughout the device lifecycle: vulnerability monitoring, timely patches, coordinated disclosure, and end-of-life communications to customers. Devices with no postmarket plan get pulled from hospital formularies and trigger MedWatch reports when CVEs land unaddressed.
Is this true: “Moving to the cloud means our cloud provider handles security.”?
No. Cloud is a shared-responsibility model. AWS/Azure/GCP secure the infrastructure; you still own identity, data, configuration, network policy, and the SaMD application itself. Misconfigured S3 buckets, exposed APIs, and weak IAM are now the leading cause of breaches in cloud-connected medical software.
Is this true: “AI/ML medical software doesn't need new security thinking.”?
No. AI/ML SaMD introduces new attack surfaces: model poisoning, adversarial inputs, training-data exfiltration, and prompt injection. The FDA's 2025 AI/ML lifecycle guidance and PCCPs treat these as cybersecurity concerns. Models that misclassify due to adversarial input can cause clinical harm, and aren't caught by traditional appsec testing.
Is this true: “Open-source components are free and safe to use.”?
No. Open source is free to license, not free of risk. Every dependency inherits the upstream's vulnerabilities (Log4Shell, OpenSSL CVEs) and must be tracked in your SBOM with a remediation plan. Manufacturers without OSS governance ship known-vulnerable libraries and can't respond when a critical CVE drops.
Is this true: “Bluetooth Low Energy and Wi-Fi pairing are secure by default.”?
No. BLE Just-Works pairing, fixed PINs, and unauthenticated GATT services are widespread in medical devices, and trivial to exploit. SweynTooth, BleedingTooth, and KRACK proved entire device classes were vulnerable. Wireless protocol flaws have led to insulin pump, pacemaker, and patient monitor advisories from CISA and the FDA.
Is this true: “We don't need a vulnerability disclosure policy, no one's looking.”?
No. Researchers, hospitals, and the FBI are looking. FDA premarket guidance and ISO/IEC 30111 expect a published Coordinated Vulnerability Disclosure (CVD) process so external findings can reach you safely. Without a CVD program, vulnerabilities reach Twitter, hospital procurement, or CISA before they reach your engineering team.
Is this true: “Devices in the field don't need to support secure updates.”?
No. Section 524B explicitly requires the ability to deploy postmarket updates and patches in a reasonable time. That means signed firmware, integrity verification, rollback protection, and a deployment plan. Devices without secure OTA update mechanisms cannot be remediated when a critical CVE lands, forcing recalls instead of patches.
Is this true: “Security testing belongs in V&V at the end of the project.”?
No. Security activities run in parallel with the entire SDLC: threat modeling at design, SAST in CI, DAST in integration, fuzzing on protocols, pentest before release. V&V verifies, it doesn't discover. Discovering a cryptographic flaw or auth bypass during V&V means restarting verification, months of delay and budget overrun.
Is this true: “Hospitals will buy our device regardless of security posture.”?
No. Major IDNs (HCA, Mayo, Kaiser, Intermountain) require MDS2 forms, SBOMs, patch SLAs, and risk assessments before procurement. Weak security answers kill deals. Manufacturers without security collateral lose contracts to competitors who can answer hospital questionnaires in days, not months.
Is this true: “Cyber insurance will cover us if something goes wrong.”?
No. Cyber policies increasingly exclude losses from missing controls (no MFA, no patching program, no SBOM). Premiums have spiked 50–100% and carriers are denying claims for foreseeable failures. Insurance is a backstop, not a strategy. Underwriters now demand evidence of an SPDF and incident response plan before binding coverage.
Is this true: “We're HIPAA compliant, so we're cybersecure.”?
No. HIPAA governs the privacy and security of protected health information held by covered entities and business associates. It does not regulate medical device cybersecurity, that is FDA's lane via the FD&C Act and §524B. Manufacturers conflating HIPAA with device security ship products that meet no premarket cyber requirements and still get refused at submission.
Is this true: “Our device is Class I, so cybersecurity rules don't apply.”?
No. Section 524B applies to any 'cyber device' regardless of classification. If your Class I device contains software, can connect, and could be vulnerable, FDA expects an SBOM, SPDF evidence, and a postmarket plan. Class I manufacturers assuming exemption are caught flat-footed when 510(k) exempt does not mean cybersecurity exempt, and hospitals still demand MDS2 forms.
Is this true: “If we're cleared by the FDA, the EU will accept the same package.”?
No. EU MDR Annex I §17.2 and the Cyber Resilience Act impose distinct cybersecurity requirements. Notified Bodies want IEC 81001-5-1 evidence, MDCG 2019-16 alignment, and CRA-style essential requirements, not an FDA cover letter. Manufacturers reusing FDA submissions in Europe trigger Notified Body deficiencies, CE-mark delays, and withdrawn product launches.
Is this true: “Any penetration test will satisfy our security requirements.”?
No. Scope is everything. A pentest limited to the web UI tells regulators nothing about firmware, wireless protocols, or supply chain. FDA expects testing scope to mirror your threat model and architecture, with documented coverage rationale. Manufacturers presenting narrow pentest reports get deficiency letters citing inadequate cybersecurity testing under §V of the current FDA premarket cybersecurity guidance (Feb 2026).
Is this true: “Application-layer security is enough, hardware is fine.”?
No. Without secure boot, hardware root of trust, debug-port lockdown, and side-channel protections, an attacker with brief physical access can dump firmware, extract keys, and persist below your OS. Implantables and bedside devices both qualify. Devices without hardware-rooted security have been jailbroken on YouTube, leading to FDA safety communications and stock-moving recalls.
Is this true: “Our crypto is fine, we don't need to think about it again.”?
No. RSA-2048 and ECC will fall to a cryptographically relevant quantum computer. Devices shipping today with 10-15 year service lives need crypto agility, the ability to swap algorithms in the field, and a path to NIST PQC standards (ML-KEM, ML-DSA). Devices hard-coded to today's algorithms will be unpatchable when 'harvest now, decrypt later' attacks mature, forcing recalls instead of OTA updates.
Is this true: “A shared admin password is fine for service technicians.”?
No. Modern medical device security expects per-user identity, role-based access control, and short-lived credentials, not a sticky note in the service manual. Hardcoded or shared credentials are a top finding in CISA medical device advisories. Shared credentials trigger CISA advisories, hospital procurement red flags, and FDA deficiency letters citing insufficient access control.
Is this true: “Running our SaMD on Kubernetes makes it secure.”?
No. Kubernetes is powerful, not secure by default. Default service accounts, permissive network policies, exposed dashboards, and unsigned images are the norm. SaMD on K8s still owns the cluster's security posture under the shared responsibility model. Misconfigured K8s clusters running SaMD have leaked PHI, served as ransomware footholds, and failed hospital security reviews.
Is this true: “If we find a serious vulnerability, we'll just issue a recall.”?
No. FDA expects you to patch first when feasible. A recall for a software vulnerability is a Class I/II event with MDR reporting, customer notification, and reputational fallout. Devices designed for secure OTA updates avoid most recalls. Manufacturers without patch-deploy capability convert every CVE into a recall, draining budgets and customer trust.
Is this true: “Our incident response plan is the IT team's runbook.”?
No. Medical device incidents trigger overlapping obligations: FDA MDR reporting, HHS breach notification (if PHI), CISA coordinated disclosure, customer comms, and clinical risk assessment. A generic IT runbook misses every regulator-specific clock. Manufacturers without a device-specific IR plan miss the 60-day HHS notification window and the 30-day FDA MDR clock, compounding penalties on top of the breach.
Is this true: “Our AI model is ours, so we control its supply chain.”?
No. Most clinical AI is built on third-party foundation models, pretrained weights, and pip-installed ML frameworks. Each is a supply-chain dependency: model cards, training-data provenance, and weight integrity belong in your SBOM (or AI-BOM) alongside the libraries. Manufacturers without an AI-BOM cannot answer 'what model version, trained on what data, with what weights?' when regulators or hospitals ask after an incident.
Is this true: “A Predetermined Change Control Plan lets us update our AI model whenever we want.”?
No. PCCPs authorize specific, pre-described modifications under defined verification and validation. Anything outside the boundary is a new submission. Cybersecurity controls (data integrity, model signing, monitoring) are part of what FDA expects to see described in the PCCP. Teams treating PCCPs as blanket permission ship out-of-scope updates that trigger Form 483s and unplanned 510(k)s.
Is this true: “LLM clinical copilots are safe because we put a disclaimer in the system prompt.”?
No. Indirect prompt injection through a patient note, lab PDF, or EHR field can override the system prompt, exfiltrate context, or rewrite recommendations. Disclaimers do not constrain model behavior. OWASP LLM01 and FDA's emerging AI guidance both treat this as a security-and-safety issue. A clinical copilot that follows attacker-controlled text in a chart can recommend wrong dosing or leak PHI to an external endpoint, neither of which a disclaimer prevents.
Is this true: “Once our AI model is validated, performance monitoring is a nice-to-have.”?
No. Model drift, data drift, and shifting clinical populations degrade performance silently. GMLP principle 9 and FDA's lifecycle approach require ongoing performance monitoring with thresholds and a defined response, security incidents include integrity, not just confidentiality. Unmonitored models silently degrade until a clinician notices, by which point patient harm reports and MDR filings are already in motion.
Is this true: “Federated learning means patient data never leaves the hospital, so it's private by design.”?
No. Gradients and model updates leak training data. Membership-inference and gradient-inversion attacks have reconstructed images and records from federated updates. Differential privacy, secure aggregation, and clipping are required, not optional. Federated MedTech projects shipped without privacy-preserving aggregation have leaked reconstructable images, voiding the privacy claim that justified the architecture.
Is this true: “The EU Cyber Resilience Act doesn't apply to us, we're regulated under MDR.”?
No. Most medical devices are exempted from CRA's substantive obligations because MDR/IVDR cover them, but only if MDR cybersecurity expectations are actually met. Accessories, standalone software, and components may still fall under CRA. The 36-month transition (full applicability Dec 2027) is now. Manufacturers misreading the carve-out will face dual obligations and CRA enforcement, including the 24-hour active-exploit notification clock to ENISA.
Is this true: “A CE mark is enough to sell into the UK.”?
No. MHRA accepts CE marking on a recognized basis through 30 June 2030, but the UKCA route, UK Responsible Person, and forthcoming UK-specific cybersecurity expectations are diverging. MHRA's 2024 software and AI roadmap signals UK-specific postmarket obligations. Manufacturers planning indefinite reliance on CE will hit a wall as MHRA finalizes its own framework, with no grandfathering for cybersecurity evidence.
Is this true: “Health Canada will accept our FDA cybersecurity package as-is.”?
No. Health Canada's 2019 Pre-market Requirements for Medical Device Cybersecurity overlap with FDA but require Canadian-specific evidence: licence-holder responsibilities, MDEL implications for distributors, and risk documentation aligned to Canadian guidance, not just an FDA cover letter. Submissions that copy-paste FDA artifacts get Information Requests and licence delays, particularly for SaMD and Class III devices.
Is this true: “Australia's TGA mirrors FDA, so cybersecurity evidence transfers cleanly.”?
No. TGA's Medical Device Cyber Security Guidance maps to Essential Principles and Australian-specific postmarket obligations. SaMD reclassifications (effective 2021) and 2024 IMDRF-aligned updates demand evidence packaged to TGA's structure, not FDA's. Manufacturers entering ANZ on FDA artifacts alone face TGA Section 41 conformity assessment delays and conditional registrations.
Is this true: “China NMPA cybersecurity rules are loose, we'll handle it later.”?
No. NMPA's 2022 Technical Review Guideline for Medical Device Cybersecurity, plus China's data security and cross-border data transfer laws, now require localized cybersecurity submissions, in-country data handling for many SaMD use cases, and NMPA-specific test reports. Late attention to NMPA cybersecurity blocks market entry and creates data-export liability that can't be unwound after launch.
Is this true: “The hospital's IT team owns medical device security once devices are deployed.”?
No. Healthcare Technology Management (HTM / clinical engineering / biomed) owns the device fleet. They control inventory, patching windows, MDS2 ingestion, and recall execution. IT may run the network, but cannot patch a Class II device without HTM and the manufacturer. When IT and HTM disagree on ownership, devices go unpatched for years and recall responses miss FDA-expected windows.
Is this true: “Decommissioning a device is just paperwork.”?
No. End-of-life devices contain PHI on internal storage, embedded credentials, and active certificates. Without media sanitization (NIST SP 800-88), credential rotation, and certificate revocation, decommissioned units resurface on eBay with full hospital network access intact. Researchers have repeatedly bought used infusion pumps and imaging consoles online containing live Wi-Fi keys and PHI, triggering breach notifications years after disposal.
Is this true: “An MDS2 form is a complete picture of a device's security posture.”?
No. MDS2 is a self-disclosure snapshot, not an assessment. It reflects design intent, not deployed configuration, and does not cover SBOM contents, CVE exposure, or postmarket patch SLA. Treat it as the start of a procurement conversation, not the end. HDOs that buy on MDS2 alone inherit fleets whose real posture diverges from what the form claims, surfacing during incidents or audits.
Is this true: “Putting medical devices on a separate VLAN is enough segmentation.”?
No. A flat medical VLAN with bidirectional EHR, PACS, and clinical-workflow access is a soft target. Real segmentation requires microsegmentation by device type and risk, east-west inspection, and explicit allow-lists for clinical traffic, not just a separate broadcast domain. Hospitals with 'medical VLAN' as their only control have seen ransomware traverse from a single compromised workstation to ventilators and infusion pumps within hours.
Is this true: “If a clinician signs up for a SaaS tool with their work email, that's not our problem.”?
No. Clinical SaaS, AI scribes, and patient-engagement tools introduced via shadow IT fall under HIPAA business associate, FDA SaMD, and procurement security review, even when no PO was issued. The hospital, not the vendor, owns the breach. Shadow clinical SaaS has caused HHS settlements where the HDO had no record of the tool, the BAA, or the data flow until enforcement arrived.
Is this true: “Embedding a 4G/5G modem makes our device cellular-secure.”?
No. Cellular modules carry their own attack surface: AT-command injection, baseband bugs, eSIM provisioning flaws, and APN misconfigurations that route patient data over carrier-default paths. The carrier secures the network. The device owns identity, APN, mTLS, and modem-firmware updates. Cellular-connected devices have been geolocated, downgraded to insecure 2G, and silently re-provisioned to attacker-controlled APNs.
Is this true: “Zero trust is for enterprise IT, not embedded medical devices.”?
No. Zero trust principles, verify explicitly, least privilege, assume breach, apply directly to device fleets: per-device identity, mTLS for service traffic, continuous attestation, and revocable short-lived credentials. NIST SP 800-207 and the DHS CISA Zero Trust Maturity Model both extend to OT and IoMT. Devices designed around perimeter trust assume the hospital network is safe, which it isn't, and have no defense once an attacker is inside.
Is this true: “BLE Secure Connections (LE SC) means our pairing is safe.”?
No. LE Secure Connections fixes the math, not the user experience. Just-Works association, missing OOB confirmation, downgrade to legacy pairing, and unauthenticated GATT services all leave BLE medical devices exposed even when 'Secure Connections' is technically enabled. Insulin pumps, hearing aids, and patient monitors with LE SC enabled have still been paired-and-controlled by attackers within radio range due to association-model gaps.
Is this true: “USB-C and Thunderbolt are fine, we lock the OS.”?
No. Thunderbolt and USB4 expose PCIe via DMA. Without IOMMU/Kernel DMA Protection enforced and unsigned-peripheral blocking, an attacker with seconds of physical access can read memory and bypass disk encryption, regardless of OS login state. Bedside and cart-mounted devices are the obvious targets. Thunderclap-class attacks have demonstrated full memory disclosure on locked clinical workstations through a hostile dock or projector.
Is this true: “Secure boot is our hardware root of trust.”?
No. Secure boot verifies the boot chain, but a real hardware root of trust adds device identity, remote attestation, sealed key storage, and rollback protection in immutable hardware (TPM, SE, or RoT IP). Without attestation, hospitals and regulators can't prove a fielded device is running the firmware you shipped. Devices with secure boot but no attestation cannot prove integrity to a relying party, so trust collapses to 'we promise', which fails under postmarket scrutiny.
What is AAMI TIR57?
A technical information report from the Association for the Advancement of Medical Instrumentation that provides guidance on applying security risk management principles to medical devices.
What is CVE (Common Vulnerabilities and Exposures)?
A standardized identifier for publicly known cybersecurity vulnerabilities, used by manufacturers, regulators, and hospitals to track exposure.
What is CVD (Coordinated Vulnerability Disclosure)?
A documented process by which security researchers can report vulnerabilities to a device manufacturer, who then triages, fixes, and discloses them responsibly.
What is IEC 81001-5-1?
International standard specifying activities for secure development of health software and health IT systems, the international counterpart to FDA SPDF expectations.
What is ISO 14971?
The international standard for the application of risk management to medical devices. Cybersecurity hazards must be integrated into the device's risk management file.
What is MDS2?
Manufacturer Disclosure Statement for Medical Device Security, a standardized form hospitals use to evaluate the security posture of devices they procure.
What is Postmarket Surveillance?
Ongoing monitoring of a device's safety and security after it reaches the market, including vulnerability tracking, patch deployment, and reporting.
What is RTA (Refuse to Accept)?
An FDA decision to reject a premarket submission as administratively incomplete. Since October 2023, missing cybersecurity documentation can trigger an RTA.
What is Section 524B?
The provision of the FD&C Act giving the FDA authority to require cybersecurity information, SBOMs, threat models, postmarket plans, in premarket medical device submissions.
What is SPDF (Secure Product Development Framework)?
A security-integrated software development lifecycle expected by the FDA, encompassing threat modeling, secure coding, testing, and vulnerability response from concept to end-of-life.
What is SBOM (Software Bill of Materials)?
A formal, machine-readable inventory of all software components in a medical device, used for vulnerability management and required by FDA premarket submissions since 2023.
What is Threat Modeling?
A structured analysis of how an attacker could compromise a device, used to drive design decisions and security controls. STRIDE and PASTA are common methodologies.