The Patch Problem: Ken Hoyme on Why Medtech Can't Keep Up with the Coming Vulnerability Flood

Ken Hoyme spent 18 years as a senior fellow at Honeywell's corporate research lab, earning the company's highest technical recognition for his work on the Boeing 777. When the GE-Honeywell merger collapsed under antitrust review, he moved to Guidant (now Boston Scientific), where he became a senior fellow in cardiac rhythm management and led development of Latitude, the first remote monitoring platform for implantable cardiac devices. That work placed him at the intersection of safety-critical systems and cybersecurity before the industry had a name for that intersection.

He later returned to Boston Scientific to stand up the company-wide product security program, spent time at Adventium Labs leading DHS-funded projects on high-assurance cyber physical architectures, and co-chaired AAMI's Device Security Working Group. He holds 40 US patents and is now consulting with Galois on a $4.2 million ARPA-H program on automated medical device patching.

He also wrote the paper Shannon has been recommending for years: "Streamlining Management of Post-Market Security Vulnerabilities," published in AAMI in 2022. He came on Inside MedTech Innovation to discuss what has changed since it was written, and what AI now showing up on every side of the cybersecurity table means for an industry that was already struggling to keep up.

This episode covers why safety risk and cybersecurity risk cannot be assessed using the same framework, what it actually takes to patch a pacemaker, how separating platform testing from application testing changes the economics of post-market response, and why the 27-year-old Linux bug found in April 2026 is the clearest possible signal of what is coming.

Who Is Ken Hoyme? [00:56]

Hoyme's career follows a consistent thread: life-critical systems. He describes it as mission. Working on military contracts at Honeywell, the work didn't land the same way. "Building something that might go into a weapons system. That just didn't jive with me." When he shifted to the commercial aviation side and started on the Boeing 777, something changed.

He tells a specific story about his children. During the 777 development, his kids were two and four. He made a decision then about the kind of work he wanted to do: "I never want to grow up and tell my kids that I don't want them to fly on that airplane because I know too much about how it was built." His eldest later flew a 777 from Chicago to Shanghai. He was proud of it.

The through-line into medtech is the same. His late mother-in-law had a Boston Scientific pacemaker. He held four patents on the technology inside her.

"Loved ones, whether it's riding on an airplane, whether it's using a cardiac device, whether it's being engaging in the healthcare system, this matters to people, their individuals and their families."

Why Cybersecurity Risk Can't Be Measured Like Safety Risk [10:40]

AAMI TIR57 exists because cybersecurity and safety risk are assessed differently, and the medical device industry was built around safety risk methods.

Safety risk works from historical data. You look at how components have failed in the field, assign probability estimates to failure modes, and build risk models from that. When something fails, the data goes back into the model. It is a rearview mirror process.

Cybersecurity doesn't work that way. "You can be completely unhacked for years and years, and a hacker looks at your device, finds something, and all of a sudden you're hacked." There is no accumulated failure history to draw probability estimates from. One researcher framed it as a black swan event: something unexpected appears and everything changes. The likelihood equation has a different structure.

The harm axis also differs. Traditional IT security focuses on confidentiality: keeping data from being seen by the wrong people. Medical devices have a different threat surface. A hacked MRI machine isn't a confidentiality breach. It's a diagnostic tool going down while a stroke patient is waiting to find out whether they need clot-dissolving drugs or clot busters, a decision that is time-critical and lethal if wrong.

"Understanding how availability can directly affect patient harm and how integrity, if the data is modified, is corrupted, can lead to improper diagnosis, improper therapy."

TIR57's job was to translate the likelihood analysis that cybersecurity uses into language the safety side of the organization could work with. Not a conceptual bridge: a practical one.

Why Patching Everything Quickly Isn't the Answer [16:44]

The obvious question: if a vulnerability exists, why not patch it immediately?

The regulatory answer is that any change to a medical device requires demonstrating that safety and effectiveness were not affected. That process costs money, takes time, and requires people who understand both the device and the software stack. Hoyme describes what deployment looked like at Boston Scientific before networked update infrastructure existed: "the deployment of software to those programmers was sneaker net. It literally was our field reps with a USB drive going in and touching each programmer."

That was a lot of labor to reach all the programmers. And the underlying testing overhead was the same regardless of how the patch was delivered. The situation can collapse into a constant churn: "you could get a situation where you never have finished the previous test and deployment before you've got another urgent one to do."

The problem is structural. The people who understand the device's software are in R&D. R&D is building the next iteration. When a patch needs to be validated, those same people get pulled off development work, miss deadlines, and watch their managers get dinged on performance reviews for it. "We've got the wrong incentives built in to speed up post-market response."

Separating Platform Testing from Application Testing [23:01]

Hoyme's core thesis in the 2022 paper is an organizational and technical one. Medical device testing has traditionally been done as a single unified suite: everything, all at once, at the end of the development cycle before submission. That made sense when the thing being submitted changed slowly. It doesn't work for an environment where third-party software dependencies get patched continuously.

The structure of the problem: a medical device runs on a platform (operating system, third-party libraries) and an application (the code that makes it behave like a pacemaker or an infusion pump). Vulnerabilities in the platform are things the platform is doing wrong. Patching them should not change the application's behavior. But because no one organized testing to separate platform tests from application tests, companies cannot prove that without re-running everything.

"If you patch the vulnerability, you should not be changing the behavior that you counted on. You should be eliminating bad behavior that happens when somebody misuses it."

The parallel he sees is hardware sustaining engineering. At Boston Scientific, a sustaining engineering department handled hardware component changes: supplier changes, manufacturing optimizations, FDA filings for those changes. That work was separate from R&D. Hoyme's argument is that software needs the same structure. A software sustaining function that owns platform-level patch testing, separately funded and separately organized from the team building next-generation features.

Why doesn't it happen already? Because there was no incentive to build the test structure that would make it possible. "There was no incentive to organize tests in such a way that some tests verified that the underlying operating system provided the services that you expected."

The Dedicated Post-Market Patch Team [26:43]

The recommendation in the paper is explicit: a dedicated, separately funded post-market patch team. Not a carve-out from R&D headcount. A separate function with its own budget and its own performance metrics.

The incentive argument is direct. Right now, the people who can do patch validation are the same people being measured on shipping the next device. Every time they get pulled for post-market response, someone's deadline slips. "People respond to what their management chain prioritizes."

A separately funded function changes what the management chain prioritizes. It creates a team with no competing deliverables, no deadline conflicts with product development, and whose entire performance metric is response speed and quality on post-market security events.

Hoyme is candid that he has not seen it implemented consistently in the industry. The structure he describes from Boston Scientific is instructive about why: the product security function started in corporate R&D, which was the only place that had the software expertise. That's the right people, wrong organizational placement.

AI as Red Teamer: The Coming Vulnerability Flood [30:00]

This is where the 2022 paper's argument gets its current urgency.

On April 7, 2026, the Mythos AI announcement included a finding that had been sitting in the Linux kernel for 27 years. Linux is the most-scrutinized piece of software on the planet. Decades of security researchers, automated scanning tools, and public contributions: none of it surfaced this flaw. An AI tool found it.

"To find a bug that's been there for 27 years without all those processes detected, it's like, if they can do that, how many vulnerabilities are there in all of the other things we use?"

The logical conclusion: vulnerability discovery is about to accelerate in a way that existing post-market response processes are not built for. And it isn't just discovery. AI tools generating vulnerability reports are also generating exploit code alongside them. "The mechanism for how to use those vulnerabilities will be readily available as well, and that increases the risk because the likelihood of a deployed attack actually exploiting that vulnerability goes up."

Hoyme had been skeptical of generative AI before this. After April 7th, the position shifted. The implication for medtech is not abstract: "we can't have med devices months out of date with vulnerabilities for which... the AI is not only detecting the vulnerability, but they're providing exploit code."

The industry's current pace of patch validation was already falling short. The coming rate of discovery will make that gap untenable.

Code Signing: Who Controls the Patch [38:00]

One practical constraint on automated patching that Hoyme raises from his work on the ARPA-H UPGRADE program.

FDA increasingly expects that software updates to medical devices are code signed: the device only accepts updates that can be verified as coming from a legitimate source. That's sound security posture. The problem is that the signing keys are held by the manufacturer, not the hospital.

UPGRADE envisions a toolset that hospital IT teams could use to manage the overall risk of their device network. But if a hospital IT person generates a patch and wants to deploy it to a code-signed device, they cannot. They don't have the signing keys. The device won't accept it.

Hoyme's read on where the toolset is most immediately useful: in the hands of the manufacturer, not the hospital. "If it's put in the hands of the manufacturer who have the code signing keys and can now have a path to be able to more rapidly do it, is a huge win for the manufacturers."

That reframes UPGRADE's value proposition. The program is framed as a hospital-facing risk management tool. The code signing constraint means its near-term impact on actual device patching runs through manufacturers. That is a different kind of adoption conversation.

What Automated Validation Could Save [46:33]

Hoyme is careful about citing specific numbers, but he gives enough structure to make the range meaningful.

Pacemaker and defibrillator final verification testing at Boston Scientific took approximately 40 calendar days for a team of people. With documentation and surrounding process, estimates run to nine months. That's for a complete validation cycle.

If platform testing and application testing were separated, and if the platform test suite could be run autonomously to verify that a patch changed nothing the application was counting on, the scope of a typical patch validation cycle would shrink significantly. His estimate for what automated patch validation, done well, could save a product line: "25 to 70%, depends on the type of structure."

Documentation is a separate category. AI has already shown value in generating compliance documentation. "If there's one thing that AI has been pointed at as being good for is gonna be creating documentation and doing that. So maybe if you just deployed it at the documentation stuff and didn't fix the software testing, you would have a big win."

Even the documentation savings alone require a study to validate with a medical device manufacturer. A proof of concept is not sufficient. It's real work, and it requires the manufacturer to participate. That's the gap between research-stage tools and production-ready ones: what Hoyme calls the valley of death in technology transition from government-funded research to commercial use.

What This Means for MedTech

Shannon's thesis going into this episode was that post-market patching is the most urgent unsolved structural problem in medtech cybersecurity, and that AI is about to make the gap visible to everyone.

Hoyme's argument is that the structure for solving it already exists in the organization. Sustaining engineering handled hardware component lifecycle management for decades. Software needs the same function: a team separate from R&D, with separate funding, whose job is platform-level patch validation and deployment. The test architecture to support it is achievable, and separating platform tests from application tests is the technical key.

What's changed since the paper was written: the rate of vulnerability discovery is about to increase in a way that was inevitable and is now visible. A 27-year-old bug in the most-scrutinized software in existence is not a curiosity. It is a signal about everything else we depend on.

"Vulnerability announcements are gonna be coming more and more rapid, and you gotta start planning now."

The industry was not meeting urgency before the AI red teamers arrived. The question now is whether the structural case for dedicated post-market response functions, the one Hoyme has been making since 2022, finally carries the weight it needs to.

Listen to the full episode: https://creators.spotify.com/pod/profile/shannon-lantzy

Inside MedTech Innovation is hosted b

y Shannon Lantzy. This post was created with AI assistance from the full episode transcript.