The story most boards heard about medical device security in 2026 was an external one: cyberattacks against the manufacturers themselves. Stryker, Intuitive Surgical, and Medtronic all disclosed incidents within roughly six weeks earlier this spring. Those events matter. They are also not the only story.
RunSafe Security's 2026 Medical Device Cybersecurity Index, released April 29, surveyed 551 healthcare professionals across the United States, United Kingdom, and Germany. Its findings describe what is happening on the inside of healthcare environments — the installed base of clinical hardware already running, already vulnerable, already in service. The headline numbers, reported by Infosecurity Magazine, Industrial Cyber, and Silicon Republic, among others:
- 24% of organizations experienced a cyberattack targeting medical devices in the past year (up from 22% in 2025)
- 80% of those incidents caused moderate-to-significant impact on patient care (up from 75% in 2025)
- 44% acknowledge running devices with known, unpatched vulnerabilities
- 28% operate devices past end-of-support
The trend lines on each metric are wrong direction or flat. Awareness is no longer the gap. Action is.
What "Patient Care Impact" Actually Looks Like
The 80% patient impact number is easy to skim past as a survey statistic. The underlying outcomes are not abstract.
Across the reporting, respondents described delayed imaging exams, postponed surgical procedures, disrupted critical care delivery, and compromised patient monitoring during incidents. When a CT scanner cannot scan, when an infusion pump cannot infuse, when a patient monitor cannot transmit telemetry to a central station — the harm is not data exposure. It is a patient waiting, sometimes a patient missing a clinical window, occasionally a patient experiencing a different outcome than they would have without the disruption.
This is a meaningful framing shift. The conversation about medical device security has, for years, been dominated by the question of whether attackers could harm a patient directly by manipulating a device. That remains the worst-case scenario. But the day-to-day clinical impact of medical device cyber incidents is overwhelmingly about availability — devices being offline, slow, segregated for forensics, or operating on degraded modes — not about manipulated outputs. The harm is operational continuity translated into clinical workflow.
The Installed Base Problem
The two numbers that should drive board conversations are the ones healthcare organizations report about themselves.
44% are running end-of-support clinical devices with known, unpatched vulnerabilities. Not running EOL devices generally — running EOL devices that have published, known security weaknesses. The organizations responding to this survey are aware these devices are vulnerable. They are running them anyway.
28% are operating devices past end-of-support entirely.
This is not negligence. The mechanics are well-understood by anyone who has worked inside a hospital security program:
- Many medical devices require FDA validation for software changes, and that validation is owned by the manufacturer, not the hospital. If the manufacturer has not validated a patch, the hospital cannot apply it without potentially affecting clearance status.
- Devices in active clinical use often cannot be taken offline for patching during operational hours, and many environments do not have a routine downtime window for clinical hardware.
- Replacement cycles for capital medical equipment run 7 to 15 years. A device purchased in 2018 was not designed to a 2026 threat model. It also cannot simply be retired when budget cycles run on a different rhythm.
- A meaningful fraction of installed clinical hardware is past the manufacturer's support window entirely, with no patches available at any cost.
The result is a structural debt problem, not a discipline problem. The vulnerabilities exist because the installed base predates the controls now considered standard, and because the FDA validation, vendor support, and capital replacement cycles do not align with the speed of the threat environment.
The Procurement Counter-Signal
Where the report shows real progress is in the buying conversation.
- 56% of respondents reported rejecting a device at procurement on cybersecurity grounds — up from 46% in 2025
- 84% include cybersecurity requirements in vendor RFPs — 43% with detailed specifications, up from 38%
- 81% rate Software Bill of Materials (SBOM) as "important" or "essential" — and 35% will not consider a device without one
- 76% would pay a premium for advanced runtime protection
- 82% have deployed or are piloting runtime exploit protection
This is meaningful. It changes the trajectory of what gets purchased going forward. It will, over years, change the composition of the installed base.
It does very little for what is already on the floor.
For health system CISOs, this creates a two-track problem. The future-state track is procurement discipline — getting cybersecurity requirements into RFPs, demanding SBOMs, paying for runtime protection where available, and saying no to vendors who cannot meet the bar. The current-state track is installed-base management — risk-rating the devices already in service, identifying which are end-of-support, mapping which clinical services depend on which devices, and building compensating controls and contingency plans for the ones that cannot be patched, replaced, or retired in the near term.
Procurement discipline alone does not address the present. The installed base is what attackers are pricing in.
Where Attacks Are Landing
According to RunSafe's data, the systems most commonly affected in reported incidents:
| System Category | Share of Affected Organizations |
|---|---|
| Electronic health record systems | 35% |
| Patient monitoring devices | 23% |
| Laboratory and diagnostic equipment | 18% |
| Networked surgical equipment | 10% |
| Imaging systems | 8% |
The attack methods reflect the same pragmatism. Malware infections (48%) and network intrusions (41%) still account for the majority of incidents, but remote access exploitation has emerged as a major vector at 38%. The remote access trend is consistent with the broader 2025-2026 pattern of attackers prioritizing edge infrastructure compromise — Citrix NetScaler, F5 BIG-IP, VPN concentrators — as a cheaper path into operational environments than full network intrusion.
The AI Layer
The report also captures an emerging risk that is moving faster than the controls around it. 57% of surveyed organizations have adopted AI-enabled or AI-assisted medical systems, and 80% of those organizations report moderate-to-high concern about cybersecurity risks associated with those AI components. Adoption is outpacing risk mitigation.
This is the same pattern documented in the Mindgard / Doctronic findings two weeks ago. Clinical AI is being adopted faster than the governance and assurance infrastructure around it can mature. RunSafe's data is one more independent signal of the same gap.
What Healthcare Leaders Should Do Now
1. Inventory Before Anything Else
You cannot manage what is not enumerated. The first concrete action is a current, accurate inventory of every networked clinical device — by manufacturer, model, firmware version, support status, network segment, and the clinical service that depends on it. Most health systems have an asset inventory. Most do not have one that maps cleanly from device to clinical workflow.
If you cannot answer the question "which devices in our environment are end-of-support today, and which clinical services depend on them" in less than a day, that is the first work.
2. Risk-Rate the Installed Base, Not Just the Threats
Standard vulnerability management programs prioritize patching by CVSS score and exploitation likelihood. Clinical device risk requires a third dimension: clinical dependency. A medium-severity vulnerability on a device that supports an active surgical service line may carry more operational risk than a critical-severity vulnerability on a peripheral monitoring device with redundant alternatives.
The output is not a CVSS-ordered list. It is a clinical-dependency-weighted register that the COO and CMO can read alongside the CISO.
3. Make Procurement Discipline Permanent, Not Aspirational
The 56% rejection rate is encouraging. Make sure your organization is in that 56%, in writing. RFP language should require cybersecurity attestations, SBOMs in standardized formats (SPDX or CycloneDX), defined patch and end-of-support timelines from the manufacturer, and contractual incident notification commitments. Where vendors will not meet the bar, the answer should be no.
4. Treat End-of-Support as a Boardroom Issue
EOL clinical hardware is not a security problem. It is a capital planning problem with security consequences. Surface it at the level where capital decisions are actually made. Quantify the operational risk of running a specific class of device past end-of-support, the cost of replacement, and the alternative options (segmentation, compensating controls, contractual extensions). Make leadership the decision-maker — not the security team holding a spreadsheet of risks no one is choosing to fund.
5. Pre-Stage the Clinical-Operations Response
When a medical device incident lands, the first hour is the difference between coordinated response and confusion. Have a pre-agreed playbook with clinical operations: which services degrade first, what the manual workarounds are, who notifies attending physicians, who manages family and patient communications. This is not a security tabletop. It is a joint clinical-and-security operational rehearsal.
The Bottom Line
The medtech industry is improving on the procurement side. Health systems are demanding more, and manufacturers are responding. That is real progress for the next decade of installed clinical hardware.
The security debt sitting on hospital floors today is what attackers are pricing in. Forty-four percent of the organizations surveyed know they are running devices with unpatched, known vulnerabilities. Eighty percent of recent incidents caused real impact on real patients.
The right question for a health system board is not whether the organization is "secure." It is narrower and more answerable: which clinical devices in our environment are unpatched or out of support, what services depend on them, and what is our specific plan for each one before the next attack lands?
If those answers are not on a page somewhere right now, that is the work.
Jackal Group delivers daily threat intelligence and custom security policy documentation built for healthcare organizations navigating clinical device risk, vendor concentration, and operational resilience. Read this week's brief or contact us to discuss your installed-base posture.