A software flaw inside one medical device can hit an entire device fleet. In U.S. hospitals, that can delay care, block access to equipment, and leave teams dealing with both patient safety risk and cyber risk at once.
If I had to sum up the issue in plain English, it’s this:
- Medical devices often run third-party software
- Many hospitals don’t have a clear list of those components
- Patching is often slow because devices need vendor review and downtime
- Some devices stay in use long after software support ends
- SBOMs, inventory, contracts, and risk tracking are now part of the job
A few numbers show why this matters:
- 75% of more than 200,000 infusion pumps reviewed had known cybersecurity weaknesses
- 83% of medical imaging devices in U.S. healthcare organizations were running outdated operating systems
- After WannaCry in 2017, some imaging and radiology systems went offline because of old Windows components
The article comes down to three main risks:
- Unpatched software
- Hidden third-party dependencies
- End-of-support components that stay in service for years
It also points to what teams should do next:
- Keep a current device inventory
- Link devices to SBOM data
- Match software components to new CVEs
- Use patch review and testing before deployment
- Apply controls like network isolation and MFA when a patch must wait
- Put vendor update terms and notice rules into contracts
- Track every patch, delay, and mitigation in one risk record
FDA now treats device cybersecurity as part of the product lifecycle, not a side task. For many connected devices, manufacturers must provide a postmarket plan, support secure updates, and submit an SBOM. So if you buy, manage, or secure medical devices, the job is simple to define: know what software is inside, know when support ends, and know what you’ll do when a flaw shows up.
That’s the point of the article: software risk in medical devices is not just an IT issue. It can affect care delivery fast, so hospitals and manufacturers need clear visibility, vendor accountability, and a documented response process.
Medical Device Cybersecurity Risk: Key Stats & Action Steps
Case Study: Why FDA Cybersecurity Expectations Are Really QMS Expectations
sbb-itb-535baee
The Main Risks OTS Software Creates for Medical Devices
OTS software creates three main risks: unpatched vulnerabilities, hidden dependencies, and end-of-support exposure. In plain terms, trouble tends to show up in three moments: when software isn't patched, when teams can't see what's inside the stack, and when vendor support stops.
Unpatched Vulnerabilities and Outdated Components
An unpatched operating system or library can turn a medical device into a doorway for malware and lateral movement. The FDA has warned that networked medical devices that use OTS software are open to threats like viruses and worms, and that unauthorized access to a device or network is itself a cybersecurity vulnerability.[16]
The 2017 WannaCry ransomware outbreak made that risk impossible to ignore. The attack used EternalBlue, a known flaw in Windows SMB that had already been patched for supported systems. Medical devices from vendors including Bayer Medrad and Siemens Healthineers - imaging and radiology equipment running embedded Windows - were directly affected.[14] CT scanners and injection systems went offline. Staff had to fall back on manual workarounds. Diagnostic procedures were delayed.[14][15]
At the center of the problem was unpatched OTS software inside regulated devices, where patching is often slow, tied to the vendor, and may require validation before deployment.[5][2][12][13]
The issue gets even tougher when the weak component is buried inside shared third-party code.
Hidden Third-Party Dependencies and healthcare supply chain security challenges
A single vulnerable library can sit quietly inside dozens of device models from multiple manufacturers. Embedded TCP/IP stacks, cryptographic libraries, and open-source compression components are built into device firmware and are often customized. That makes it hard to tell which version is running - or whether a newly disclosed CVE applies to it.[10][11][4][8]
The FDA has called this out directly. Its cybersecurity alerts for vulnerabilities in the PTC Axeda agent and Axeda Desktop Server showed how one shared software component can ripple across a whole medical device ecosystem.[9] Without visibility at the component level, security teams can't answer basic but urgent questions:
- Which devices use this library?
- Which clinical services depend on those devices?
That blind spot slows threat hunting, risk assessment, and remediation planning.[4][8][15]
When support ends, that same blind spot stops being a short-term problem and becomes a lasting exposure.
End-of-Support Software in Long-Lived Medical Devices
Medical devices often remain in service for 10–15 years or longer.[15] But the OTS software inside them - commercial operating systems, embedded databases, and communication stacks - may hit end of support years before the device itself is retired. Once support ends, new patches stop. New vulnerabilities stay unpatched until the device is finally taken out of service.[15][7]
A radiation therapy system or imaging modality can't be replaced overnight. It takes capital investment, clinical validation, and regulatory review.[5][2][3][9] FDA postmarket guidance recognizes this and recommends structured risk assessments, documented compensating controls, and ongoing risk management instead of assuming hospitals can simply replace unsupported devices.[3][9][7]
That leaves healthcare organizations carrying the residual risk for long stretches of time, often with few practical choices.
Because these risks are often buried deep in the device stack, visibility and governance become the next priority.
What U.S. Healthcare Organizations and Manufacturers Are Expected to Do
FDA and federal law now spell out how manufacturers and healthcare organizations are supposed to handle these risks. FDA treats cybersecurity as part of device quality, not just a box to check before launch. For connected devices with software - FDA's "cyber devices" - security has to be built into design, risk management, production, postmarket surveillance, and end-of-life planning. So the issue isn't whether risk exists. It's how organizations verify it and keep it under control.
FDA Cybersecurity Expectations Across the Device Lifecycle
The legal basis is Section 524B of the FD&C Act, added by the 2023 Consolidated Appropriations Act. Under it, manufacturers must submit a plan for monitoring and addressing postmarket vulnerabilities, show that the device can be updated securely, and provide a software bill of materials (SBOM).[8][25] Since October 1, 2023, FDA may refuse to accept a premarket submission if that documentation is missing.[8][20][22]
For OTS software, FDA expects manufacturers to document:
- which components are included
- which versions are still supported
- how vulnerabilities will be monitored
- what happens when a component reaches end of support[10][2][24]
Healthcare organizations should treat that documentation as a starting requirement during procurement.
SBOMs as the Starting Point for Component Visibility
A software bill of materials (SBOM) is now the main tool for making OTS software visible. FDA guidance says SBOMs must cover commercial, open-source, and off-the-shelf components. Each entry should include the component name, version, manufacturer, support level, end-of-support date, and known vulnerabilities.[1][4][8][6][17][23][24] FDA also calls for machine-readable SBOMs in SPDX, CycloneDX, or SWID formats, such as JSON or XML.[20][21][24]
For healthcare organizations, the manufacturer's SBOM is the baseline for postmarket risk management. It gives clinical engineering and security teams a way to map components to deployed devices, track end-of-support dates, and decide what needs attention when a new CVE is disclosed. That kind of visibility lets teams move before a flaw starts affecting care.
Vendor Risk Management and Contractual Accountability
U.S. healthcare delivery organizations are expected to perform vendor risk management for networked medical devices, including getting cybersecurity commitments in writing.[18][19]
Industry groups have drafted model contract language to make that easier to put into practice. HSCA recommends that purchase agreements require suppliers to warrant that devices are free of known malware or vulnerabilities at delivery, commit to providing security updates at no added cost for the device's full useful life, and state that useful life clearly in the contract.[18] HSCC also recommends contract terms that make suppliers responsible for incident-notification costs in the event of certain cybersecurity incidents.[19]
In practice, a solid contract should lock down a few key points:
- patch service-level expectations
- coordinated vulnerability disclosure timelines
- incident communication requirements
- confirmation that the supplier follows recognized security frameworks such as ISO 27001 or SOC 2[18]
These terms turn vendor promises into requirements that can be enforced after deployment. They also give healthcare organizations a clear basis for patching, disclosure, and compensating controls.
How to Reduce OTS Software Risk in Medical Devices
Once the requirements are clear, the focus moves to day-to-day risk control. This is where teams need visibility, a link to SBOMs, and a way to act on vulnerabilities before they affect care.
Build a Complete Inventory of Devices and Embedded Software Components
Visibility is the first control. Pull CMMS, EHR interface, network discovery, and procurement data into one device inventory. Each record should include the manufacturer, model, serial number, location, owner, network identifiers like IP and MAC addresses, firmware and OS version, and embedded OTS components. That way, teams can quickly find affected devices during patching or incident response.
That inventory also needs to stay current. The best way to do that is to build updates into normal workflows: new device onboarding, firmware upgrades through change management, and device retirement. Store manufacturer SBOMs in a structured repository that teams can query when new CVEs are published. Ownership should be clear across teams: clinical engineering handles the hardware lifecycle, cybersecurity owns vulnerability management, and IT manages network and configuration changes. Set SLAs so records are updated within a defined time after any change.
Inventory by itself doesn't cut risk. It has to connect to SBOMs and vulnerability feeds.
Use SBOM Data to Drive Patch Governance and Compensating Controls
Tie SBOM data to vulnerability intelligence. Normalize SBOMs in SPDX or CycloneDX formats and ingest them into a system that automatically matches component and version pairs against feeds like the NVD and CISA's Known Exploited Vulnerabilities catalog. When a new CVE appears, the system should identify affected devices and rank them by clinical criticality, such as life-support, monitoring, or imaging, plus network exposure and exploitation status.
For patching, replicate device configurations in a lab, validate clinical functions after the patch, and get manufacturer approval when required. If patching can't happen right away because of vendor limits or the risk of disrupting care, use compensating controls instead:
- Isolate devices on dedicated VLANs
- Restrict remote access to secured jump hosts with multi-factor authentication
- Increase log collection and anomaly detection
- Apply application whitelisting where feasible
Document each decision - patched, deferred, or mitigated - in a risk register. Include the vulnerability description, affected assets, clinical and operational impact, risk rating before and after controls, compensating controls applied, decision owners, and a planned remediation timeline. That record supports lifecycle cybersecurity expectations and gives leadership a clear audit trail.
Once those pieces are in place, the next job is getting teams to work from the same system.
Centralize Third-Party and Enterprise Risk Workflows with Censinet
Censinet RiskOps™ brings SBOMs, vendor assessments, vulnerability tracking, and remediation workflows into one place. For healthcare teams, that means less time chasing spreadsheets and email and more time tracking owners, evidence, and risk decisions in one system. It also scores vendor cybersecurity maturity across the portfolio and compares patch practices with contractual commitments.
AI-assisted review can help speed up document analysis. Still, analysts and clinical engineering teams should make the final risk decision.
Conclusion: Manage Device Software Risk Before It Affects Clinical Operations
OTS software is useful, but it comes with risk. It can bring in unpatched vulnerabilities, hidden dependencies, and end-of-support exposure that can disrupt care.
That risk isn't just hypothetical. WannaCry showed how fast a software flaw can turn into a care disruption event.
Now that lesson is part of a formal regulatory framework. FDA treats device cybersecurity as a lifecycle obligation, and the sheer volume of disclosed vulnerabilities makes reactive management hard to keep up with. Healthcare organizations need full inventories, SBOM-linked vulnerability intelligence, third-party vendor risk management, and documented remediation workflows.
The goal is control, not perfection. If patching can't happen right away, compensating controls can buy time. If vendor support ends, documented risk decisions and contract commitments help define the next step. Teams also need one place to take action on that visibility. Censinet RiskOps™ centralizes third-party and enterprise risk assessments, evidence, and remediation workflows so device software risk is managed in a consistent way across teams. Know what's in each device, track its support status, hold vendors accountable, and act before software risk reaches the bedside.
FAQs
What counts as OTS software in a medical device?
Off-the-shelf (OTS) software refers to external code or prebuilt software components used in a medical device that the manufacturer usually does not fully control throughout the software life cycle.
Under FDA requirements, OTS software is treated as a subset of third-party software. Since source code is often unavailable, manufacturers need to validate it through audits or black-box testing. They also need to include it in the device’s SBOM to support transparency and cybersecurity risk management.
How can hospitals know which devices are affected by a new CVE?
Hospitals can spot affected devices by using a Software Bill of Materials (SBOM) for each medical device in a machine-readable format like SPDX or CycloneDX.
From there, automated tools can check those SBOMs against trusted sources such as the NVD and the CISA KEV catalog to flag devices that include vulnerable components. VEX statements then help teams figure out whether a given CVE is actually reachable and exploitable in that device’s setup.
What should a hospital do if a device cannot be patched right away?
If a medical device can’t be patched right away, hospitals should put compensating controls in place to cut risk until there’s a permanent fix or a migration plan.
That might mean network segmentation, firewall rules for virtual patching, tighter access restrictions, or anomaly detection. The goal is simple: reduce exposure now, not months later.
Hospitals should also record these steps in the risk management file. That includes the reason for any accepted residual risk. It also helps to work closely with manufacturers to track remediation and keep patient safety front and center.
