New analysis from MITRE warned that rapid integration of emerging technologies into medical devices is reshaping the cybersecurity risk landscape in ways that traditional controls are not equipped to handle. In a newly released analysis, the non-profit organization finds that innovations such as cloud computing, AI (artificial intelligence) and machine learning, and post-quantum cryptography introduce distinct and evolving attack surfaces that can directly affect device functionality and, in worst cases, patient safety.
Titled ‘Cybersecurity Risk Analysis for Medical Devices in the Era of Evolving Technologies,’ the discussion paper draws on interviews with manufacturers, healthcare providers, regulators, and security vendors to map these risks and identify mitigation practices, underscoring that cybersecurity must now be treated as a core design consideration rather than an afterthought. At the same time, it highlights how the operational context of medical devices is shifting beyond controlled clinical environments into homes and patient-managed settings, complicating risk ownership and oversight.
Devices now span everything from implantables to large hospital systems, often constrained by limited computing resources, long lifecycles, and legacy software, while also being increasingly interconnected with other devices and health IT systems. This expanding ecosystem introduces dependencies on third parties and blurs accountability, reinforcing MITRE’s conclusion that cybersecurity risk management is becoming a shared, multi-stakeholder responsibility that must adapt to distributed care models and continuously evolving technologies.
Medical device manufacturers introduce cybersecurity risk across a remarkably diverse landscape, from implantable pacemakers and portable infusion pumps to large integrated hospital systems like MRIs and CT scanners, with many devices constrained by limited power, memory, and processing capacity that restrict the cybersecurity controls available to them, while large devices often run outdated hardware and software due to their long operational lifetimes. Most devices also interface with other medical products and health IT systems, compounding that risk further.
The challenge is made more complex by a shifting deployment environment: devices that once sat within tightly managed hospital settings are increasingly used in ambulatory and home environments, managed by patients themselves through connected apps and wearable devices, reducing oversight and control that healthcare delivery organization staff can realistically exercise.
“To accommodate those changes, risk management paradigms for evolving technologies, such as cloud services and AI/ML, will account for medical devices and components that may be located outside of a healthcare facility and managed by third parties,” MITRE detailed in its paper. “Cybersecurity risk management of medical devices has always been a shared responsibility between MDMs and HDOs, but now additional third parties are accounted for when defining roles and responsibilities.”
It also noted that a key consideration is designing devices and putting processes and frameworks in place to prevent devices from becoming devices that cannot be reasonably protected against current cybersecurity threats, such that they are not cybersecure. Medical devices and their systems can evolve through hardware and software upgrades over the lifetime of the device, so they can continue to be used safely. Threat modeling early in design and development can lead to robust, evolvable designs and threat models with appropriate mitigations. These practices, in turn, can help ensure that vulnerabilities discovered in the post-market are more likely to be controlled, or if uncontrolled, facilitate rapid remediation.
MDMs adopting cloud computing face significant cybersecurity challenges across two areas of acquisition and deployment, and software development. While cloud services reduce costs and improve efficiency, they shift control away from both MDMs and healthcare delivery organizations, introducing third-party risks that are not always fully understood or regulated. Cloud service providers can create systemic vulnerabilities, and if those services become unavailable, patient care can be directly disrupted.
Role boundaries are also changing, as MDMs increasingly become partial operators of their own devices, complicating responsibilities around penetration testing, vulnerability management, and compliance across different global regulatory regimes. Contingency planning and robust supplier controls, such as those outlined in ISO 13485:2016, are essential to managing these risks.
On the software development side, MDMs are shifting from cloud-hosted to cloud-native solutions to gain performance, scalability, and resilience benefits, but this requires new development skills, DevSecOps practices, and secure CI/CD pipelines. The threat landscape across both areas is serious. Adversaries can attack cloud services at any point in a device’s lifecycle: tainting machine learning training data to cause misdiagnosis, rendering devices unavailable through ransomware, or corrupting code and data to cause treatment errors.
Crucially, the blast radius of these attacks is wide, covering a single cloud service compromise that can simultaneously impact devices across hundreds of facilities, as demonstrated by the ransomware attack on Elekta’s cloud services, which disrupted cancer treatment at more than 170 sites.
MITRE outlined that mitigations for cloud-based medical device cybersecurity risks span three areas. On policies and processes, MDMs should clearly define roles and responsibilities based on their chosen cloud service model, using Service Level Agreements and contracting language with both HDOs and cloud service providers to set security expectations, availability requirements, and supplier accountability — drawing on frameworks such as ISO 13485:2016 and NIST cloud security guidance. DevSecOps practices tailored to cloud-native development, including secure CI/CD pipelines and container and orchestration security, should be embedded throughout the product lifecycle.
On resilient architecture and design, MDMs should extend existing secure development processes to cloud environments, incorporating cloud components into Software Bills of Materials (SBOMs) and threat models, mapping trust boundaries across the full cloud technology stack, and leveraging resources such as MITRE ATT&CK’s cloud matrices, OWASP cheat sheets, and CSP-native security tooling to identify and mitigate threats specific to IaaS and SaaS service models.
On preparedness and response, MDMs should not assume cloud infrastructure resilience is sufficient on its own, as systems should be provisioned across multiple geographic regions with regulatory requirements in mind, and device architectures should support local caching and offline operation modes, alongside geographically distributed backups, to maintain care continuity and enable recovery in the event of a cloud-targeted cyberattack.
Incorporating AI/ML into medical devices introduces a distinct and serious set of cybersecurity risks that span the entire device lifecycle. Attacks can occur during algorithm development, such as poisoning training data to produce incorrect outputs, or during operational use through adversarial inputs or prompt injections, with consequences ranging from misdiagnosis and improper treatment to patient privacy violations under HIPAA, including membership inference attacks that can expose whether individuals were part of training datasets.
Even devices that don’t use AI/ML in their core functionality may be at risk if their software was developed with AI-generated code, which can introduce unusual bugs that are harder to detect and diagnose than those found in traditional human-written code. Moreover, the integrity of data across every stage of the AI/ML lifecycle, raw data, training data, validation data, model weights, prompts, and sub-system inputs, is critical, as any compromise to that data chain can undermine the trustworthiness of the entire system. Finally, because AI/ML is ultimately implemented in software, it remains vulnerable to the same coding errors and design flaws as any other software, giving attackers additional vectors to compromise the availability, integrity, and confidentiality of AI-enabled medical devices.
Medical device manufacturers adopting AI/ML face several interconnected challenges. The stochastic, non-deterministic nature of AI/ML means outputs can vary even with identical inputs, a fundamental departure from traditional software, creating safety risks such as hallucinations in generative AI that could lead to misdiagnosis, and making conventional debugging and code analysis techniques insufficient for understanding or predicting failures.
Emerging defenses such as guardrails and Retrieval Augmented Generation offer some protection but remain immature, with no reliable guarantees of effectiveness. The choice between adaptive and locked operational modes introduces further tradeoffs: adaptive mode enables continuous learning but increases exposure to data poisoning and may skip critical validation steps, while locked mode offers more predictability and versioning but is slower to update.
Where AI/ML capabilities require cloud infrastructure, particularly for resource-constrained devices like wearables, MDMs inherit associated cloud availability and cybersecurity risks. Finally, even where AI/ML shows clinical promise, adoption can be slowed by clinician skepticism toward unpredictable systems, resource intensity, and uncertainty about real-world benefit to patient safety.
To mitigate the cybersecurity risks of integrating AI/ML into medical devices, MDMs should focus on several key areas. First, securing the learning environment is foundational, with training data, parameters, models, prompts, and associated systems that must be protected against tampering, with clear separation between training and test datasets to prevent data poisoning.
Second, guardrails and robust testing mechanisms should be implemented to constrain unpredictable AI/ML behavior, supplemented by techniques such as Retrieval Augmented Generation, prompt engineering, and hyperparameter configuration, alongside targeted automated testing and manual red teaming by subject matter experts who can probe system-specific vulnerabilities that automation may miss.
Third, AI/ML security should be fully embedded within the broader software security program through threat modeling of AI/ML components, least-privilege access controls, trust boundary enforcement, particularly around cloud-based or third-party AI components, and integrity validation of outputs, given that AI/ML results may not conform to well-defined specifications as traditional software would.
Finally, during the acquisition of any AI/ML components, MDMs should conduct diligent risk and liability analysis, accounting for cybersecurity risk and the potential consequences of AI/ML failure on patient safety, product correctness, and data confidentiality.
In its discussion paper, MITRE noted that MDMs and healthcare organizations should begin planning their transition to post-quantum cryptography (PQC) to address the threat that quantum computing poses to current encryption and digital signature algorithms. While PQC alternatives exist for both confidentiality and authentication applications, the migration away from widely used legacy cryptography is complex and will require significant time and coordination, given the interconnected nature of medical devices and healthcare systems.
Organizations face two distinct but related goals: securing the devices and systems they build against quantum threats by addressing technical cryptographic vulnerabilities directly, and developing a broader organizational strategy to protect their own operations and patients across cryptographic systems they use, including those they do not develop or control, while maintaining ability to deliver safe and effective care throughout the transition.
Transitioning to post-quantum cryptography in medical devices presents three interconnected technical challenges. First, PQC algorithms, while not dramatically slower, demand more memory, code, processing power, and longer message sizes, translating into additional hardware requirements and costs.
Second, interoperability with legacy devices remains a persistent vulnerability, as new PQC-enabled devices will inevitably interface with older systems that lack post-quantum controls, requiring endpoints to handle multiple cryptographic standards simultaneously and increasing system complexity, while the quantum risk remains unresolved for as long as legacy systems exist.
Third, transition timelines will vary widely depending on engineering constraints, financial considerations, legal mandates, device lifespan, and the feasibility of updating versus replacing existing devices, with extreme cases such as implantable devices presenting particular challenges, where altering cryptography may require a medical procedure that would only be justified if it served the patient’s broader clinical interests.
In conclusion, MITRE recognizes that emerging and evolving technologies promise advances in patient care, but at the same time introduce new cybersecurity risks. “Managing these risks doesn’t necessitate an entirely new approach but builds upon existing practices. Safeguarding medical devices against the threat of quantum cryptographic attacks and cyberattacks against cloud infrastructure and AI/ML algorithms used by the devices can be achieved by considering how to incrementally adapt processes, such as using SBOMs to manage vulnerabilities and creating threat models, to include cloud, AI/ML, and cryptographic components. Governance is central to managing cybersecurity risk.”
The paper added that the frameworks and architectures lead to rethinking roles and responsibilities. When acquiring systems with these new technologies, contracting language and cloud SLAs can clarify the cybersecurity expectations of the various parties. Planning and roadmaps for adoption and migration can be developed to ensure a smooth transition. The only constant is change, as technology will continue to evolve. It is important to develop medical devices that can be updated so they can continue to provide needed care without becoming vulnerable and introducing threats to patients and the environments in which they are used.
