Skip to main content
    Back to episode
    Episode 41 · December 2, 2025 · 11m listen · 1,875 words · ~9 min read

    Cybersecurity Qs MedTech Innovators Ask: Christian’s Hot Seat | Ep. 48 - 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

    This episode of The Med Device Cyber Podcast places Christian in the hot seat, addressing critical questions frequently posed by MedTech innovators. The discussion kicks off by demystifying ISO 13485, explaining its role in establishing robust quality management systems essential for medical device traceability, design history, and risk mitigation. A pivotal point of the conversation highlights cybersecurity as the most common reason for FDA medical device rejection, underscoring its paramount importance in the current regulatory landscape. The episode clarifies the distinct differences between Software as a Medical Device (SAMD) and Software in a Medical Device (SIMD), using practical examples like AI-powered image enhancement tools versus integrated patient monitoring systems. A significant portion delves into the often-misunderstood distinctions between HIPAA compliance and FDA cybersecurity requirements, emphasizing the FDA's primary concern with patient safety over protected health information. The hosts also explore the varying cybersecurity requirements globally, identifying the FDA as a leading, albeit stringent, authority whose guidelines often influence international markets indirectly, such as the path to Chinese market entry via Hong Kong approval. The episode concludes by reinforcing the podcast's mission to arm MedTech innovators with actionable cybersecurity knowledge to prevent device rejection and market delays.

    Key takeaways from this episode

    • ISO 13485 is crucial for establishing a quality management system that ensures traceability, proper design, and effective risk mitigation for medical devices.
    • Insufficient cybersecurity is currently the most cited reason for medical device rejection by the FDA, highlighting its critical role in regulatory approval.
    • Software as a Medical Device (SAMD) refers to standalone software, while Software in a Medical Device (SIMD) refers to software embedded within a hardware medical device.
    • FDA cybersecurity requirements prioritize patient safety above all else, which differs significantly from HIPAA's focus on protecting health information.
    • The FDA is generally considered the global leader in stringent cybersecurity requirements for medical devices, with its standards often influencing international markets.
    • Understanding the nuances of international regulatory bodies like China's NMPA, which may require significant device overhauls, is crucial for global market access.

    Full episode transcript

    Page 1 of 3· Paragraphs 1 - 12
    Hello and welcome back to another episode of the Med Device Cyber Podcast. This one is going to be a little bit different from our typical flow. We're putting Christian in the hot seat and running him through some of the questions that we see come up all the time as frequently asked questions with MedTech innovators, and seeing how he does and how well he knows all of these processes. All right, we'll start off with a good one and a very important one. Could you give us a little description of what ISO 13485 is? ISO 13485 is the standard for a quality management system, and how to set that up, what should be in that system, and what the foundational components of that system are. The whole idea is that when you have a medical device, you need to have a QMS, or some sort of system, that has basically all the information about the medical device: the design history files, the cybersecurity documentation. The whole idea is, I have all this stuff organized in a very logical manner so I have traceability for when the device is in the market, traceability for when it was designed, how it was built, how it was tested. I have that full visibility and traceability in the system. Then, when a problem comes up with the device, I feed that into the quality management system, and we have the evidence of what we did to reconcile that problem and make sure the risk is at an acceptable level. For example, if we had to mitigate the risk and how we did that and the history of that, or if we decided the risk was already at an acceptable level and we didn't need to take any action. Excellent. Yes, that's a perfect way to put it. We're trying to make sure that we have quality, repeatable, and secure processes. It's often one of the bigger frustrations for working with healthcare and MedTech devices, just since it's a little bit unique to regulated spaces, for sure, but very important. All right. Now, what is the most common reason that medical devices get rejected by the FDA? Lately, in the past year or so, the most common reason is cybersecurity – actually, insufficient or inadequate cybersecurity, I should say. Yes, exactly. All right. Now, could you give us a little bit of a summary of the description between SAMD and SIMD products? Oh my goodness. SAMD is Software as a Medical Device. So, this would be some sort of software that may sit on the cloud; it could be some sort of AI image enhancement tool that takes an ultrasound image, sends it up to the cloud, and the software component runs AI through it and does some image enhancement for something like a vascular disease. So the physician can look at the image and see the vascular portion much better than just through the ultrasound or an MRI. A SIMD is Software in a Medical Device, and that is basically a medical device that has software inside of it. This could be like a patient monitoring system that has software inside of it. The Software as a Medical Device is only software, so there's no hardware component with it. The patient monitoring system is a good example; it's the hardware, and the software running in that hardware. Yes, exactly. Okay, so I was on the right track. All right. Now, here's a question that I actually got last night at dinner, believe it or not. This was at the Georgian Calian dinner, and I was talking with a startup innovator that has a new product that they're just about to gear up for their 510K. We were talking about what cybersecurity needs to go into it, and he asked, "Well, I have HIPAA compliance. Is that going to work for the FDA?" I told him, "No, it's not." So, what are some of the differences between what HIPAA looks for and what the FDA looks for? There are some stark differences. The FDA is primarily concerned with patient safety, meaning, if I can hack into this medical device, what harm can I cause to a patient? That is a primary lens the FDA is looking through. HIPAA, in contrast, is related to protected health information. It has nothing to do with patient safety. It's like, is my charting about my diagnosis protected? Is my insurance protected that's in the hospital for my treatment? And those are two very different things. I think this is a commonly misunderstood concept with MedTech cybersecurity. People often think it's about the data, which is HIPAA. The data is important, but it's secondary to patient safety. I like to give an analogy: if I've got a defibrillator and somebody has hacked into it remotely through Med Radio or whichever radio means, and they're shocking me to death while at the same time somebody's stealing my health records, do I actually care that they're stealing my health records, or do I focus on being shocked to death?
    1 / 3