AI Cybersecurity

AI and Cybersecurity in Medical Devices: A Multi-Dimensional Challenge

Introduction

If you’re developing for medical devices in 2026, you’re dealing with AI whether you planned to or not. AI tools are changing how code gets written, what features get built into devices, and what kinds of attacks those devices face.

AI coding assistants speed up code generation but pull in dependencies or implementations from public repositories, many of them insecure. AI/ML diagnostic algorithms create attack surfaces that didn’t exist five years ago. Threat actors are using AI to write better phishing emails and find vulnerabilities faster.

For manufacturers preparing FDA premarket submissions or EU MDR/IVDR conformity assessments, this creates a compliance problem. The FDA’s guidance on AI in medical devices, the EU AI Act, and AAMI TIR34971 (and soon, ISO 24971-2) explicitly require manufacturers to address AI related cybersecurity risks.

Approach Overview

This article looks at three places where AI intersects with medical device cybersecurity: AI as a development tool introducing supply chain risks, AI enabled device capabilities creating new attack surfaces, and AI augmented threats requiring layered defenses.

AI Assisted Development: Managing New Risks

AI coding assistants can make your development team faster. They’re also trained on public repositories scraped from GitHub, Stack Overflow, and similar sources, meaning they’ve learned from millions of lines of insecure code.

The FDA’s cybersecurity guidance and IEC 81001-5-1 require manufacturers to establish a secure product development framework (SPDF), with the main focus being on cybersecurity risk management.

Key things to consider:

• Security by design – Regulators want to see that your system was designed to be secure, not that cybersecurity was treated as an afterthought.
• Data protection – Cloud based AI services may expose protected health information. If you’re pasting patient data into ChatGPT or Copilot, you’re likely violating HIPAA and other data protection regulations.
• Supply chain security – Use Software Composition Analysis (SCA) tools to vet code and libraries suggested by AI. These tools can identify insecure code and point to deprecated or vulnerable packages.
• Cybersecurity risk management – Teams may need to spend additional effort on code reviews, refactoring, security testing, and risk assessment activities to ensure vulnerabilities or unsafe functionality have not been introduced.

The Software Bill of Materials (SBOM) is now required in FDA software submissions (see the latest version of eSTAR). If your AI assistant imports a library, that library goes in the SBOM, and you’re responsible for monitoring it for obsolescence and vulnerabilities throughout the device lifetime.

AI Enabled Devices: New Attack Surfaces

When you embed AI/ML capabilities in a medical device including diagnostic algorithms, predictive models, or adaptive systems, you create cybersecurity risks that traditional medical devices don’t face. The FDA’s draft guidance on AI-enabled device software functions (AI-DSF) identifies these distinct threats, including:

• Data poisoning – this happens when attackers inject malicious data corrupting the model’s behavior. For example, a 2024 study found that even small amounts of poisoned data injected into a LLM (large language model) resulted in the model generating “coherent but incorrect answers”. 
• Model theft – these are attempts to reverse engineer proprietary AI models through model inversion or extraction attacks. Defenses include differential privacy (adding noise to training data) and model watermarking, but the cybersecurity risk assessment standards require manufacturers to document a benefit-risk analysis i.e., trade-offs between security and model accuracy. Adding noise to improve security can reduce diagnostic accuracy, which creates a patient safety vs security tradeoff that must also be disclosed to regulators and end users.

The FDA’s AI-DSF guidance and EU’s Cyber Resilience Act make it clear that security doesn’t end once the device is on the market. Manufacturers are required to monitor their device’s performance post-market as well as monitor for cybersecurity vulnerabilities . That monitoring effort has a cost most manufacturers underestimate.

AI as a Threat Multiplier

While medical device manufacturers adopt AI to speed up development, attackers use the same technology to improve their success rates.

AI systems are good at finding vulnerabilities. Tools like ChatGPT can analyze codebases, identify weaknesses, and generate working exploits. This narrows the window between vulnerability disclosure and exploitation. Development teams used to have weeks to patch. Now they may have days or hours.

AI generated phishing attacks targeting healthcare personnel have gotten better. Phishing emails used to have obvious tells: grammar errors, generic greetings. AI can generate convincing emails personalized to the target. For devices with remote access capabilities (telehealth platforms, remote monitoring systems), this increases the risk of credential compromise.

Defense requires multiple layers. IEC 81001-5-1 calls this “defense in depth.” You assume one control will fail, so you need several. For medical devices, this typically includes:

• Multi-factor authentication (MFA) for remote access
• Role-based access control (RBAC) limiting what authenticated users can do
• Application whitelisting to block unauthorized executables
• Secure boot to prevent firmware tampering
• Runtime integrity verification to detect unauthorized changes
• Anomaly detection to identify unusual behavior patterns

Zero trust architecture, where no user or device is trusted by default, is becoming standard for connected medical devices. Nobody likes it because it adds friction, but the alternative is worse.

Regulatory Framework and Practical Implementation

The EU AI Act classifies medical AI systems as “high risk”, triggering mandatory cybersecurity requirements: risk management, data governance, technical documentation, and post market monitoring. For FDA premarket submissions, manufacturers must provide risk management files addressing AI specific threats identified in the AI-DSF guidance.

Organizations should implement controls across all three dimensions:

AI assisted development:

• Establish policies on which AI tools are approved for use
• Treat AI generated code as untrusted input requiring validation
• Integrate Software Composition Analysis into CI/CD pipelines
• Maintain a comprehensive SBOM and monitor its components

AI assisted development:

• Conduct threat modeling addressing AI-specific threats (data poisoning, model theft, etc.)
• Establish continuous monitoring for model performance 

Defense against AI enhanced threats:

• Implement defense in depth architecture with multiple layered controls
• Deploy MFA and RBAC for all remote access
• Maintain continuous vulnerability monitoring using automated scanning
• Establish incident response procedures with defined roles and escalation paths

Conclusion

AI changes medical device cybersecurity in three ways: it introduces supply chain risks during development, creates new attack surfaces in device capabilities, and gives attackers better tools.

Manufacturers who adopt secure by design principles and build AI security expertise will have fewer surprises during FDA review/CE conformity assessment. The alternative is addressing these issues reactively, finding problems during premarket submission or after devices ship.

Cybersecurity is a quality attribute, not a feature you add at the end. You either build it in from the start or you pay for it later when someone finds the problem you didn’t catch.