Skip to main content
    All Episodes
    Episode 024 · June 10, 2025 · 27m listen

    Unpacking Post-Market Management and Incident Response for Medical Devices | Ep. 23

    Episode Summary

    This episode of The Med Device Cyber Podcast delves into the critical aspects of post-market management and incident response for medical devices. Hosts Christian Espinoza and Trevor Slatterie dissect the process of addressing vulnerabilities once a device is in the field, moving beyond traditional cybersecurity paradigms to focus on patient harm and data loss. They explore various sources of vulnerability discovery, including coordinated vulnerability disclosures (CVDs), static testing, fuzz testing, and the CISA Known Exploited Vulnerabilities (KEV) database. The discussion highlights the importance of a robust risk methodology to accurately triage vulnerabilities, emphasizing that scanner-assigned risk levels may not align with real-world impact in a medical context. The episode also touches upon FDA guidance, particularly concerning PMA and 510(k) devices, and the vital role of ticketing software like Jira in tracking and managing vulnerabilities. A significant point of discussion is the challenge of false positives in scanning tools and the evolving nature of exploitability in the post-market phase, urging manufacturers to continuously adapt their security processes.

    Key Takeaways

    • 01Incident response for medical devices prioritizes patient harm and data loss over traditional cybersecurity metrics.
    • 02Vulnerability discovery methods include coordinated vulnerability disclosures, static testing, fuzz testing, and continuous monitoring of the CISA KEV database.
    • 03Medical device manufacturers must have a clear process for triaging vulnerabilities using a risk methodology that accounts for clinical context and patient impact.
    • 04Ticketing software like Jira can effectively track, manage, and report on vulnerabilities, fulfilling FDA metrics requirements.
    • 05Post-market security processes must continuously evolve to address changing exploitability and new vulnerability landscapes, rather than relying on pre-market assessments.

    Frequently Asked Questions

    Quick answers drawn from this episode.

    • This episode of The Med Device Cyber Podcast delves into the critical aspects of post-market management and incident response for medical devices.

    • Incident response for medical devices prioritizes patient harm and data loss over traditional cybersecurity metrics. Vulnerability discovery methods include coordinated vulnerability disclosures, static testing, fuzz testing, and continuous monitoring of the CISA KEV database. Medical device manufacturers must have a clear process for triaging...

    • They explore various sources of vulnerability discovery, including coordinated vulnerability disclosures (CVDs), static testing, fuzz testing, and the CISA Known Exploited Vulnerabilities (KEV) database. It's most useful for medical device manufacturers, cybersecurity engineers, regulatory affairs professionals, and MedTech founders...

    • Incident response for medical devices prioritizes patient harm and data loss over traditional cybersecurity metrics.

    Listeners also asked

    Quick answers pulled from related episodes.

    Share this episode

    Pre-fills with: "Incident response for medical devices prioritizes patient harm and data loss over traditional cybersecurity metrics."

    Hi, welcome back to The Med Device Cyber Podcast. I'm your host, Christian Espinoza, along here with our co-host Trevor Slatterie. Today we're going to be talking about post-market management and incident response. What happens when a medical device is hacked or somebody reports a vulnerability on a coordinated vulnerability disclosure database? What's that process look like? And we're going to unpack that today. So before we dive into it, just checking in with you, Trevor. How's it going this morning? It's going great. We're getting some warm weather. It even broke 70 yesterday so spring has finally arrived. Yeah, it was up to 100 here in the valley. So I went for a walk and it was pretty hot. This year was the earliest year on record that it broke 90 in Phoenix. I think it was February 2nd. Yeah, doing good. Also, we got the Blue Goat coffee mugs. I don't know if you got one yet, but I didn't know we even had those. I got to get one of those. We have those. Yes, we just got back from a conference in California, so we gave a bunch of them away and quite a few other things, but yeah, we'll have to get you some for sure. Perfect. Yeah, we got a couple more conferences coming up, so we'll have to bring some Blue Goat swag. That's true. We got to get shipped out to Boston pretty soon. Cool. So, with incident response, maybe you can just walk us through a little bit of the TIR standard, 97 I believe it is, and then what the high-level process is, then we'll unpack that a little bit. Well, I think we should sort of walk back into general incident response and then we can dive into the medical side of things. So incident response is essentially the next steps after a breach, a vulnerability, or a hack has been uncovered. What is the corrective action? How do you figure out what led to this hack happening, and how do you prevent it from happening again? So, in a traditional cybersecurity perspective, this is usually going to be in a network where a systems administrator or maybe a data engineer or an architect, someone sees that something weird is going on. There's unaccounted for traffic. There's a rogue device. There's something that doesn't line up with their expected baseline, and that's a sign that they've been hacked. And they take a look, you can review network traffic. Well, it could be an anomaly, right? We've had clients that thought they were hacked, but it's actually an anomaly and they had to run it to ground. So, it's not always somebody hacking into you. It's like you said, anomalous behavior. We have to figure out what the root cause of it. Yeah, sometimes it's just computers being weird, which happens quite a lot. So, it's not always a doomsday situation, you've been hacked. Often times it's just something weird going on, but you want to know whether or not someone was hacked or if it was just weird behavior. So, you track it down and you look at networks on your perimeter. So, your VPN access, your firewalls, things like that, see if there's a problem and you try to get down to the root cause of what's going on. Now, in medical devices, rarely is a device going to be a connected network. It can be in a connected network, but it isn't the network itself. It's a single component, so you're usually going to have a pretty targeted search if something goes wrong. In the medical space, luckily, the more common way that these vulnerabilities come up is through benevolent security researchers as opposed to malicious hackers. But that's not always the case. It can often just be even a user that notices weird behavior. So, they are going to have a process to inform the manufacturer or in some cases inform whoever's handling their security if that's outsourced, that there's a problem in this product. Maybe it's even just through an annual penetration test or more often it'll be a coordinated vulnerability disclosure in the product where they say,

    Hosted by

    More from your hosts

    Other episodes diving into Christian and Trevor's areas of focus.

    Episodes covering similar ground.

    Why this matches covers similar themes around post-market, pre-market, testing.

    Why this matches covers similar themes around exploitability, levels, manage.

    Listen to this episode