Episode 41 · December 23, 2025 · 22m listen · 3,907 words · ~20 min read
Trevor Slattery Answers Tough Medical Device Cyber Questions | Ep. 51 - Full Transcript | The Med Device Cyber Podcast
Read the complete, searchable transcript of Episode 41 of The Med Device Cyber Podcast - expert conversations on medical device cybersecurity, FDA premarket and postmarket guidance, SBOM management, threat modeling, and penetration testing.
Prefer the listening experience? Open the episode page for the synopsis, key takeaways, topics, and Apple / YouTube listen links.
Episode summary
In this episode of the Med Device Cyber Podcast, host Christian Espinosa, founder and CEO of Blue Goat Cyber, switches formats to put his CTO, Trevor Slattery, in the "hot seat." The episode is a rapid-fire Q&A session designed to test Trevor's knowledge and provide listeners with quick, clear definitions of essential concepts, standards, and acronyms in the world of medical device cybersecurity. Christian quizzes Trevor on a wide range of topics, starting with foundational regulatory standards and moving into more technical testing methodologies and security concepts.
The core of the discussion revolves around the key standards that govern medical device development and security. Trevor begins by explaining IEC 62304, which dictates the software development lifecycle and safety classifications for medical devices. He then contrasts this with ISO 14971, clarifying that its focus is primarily on patient safety risk management, not cybersecurity directly. Building on this, Trevor defines AAMI TIR57 as the standard that adapts the risk management principles of ISO 14971 specifically for cybersecurity risks, and notes that AAMI TIR97 addresses post-market security activities. The conversation also touches on ISO/IEC 81001-5-1, which provides guidance on implementing a Secure Product Development Framework (SPDF) across the entire Total Product Life Cycle (TPLC), from design to decommissioning.
Beyond regulatory frameworks, the Q&A delves into practical security terminology and practices. Trevor defines different testing approaches, distinguishing between black-box penetration testing (simulating an attacker with no prior knowledge) and white-box testing (where the tester has full access to source code and architecture). He also explains fuzz testing, a dynamic testing method that involves sending a massive amount of malformed data to a device to uncover vulnerabilities. Other key terms defined include SBOM (Software Bill of Materials), an essential inventory of all software components in a device, and SOUP (Software of Unknown Provenance), which refers to any code without a clear, documented origin. The episode serves as a valuable glossary for professionals in the MedTech space, demystifying the complex language of cybersecurity compliance and practice.
Key takeaways from this episode
IEC 62304 is the standard for the medical device software lifecycle, establishing processes for secure development and classifying devices based on safety risk.
ISO 14971 is the core standard for risk management, but it is primarily focused on patient safety. AAMI TIR57 adapts this framework specifically for cybersecurity-related risks.
A Secure Product Development Framework (SPDF) provides the processes and procedures necessary to build security into a medical device across its Total Product Life Cycle (TPLC), from design to disposal.
An SBOM, or Software Bill of Materials, is a comprehensive list of all software components in a device, including both proprietary and third-party code, which is now a requirement for regulatory submissions.
SOUP stands for Software of Unknown Provenance, which refers to any code component without a verifiable origin or development process, posing a potential security risk.
The FDA's definition of a "cyber device" is broad, encompassing any device with software and a network interface, which includes not just Wi-Fi but also Bluetooth, NFC, and USB.
Penetration testing can be black-box (simulating an external attacker with no inside knowledge) or white-box (giving the tester full access to code and architecture for a deeper review).
Christian: Hi, welcome back to another episode of The Med Device Cyber Podcast. Today we're going to switch it up a little bit and I'm going to put Trevor in the hot seat and do a rapid fire to see if he actually is the brain box as he's been called before. So we'll put him to the test.
Christian: Uh I'm your host, Christian Espinosa, the Founder and CEO of Blue Goat Cyber. I'm here with Trevor who is the brain box and the CTO of our company. He's coming from NorCal, California. So I'm not sure if he's gained intelligence or lost intelligence from moving from Arizona to California, but we'll, I guess we'll figure it out.
Trevor: I've definitely lost some having to go to the DMV here like 40 times.
Christian: 40 times.
Trevor: It felt like it. I think it was actually about five times, which is five too many. The San Francisco DMV is a dark place.
Christian: Yeah, I don't like going to DMVs at all. I heard there was, there's like private places though you can pay a little bit extra to avoid the DMV.
Trevor: I couldn't find one near here, but I would always do that in Arizona. There was a, the Footwork in Cottonwood.
Christian: Yeah, all right. So we're gonna play, uh, rapid fire. So Trevor is a super smart with medical device cybersecurity, so I'm gonna ask him some questions and see how he does answering. And these are questions that a lot of you probably think about periodically, maybe not, but you're probably wondering like what IEC 62304 is, and all this other stuff. So we'll get Trevor's answer and if he goofs it up too much, which I don't expect him to, then I'll fill in the gaps.
Trevor: IEC 62304 talks about safety classifications and secure development lifecycle practices within medical devices. So, it's a good framework for understanding what controls would be applicable based on scaling device risk. Uh, uses the European classification class A, B, and C, and talks about some of the specific implementations that may be applicable for a high-risk Class C device, may not be as applicable for a low-risk Class A device, and then general best practices with software lifecycles within medical devices.
Christian: Perfect. So if I am a medical device manufacturer and I'm trying to decide what sort of outsourced software development vendor or company I should choose, I should choose one that follows IEC 62304, correct?
Trevor: Yep, exactly.
Christian: Awesome. Let's stick with the standards and we'll jump into one, uh, ISO 14971. What is that?
Trevor: ISO 14971 is titled Risk Management in Medical Devices and it focuses mostly on how safety risk is handled within medical products. Obviously, safety is the paramount concern within medical systems. It wants to outline a clearly repeatable process for conducting a risk assessment and having a risk management process. So, what acts as the input into the risk assessment, what is that procedure for successfully triaging it, moving into pre- and post-production activities and risk controls after the fact. But it is notably gated largely to these safety considerations. So there are other standards that are more applicable and more appropriate for handling other types of risks in product.
Christian: All right. So to sum it up ISO 14971 talks about patient safety and risk in terms of patient safety. It has nothing to do with cybersecurity. Uh, it's mainly about patient safety, correct?
Trevor: Correct. The framework for it can be modified for cybersecurity and I might even be getting ahead of you on one of these questions here.
Christian: Well I was gonna get, I was gonna go to that. I might as well since we're talking about ISO 14971. So let's talk about, are you tell me what AAMI TIR57 is and then tie it back to ISO 14971?
Trevor: So AAMI TIR57 is security risk management within medical devices. Uh, it is very, very heavily based off of ISO 14971 and both of them actually talk about the risk management flow and they look practically identical between the two standards. AAMI TIR57 explicitly calls out ISO 14971 as the inspiration for how this standard was created, and it also talks about the intersection points where the two can overlap.
Trevor: So when we're conducting a risk assessment, we identify a problem. We say, "Oh, we think this is a security vulnerability, we're conducting our risk assessment against it." Turns out there's actually some safety impacts here. So AAMI TIR57 talks about when we feed these vulnerabilities out from the security risk management framework into your ISO 14971 safety risk management framework as the intersection and blend of safety and security.
Christian: Perfect. Since we're talking about AAMI TIR57, let's go ahead and jump to AAMI TIR97 because they're both related to medical device cybersecurity. So, what is that one?