The Bedside Is A New Attack Surface: Securing Medical Devices In The Age Of AI
Dan Sorensen is a fractional vCISO & AI governance leader. 22+ year U.S. Air Force and Air National Guard veteran.
gettyWhen a ransomware crew hits a hospital, headlines usually focus on stolen records. From what I’ve seen, the scarier story is at the bedside: the infusion pump, the patient monitor, the imaging system and now the AI model reading the scan. Those devices don’t just hold data; they help make clinical decisions. And more of them are connected, software-driven and “smart” than ever before.
I’ve spent a lot of time around incident response, and I’d argue medical device security has become one of the most consequential corners of cybersecurity. Here’s why, and what leaders can do about it.
The numbers are pretty sobering indeed. Just look at this: Claroty’s 2025 report examined more than 2.5 million Internet of Medical Things (IoMT) devices across 351 healthcare organizations. It found that 89% of those organizations had internet-exposed medical devices with vulnerabilities known to be exploited in active ransomware campaigns. Ninety-nine percent had at least some IoMT devices with known exploited vulnerabilities.
This isn’t theoretical. In January 2025, the Cybersecurity and Infrastructure Security Agency (CISA) and the FDA warned that Contec CMS8000 patient monitors contained hidden functionality. The monitors reached out to a hard-coded IP address, allowing remote files to be downloaded and run. Researchers later debated whether it was a deliberate “backdoor” or just an insecure design. Well, for a hospital with that monitor on its network, the distinction is somewhat academic; the risk is the same.
Now layer artificial intelligence on top. The FDA’s list of AI-enabled medical devices has grown past a thousand authorized products, most of them in radiology. These tools are very promising, but they bring threats that traditional device security programs weren’t built to catch.
The FDA said as much in its January 2025 draft guidance on AI-enabled device software functions. According to Hunton Andrews Kurth, the agency specifically calls out:
• Data poisoning: tampering with the data a model learns from.
• Model inversion and theft: rebuilding the training data, or copying the model, from what it outputs.
• Model evasion: specially crafted inputs that fool the model.
• Data leakage: sensitive data slipping out through the model’s outputs.
• Performance drift: caused by manipulating the underlying data.
Each OWASP AI Exchange page explains the threat and the controls to counter it. NIST’s Adversarial Machine Learning taxonomy (NIST AI 100-2) is a good companion.
In plain terms, an attacker may not need to “break” the device at all. They could quietly degrade the model so it misses a tumor or flags the wrong patient, and nobody notices for months.
That’s a pretty different problem than just patching a buffer overflow, wouldn’t you say?
The good news is that the regulatory floor has moved. Section 524B of the Federal Food, Drug and Cosmetic Act now requires manufacturers of “cyber devices” to do three things:
• Submit a plan to monitor and address vulnerabilities.
• Provide a software bill of materials (SBOM).
An SBOM is essentially an ingredients list of the software components inside a device, including commercial, open-source and off-the-shelf software.
In June 2025, the FDA finalized updated guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions. It spells out the documentation the agency expects for those obligations, including for changes to devices already on the market.
But manufacturer compliance doesn’t automatically mean security at the hospital level. Many devices stay in service for 10 to 15 years, often long after vendor support ends. And the SBOM only helps if someone at the hospital actually reads it.
1. Know what you have. Keep a real-time inventory of connected medical devices, including firmware versions, network exposure and the AI models built into them. You can’t protect (or “own the risk” for) a device you don’t know exists.
2. Segment ruthlessly. Most medical devices have no business talking to the internet. Network segmentation and outbound traffic controls would have blunted much of the Contec exposure.
3. Make SBOMs and AI documentation part of procurement. Ask vendors for their SBOM, their vulnerability disclosure process, their patch commitments and, for AI-enabled devices, how they validate training data and monitor model performance after deployment.
4. Treat AI models as assets with their own threat model. The OWASP AI Exchange and the NIST AI Risk Management Framework offer practical controls for poisoning, evasion and model theft. Use them alongside your existing device security program, not instead of it.
5. Bring clinical engineering, IT security and clinicians to the same table. Biomedical engineering often owns the device, IT owns the network and clinicians own the outcome. Incident response plans need all three, and they need practice before the bad day, not during it.
Medical device security used to be a niche concern for biomed teams. Now connected devices are everywhere and AI increasingly shapes diagnosis and treatment, so it’s a patient safety issue and a board-level risk. Regulators have set expectations for manufacturers; healthcare leaders must close the operational gap.
Have the plan in place, then work the plan. Our patients are counting on it.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
