By Joseph M. Saunders, Founder and CEO, RunSafe Security
A medical device cleared today may stay in clinical service for 15 years or more, but the software inside it does not always age well. New vulnerabilities get discovered, open source components fall out of date, and attack techniques keep improving. Frontier AI tools now make it faster and cheaper to find medical device vulnerabilities and build working exploits at scale, widening the gap between how long a device must run safely and how quickly its makers can respond.
Regulators have stepped in to help address the problem. In June 2025, the FDA finalized updated premarket cybersecurity guidance, and Section 524B of the Federal Food, Drug, and Cosmetic Act now requires makers of cyber devices to demonstrate secure development practices, provide a Software Bill of Materials (SBOM), and monitor vulnerabilities after a device reaches the market.
Those steps matter, but they do not erase the practical limits manufacturers face. Updating a fielded device can be slow, expensive, and disruptive; some updates require revalidation, and others are not operationally feasible. Patching remains necessary, yet it cannot be the only defense. When a device cannot be updated quickly, manufacturers need another way to reduce risk while the vulnerability still exists.
The Patch Gap Is Now a Design Problem
For a hard-to-update device, the time between vulnerability discovery and a validated fix is a period of active exposure. AI is making that exposure more consequential. As discovery and exploit development accelerate, defenders have less time to investigate an issue, confirm whether a device is affected, and build, validate, and distribute a fix.
So a security program has to answer two questions. How quickly can a vulnerability be remediated, and what prevents it from becoming a successful exploit before remediation is complete? Automated vulnerability mitigation answers the second. Rather than removing every flaw, it hardens the software so attackers struggle to turn a vulnerability into a working exploit.
This matters most for devices built in C and C++, where many serious attacks depend on memory corruption and predictable memory layouts. Load-time Function Randomization (LFR) gives each protected device a unique function layout when the software loads, so attackers can no longer assume that functions and code sequences sit in the same locations. This makes it so that attackers can not develop a working exploit.
The vulnerability may still need a fix, but its exploitability drops immediately and at scale, protecting devices while remediation is underway or where a complete patch cycle may never arrive.
Measuring the Risk Reduction
Mitigation also lets manufacturers quantify how much risk they remove rather than assert it. A global manufacturer of patient-care devices wanted to shrink the attack surface of one product and support FDA approval without rewriting or delaying release.
Using the manufacturer’s SBOM and vulnerability data, RunSafe ran a Risk Reduction Analysis that identified more than 2,000 vulnerabilities in a single device, 53 of them critical. More than three-quarters of those critical vulnerabilities involved memory-safety weaknesses such as buffer overflows and out-of-bounds conditions, the types LFR is designed to mitigate. Applying RunSafe Protect could mitigate 49% of all identified vulnerabilities and 77% of the critical ones, without source code changes or a meaningful performance impact. A known vulnerability need not stay fully exploitable while a permanent fix is developed, validated, and distributed.
A Lifecycle Approach to Medical Device Security
Manufacturers can fold this into the product lifecycle that regulators already manage. It begins with generating the SBOM during the build, which records the device’s components more accurately than reconstructing them afterward with scanning or binary analysis. VEX data and reachability information then separate vulnerabilities that are merely present from those actually exploitable, so teams focus resources where they matter most.
Manufacturers can then apply runtime exploit protection like LFR where the patch gap creates the greatest risk, particularly connected, safety-critical, and difficult-to-update devices. The work continues after release, because new vulnerabilities emerge throughout a device’s service life. Teams need to monitor the fielded fleet, keep vulnerability status and documentation current, and maintain a defensible response process. An SBOM is essential, but on its own it does not secure a device; visibility has to lead to prioritization, mitigation, and ongoing action.
Cybersecurity Is Also a Commercial Requirement
Buyers now weigh these capabilities heavily. RunSafe’s 2026 Medical Device Cybersecurity Index, a survey of 551 healthcare professionals in device purchasing, found that 84% now include cybersecurity requirements in requests for proposals, and 35% will not consider a device that ships without an SBOM. More telling, 56% said their organization had rejected a device over cybersecurity concerns, up from 46% the year before. Cybersecurity has become a condition of market access as much as a technical or regulatory matter.
Medical device manufacturers must explain what software is inside a device, which vulnerabilities affect it, how the risk is reduced, and how it stays defensible throughout its life. The strongest answers will not rest on patching alone.
RunSafe Security helps medical device manufacturers put this lifecycle model into practice. RunSafe Identify generates build-time SBOMs and provides exploitability context, while RunSafe Protect uses Load-time Function Randomization to reduce the exploitability of memory-safety vulnerabilities without source code rewrites. The aim is to keep a device from sitting defenseless while it waits for a patch that may take time to validate or deploy, or may never arrive.
For medical device manufacturers, that is the next step in secure-by-design, knowing what is inside the device, understanding what can be exploited, and building in protection that lasts as long as the device does.
See how RunSafe supports FDA Section 524B compliance and long-term medical device security.
Learn MoreSponsored content by RunSafe Security
