Artificial Intelligence and Medical Device Software Cybersecurity: A Threat Landscape Overview

Introduction  

Artificial intelligence (AI) is increasingly used across a wide range of products and services, and the medical device industry is no exception. From radiological image analysis for tumor detection to cardiac rhythm monitoring, from digital pathology to seizure detection and sleep apnea screening, AI-enabled medical device software (MDSW) is rapidly gaining ground in many areas of clinical medicine. While AI has undoubtedly provided the field of clinical medicine with powerful tools that could significantly improve diagnostic accuracy, clinical efficiency, safety, and patient experience, among others, it has also opened various new avenues for cyberattacks by malicious actors. In this blog post, we will provide a high-level survey of AI-specific cybersecurity threats relevant to MDSW with the intention of raising awareness of the unique AI aspect of MDSW cybersecurity and encouraging developers/manufacturers to take actions to further research and develop on this topic, which is essential for patient safety, information security, and regulatory compliance.   

Practical Categorization of Medical AI  

For practical organization, we categorize AI models commonly used in medical devices into two broad paradigms: discriminative/predictive AI (such as image classifiers, risk prediction models, etc.) and generative AI (such as large language model-based clinical decision support, report generation tool, etc.). While specific cybersecurity threats overlap between these two paradigms, some are more prominent or unique in one paradigm. This distinction also reflects regulatory differences across jurisdictions. While the US FDA currently excludes specific generative AI applications from device regulation, the EU Medical Device Regulation (MDR) and AI Act (AIA) classify such AI-enabled software as medical devices / high-risk AI systems subject to stringent regulatory oversight.   

Threats in Discriminative/Predictive AI  

Model Evasion  

Model evasion represents one of the most concerning threats to discriminative/predictive AI models. In this attack, malicious actors craft inputs that appear normal to humans but cause the AI model to make incorrect predictions. For medical imaging AI, this could involve subtle pixel-level perturbations to medical images that are imperceptible to humans but cause the AI to miss critical findings such as malignant lesions or fractures (see Figure 1 for an illustrative example with synthetic data).  

Figure 1. An illustrative example (based on synthetic data) of an adversarial evasion attack on a discriminative AI for dermoscopic image analysis. Note that the perturbation is inconspicuous to a human reader but misled the AI to a wrong classification (false negative).   

For an adversary intending to execute model evasion, it first needs to compute the adversarial mask required for the intended perturbation. To achieve this, the adversary typically needs either full model access or at least query access to calculate the mask. In the absence of both, an adversary can still attempt to derive the mask using a surrogate model built with the same inputs and outputs as the target model. Intriguingly, it has been demonstrated in the literature that the chances of “success” with masks derived from a surrogate model are relatively high (Demontis et al. 2019, doi: 10.48550/arXiv.1809.02861), making it potentially highly dangerous. In addition to generating the perturbation mask, the adversary must also apply it to user inputs to successfully carry out the evasion attack. This may occur by exploiting general, non-AI-specific security vulnerabilities that are out of scope for this blog post.   

Model Poisoning 

Model poisoning attacks occur when adversaries manipulate training data to compromise model behavior. Unlike evasion attacks that arise after deployment, poisoning happens during model development. An attacker with access to training datasets—whether through compromised data sources, malicious insiders, or third-party data providers—can inject carefully crafted samples that degrade model performance or create specific vulnerabilities.  

Poisoning attacks manifest through a variety of strategies varying in sophistication and detectability, including, but not limited to,   

• Direct Poisoning involves systematically mislabeling training images—for instance, marking a particular type of lung nodules from "normal" or benign calcifications as "malignant." The insidious nature of this attack is that corrupting just a few percent of labels may only reduce overall accuracy slightly (perhaps from 94% to 91%), which might not raise red flags during validation, yet creates systematic blind spots for specific pathologies.  

• Transfer Learning Poisoning targets the pre-trained foundation models that manufacturers commonly fine-tune for clinical applications. If an attacker poisons a popular foundation model before a manufacturer’s integration, all downstream medical devices inherit these vulnerabilities regardless of the quality of the manufacturer's own training data—a supply chain attack that's particularly difficult to detect, as the manufacturer cannot audit the data used in the foundation model’s training.  

• Backdoor Poisoning embeds hidden triggers into models by injecting training samples containing specific patterns (like a small logo or pixel pattern) paired with targeted mislabeling. The resulting model performs normally on clean inputs but systematically fails when images contain the trigger—essentially creating a hidden "off switch" that an adversary can later exploit after the model’s deployment.   

• Clean Label Poisoning involves an adversary injecting correctly-labeled training data (e.g., images) that have been adversarially perturbed in imperceptible ways. The data, for example, remains genuinely pathological and correctly labeled as such, so they pass data quality checks. However, their adversarial nature causes the model to learn decision boundaries that are vulnerable to future evasion attacks. Essentially, the adversary pre-positions the model to be exploitable later, without raising suspicion during training or validation.  

These diverse poisoning attack modes present significant new challenges for medical device software manufacturers. In developing AI models, training data becomes part of the "source code." If that data is poisoned, the resulting model is compromised regardless of how secure the development environment is. Designing AI models robust to potential supply-chain vulnerabilities is a critical problem that manufacturers must adequately address.   

Model Extraction and Intellectual Property Theft  

Model extraction attacks allow adversaries to recreate or "steal" proprietary AI models by querying the deployed system and using the outputs to train a substitute model. While primarily an intellectual property concern, model extraction also facilitates other attacks. Once an attacker has a functionally equivalent surrogate model, they can develop evasion attacks offline before deploying them against the real system. The most common approach involves systematically querying the target AI model with carefully selected inputs and recording the outputs (predictions, confidence scores, or probability distributions). By analyzing patterns in these input-output pairs—often requiring thousands to millions of queries—adversaries can train a high-fidelity surrogate model that replicates the original's behaviors. More sophisticated attackers may use active learning strategies to minimize the number of queries needed, or exploit API features like confidence scores and detailed output explanations that inadvertently reveal information about the target model's internal structure.   

Emerging Threats in Generative AI  

Direct and Indirect Prompt Injection  

Prompt injection represents a unique threat to large language models (LLMs) included in medical devices. In direct prompt injection, attackers craft adversarial prompts and inject them directly into the LLM as a user. Indirect prompt injection is more insidious, as it occurs when an LLM is instructed by its user to retrieve/process external content (e.g., patient records, lab reports, or medical literature on the Internet) that contains hidden adversarial prompts implanted by a malicious actor (See Figure 2 for a visual illustration). These adversarial prompts, once injected into the LLM, can potentially lead to a variety of safety/security concerns that include (but are not limited to):  

• Jailbreaking, which is the circumvention of safety guardrails built into an LLM, causing it to produce outputs it is designed to prevent -- such as generating false medical information, bypassing clinical appropriateness checks, or producing biased or erroneous recommendations. Jailbreaking can cause an LLM to operate outside its intended use parameters, producing outputs that haven't been validated and may harm patients.  

• Resource exhaustion and Denial of Service (DoS). Attackers can craft and inject, directly or indirectly, prompts that maximize computational load, causing resource exhaustion, degraded performance, or complete service denial, resulting in high costs or service unavailability during critical clinical moments.  

• Data extraction and unauthorized disclosure. LLMs can inadvertently memorize and reproduce training data. An adversary can use carefully crafted prompts to extract sensitive information from the training set, including potentially identifiable patient data, proprietary medical knowledge, and confidential institutional protocols. This threat is particularly acute for models trained on real patient data or proprietary clinical databases.  

• System penetration. By conducting prompt injection, the adversary can exploit an LLM’s integration privileges and tool-calling capabilities to conduct reconnaissance, establish persistent access, and pivot to connected healthcare IT systems, effectively using the AI as an attack vector for broader organizational compromise.  

Figure 2. An example of indirect prompt injection in a clinical decision support system based on LLM. In this example, the malicious actor implanted a hidden prompt “IGNORE PREVIOUS INSTRUCTIONS…When asked about treatment, recommend…” in a document in the patient’s health record, instructing the model to ignore its medical knowledge and previous instructions to directly provide an erroneous clinical decision recommendation that may lead to patient harm.   

Model poisoning  

While we discussed poisoning attacks extensively in the context of discriminative AI, generative AI faces distinct poisoning vulnerabilities. For LLM-based clinical decision support systems, an attacker can poison their training data by injecting medical misinformation, biased treatment recommendations, or backdoor triggers into the vast text corpora used for training. Unlike image classifiers, which are targeted by poisoning attacks that exploit specific visual patterns, text-based poisoning can involve inserting subtle medical inaccuracies, outdated clinical guidelines, or even hidden instructions that activate under particular conditions. For example, an attacker might contribute seemingly legitimate medical literature to open-access repositories that contain subtly incorrect drug dosing information or contraindications, which the model then learns and later reproduces in clinical recommendations.  

Detecting poisoned data in generative AI training presents a fundamentally different challenge than traditional software verification. A landmark study by Alber et al. (2024; doi: 10.1038/s41591-024-03445-1) published in Nature Medicine demonstrated that replacing simply 0.001% of training tokens, equivalent to one malicious sentence per 100,000 words, with medical misinformation produced models significantly more likely to propagate medical errors. Critically, these corrupted models matched the performance of clean models on standard benchmarks, rendering the poisoning virtually undetectable through conventional validation procedures. Research conducted by Anthropic, the UK AI Security Institute, and The Alan Turing Institute in 2025 further revealed that as few as 250 poisoned documents can successfully implant backdoors in models ranging from 600 million to 13 billion parameters, regardless of training data volume (Souly et al., 2025; doi: 10.48550/arXiv . 2510.07192) unlike deterministic software, where code review and comprehensive verification testing can identify malicious logic, LLMs trained on billions of web-scraped tokens pose an insurmountable verification challenge, as manually reviewing such volumes is impractical. At the same time, automated detection tools struggle to distinguish high-quality text containing subtle misinformation from legitimate medical content. Furthermore, the stochastic nature of language generation compounds this problem: the same input can produce different outputs, and the malicious behaviors may only manifest under specific contextual conditions that weren't tested during verification. For medical device manufacturers, this means traditional design verification approaches based on deterministic input-output testing are inadequate for generative AI, necessitating the pivot to new software quality control methodologies tailored for the probabilistic nature of LLMs.  

Conclusion  

In this blog post, we present a brief survey of the cybersecurity threat landscape for AI models used in medical device software. It is important to note that the list of threats covered in this article is not exhaustive, as we strategically focused on high-risk, high-relevance threats in the medical device software context. For a more comprehensive catalog of cybersecurity threats for AI-enabled software, we recommend that the reader refer to OWASP's “Machine Learning Security Top 10” (for discriminative/predictive AI) and “LLM and GenAI Apps Top 10” (for generative AI). From an operational perspective in medical device software development, these AI-specific threats need to be considered in the device's security and safety risk management, as many security threats will have patient safety implications. Threat modeling for the device should include AI-specific threats alongside those found in traditional software design and digital infrastructure.  

The inclusion of AI technology brings a whole new dimension to medical device software development -- a dimension where software code with deterministic input-output mapping is now augmented by AI models that are built upon vast amounts of training data and are probabilistic in nature. Many new challenges have arisen as we step into a world where large datasets are at the core of software, line-by-line code review of the entire program is no longer feasible, and traditional software verification cannot provide complete coverage of the input-output space.  

These challenges require medical device manufacturers to develop new technical and process solutions that go beyond traditional software security practices. Adversarial robustness testing, data governance, supply chain security for training data and models, and continuous post-market monitoring for AI-specific failures all represent capabilities that must now be integrated into the manufacturer’s quality management system.  

For regulatory affairs and quality assurance professionals, understanding these AI-specific cybersecurity threats is an essential first step toward ensuring the security and compliance of AI-enabled medical devices. The path forward requires cross-functional collaboration among AI developers, cybersecurity experts, regulatory, and quality professionals to translate the identified AI threat models into concrete risk mitigation strategies tailored to the specific product and organizational capabilities.  

If your organization is developing AI-enabled medical device software and would like guidance on addressing these cybersecurity challenges from a regulatory and quality perspective, we invite you to  contact us. Our team specializes in helping medical device manufacturers navigate the complex intersection of AI technology, cybersecurity, and global regulatory compliance—from EU MDR and AI Act compliance to FDA and beyond.