Skip to main content
    Back to episode
    Episode 30 · July 22, 2025 · 26m listen · 5,040 words · ~25 min read

    What the FDA Wants in Security Architecture Views for Devices | Ep. 29 - Full Transcript | The Med Device Cyber Podcast

    Read the complete, searchable transcript of Episode 30 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, the hosts delve into the intricacies of the four security architecture views mandated by the FDA for medical devices. They meticulously break down each view: the Global System View, Updatability and Patchability View, Multi-Patient Harm View, and Secure Use Case Views. The discussion emphasizes the importance of accurately defining the device's scope, which often extends beyond the physical device to include companion apps, cloud services, and update infrastructure. Listeners will gain insights into securing the entire product lifecycle, from initial development to decommissioning, with a keen focus on preventing multi-patient harm and ensuring robust security across all device functionalities and data flows. The hosts also highlight common pitfalls manufacturers face when developing these views, offering valuable advice for product security teams, regulatory leads, and engineers navigating FDA premarket guidance and product security challenges.

    Key takeaways from this episode

    • The FDA defines four critical security architecture views: Global System View, Updatability and Patchability View, Multi-Patient Harm View, and Secure Use Case Views.
    • The Global System View requires a comprehensive understanding of the device's scope, including physical hardware, software components, cloud services, companion apps, and the update infrastructure.
    • The Updatability and Patchability View focuses on securing the end-to-end update process, from the creation of the update package to its secure installation on the device, including the development environment's security.
    • The Multi-Patient Harm View necessitates assessing scenarios where a compromise of one device or user could lead to harm across multiple devices or patients, emphasizing risk and impact-based approaches.
    • Secure Use Case Views mandate addressing security for every specific functionality, data flow, process, and state of the device, often aligning with a device's functional requirements.
    • A common mistake is incorrectly defining the device's scope, neglecting elements like update infrastructure or interoperable components, or failing to provide sufficient detail and rationale for the architecture design.
    • Proactively incorporating security requirements into functional requirements during product design can prevent significant rework and address FDA expectations more effectively.

    Full episode transcript

    Page 1 of 6· Paragraphs 1 - 9
    Hello and welcome back to the Med Device Cyber Podcast. We are going to be talking about a very interesting topic today, looking at device security architecture. So we are going to go into how we define the scope of a device, how we are considering security on all these entry points and internal components, and then looking at what the FDA is really concerned about as far as any specific use cases and how we are addressing security there. I am joined by our co-host Christian Espinosa. How are you doing today, Christian? I am pretty good. A little bit jet-lagged. I traveled about 28 hours this weekend and I haven't slept much, but it is all good. I had the same flight, but I got in on Friday, so I got to recover this weekend. You got in yesterday, right? I got in Sunday night, so yeah, yeah, it is a little bit rough. Cool. Yeah, I'm excited to talk about this topic. And I know the FDA defines the security architecture views; there are four of those, which are commonly misunderstood. So, how are you doing? Did you recover from your jet lag before we jump into the topic? Yeah, I have my secret patented recipe for avoiding jet lag, and it is don't sleep for 48 hours during the flight process. And then you are so tired when you land, it doesn't matter what time it is, you will just wake up. So, and then a healthy dose of caffeine throughout the day to make sure that I don't break the pattern. Yeah, maybe I should try that. I just had a nitro cold brew and finished all of it. So, there you go. Yeah. So, with these architecture views, there are four main ones that the FDA wants to look at, and we will get into each one. First is the Global System View. What is the device? Next is the Updatability and Patchability View. How are you providing software updates to the device? Then we are looking at the Multi-Patient Harm View. So, what situations can lead to multiple individuals, multiple products, multiple systems getting harmed with one attack? And then Secure Use Cases, which that one is, I think, the most difficult one to really fully wrap your head around. That is when the FDA wants to see you have all these different states for the device, different functionalities, different process flows, and how are you addressing security for each one of those different areas. Typically, when we are talking about architecture views, this is coming from software documentation terms, and software documentation is usually going to be more mature than cybersecurity documentation. And I feel like this is where a lot of engineers can get a bit confused with the distinction. If you say architecture view for software, it is purely what is the device? How can we outline a data flow diagram, an architecture diagram? The architecture diagram is all the components, what is the barrier for the device? Where do we consider something to be out of scope versus in scope for the device? And so I think that that can be a bit of a misconception that leads to a lot of confusion when building out this cybersecurity documentation is that the terms are used interchangeably. It is something that can be not just confined to architecture documentation, just having these interchangeable terms throughout cybersecurity and software, but I think that, personally, that is a big area that leads to deficiencies coming up or any problems with this documentation. Well, I think the clarity needs to be around the FDA specifically defines security architecture views and those four views you mentioned, which is very different than, like you said, a typical architecture diagram for a software or device. Right, yeah, and I think the further that we can divide the two terms, and so saying, you know, security architecture views, oftentimes it will just get abbreviated to architecture views when handling the documentation. And then architecture diagram, architecture views are close enough that there can be definitely that misconception there and a little bit of confusion. But yeah, I agree, the more that we have that distinction, the better. Now where it does sort of blend in is when we are looking at that first security view. That is that Global System View. That is going to actually be fairly similar to an architecture view under a traditional software scope. We are looking at what is the total scope of the device, what is each component within the device, and that helps us build into some of those further discussions on what are individual use cases, how can we harm multiple patients, what is the interoperability component. So I think that it, the software documentation does lead in as a very valuable first step to the cybersecurity documentation.
    1 / 6