Episode 54 · July 22, 2025 · 26m listen · 2,730 words · ~14 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 54 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, hosts Trevor Slattery and Christian Espinosa from Blue Goat Cyber delve into the critical topic of device security architecture, specifically focusing on the four security architecture views required by the FDA for medical device premarket submissions. They provide a detailed breakdown of these views, which are often misunderstood by manufacturers, and explain how properly addressing them is essential for both regulatory compliance and building a secure product from the ground up. The discussion begins by emphasizing the need for a comprehensive understanding of what constitutes a 'device,' which extends beyond physical hardware to include all associated software, mobile apps, cloud components, and even the update infrastructure. The hosts then explore each of the four FDA-defined security architecture views in detail. First is the 'Global System View,' which serves as the foundation for all other security analyses. This view requires manufacturers to clearly define the entire scope and boundary of their device and its ecosystem, outlining all internal components, data flows, and external connections. A common failure point highlighted is neglecting to include the update infrastructure within this scope. Second, they discuss the 'Updateability and Patchability View,' stressing its importance in the context of the total product lifecycle. This view documents how a device will receive secure software updates and patches to address vulnerabilities discovered post-market. The hosts note that this is a major area of concern for the FDA, given the risk of supply chain attacks. The third view is the 'Multi-Patient Harm View,' which analyzes scenarios where a single vulnerability or compromise could impact multiple devices or patients simultaneously, such as a breach of a shared cloud server or the exploitation of hardcoded credentials across a fleet of devices. Finally, they tackle the 'Secure Use Case View,' which they identify as the most frequently misunderstood. This view acts as a catch-all, requiring a mapping of security controls to every specific function, state, and operational context of the device, from power-up and data transmission to user interactions and decommissioning. They advise using the device's functional requirements as a blueprint for building these secure use cases, effectively integrating security by design rather than retrofitting it as an afterthought. Throughout the episode, the hosts offer practical advice and highlight common pitfalls, making a complex regulatory requirement more accessible to engineers and product managers in the medical device industry.

Key takeaways from this episode

The FDA requires medical device manufacturers to submit four specific security architecture views: the Global System View, the Updateability and Patchability View, the Multi-Patient Harm View, and Secure Use Case Views.
The 'Global System View' is crucial for establishing the entire scope of the device, including hardware, software, cloud components, and the often-overlooked update infrastructure.
A device's 'Updateability and Patchability View' is a key focus for regulators, as it demonstrates how the product will be securely maintained and protected against new vulnerabilities throughout its lifecycle.
The 'Multi-Patient Harm View' requires an analysis of how a single security flaw could scale to affect a large number of patients, which is especially relevant for networked devices and cloud-based systems.
The 'Secure Use Case View,' often the most difficult, involves mapping security controls to every function and state of the device, essentially answering how security is addressed for everything the device can do.
A practical approach to creating Secure Use Case Views is to start with the device's functional requirements and build corresponding security requirements for each function.
Defining the complete scope of the device early in the design process is fundamental, as it prevents the need for costly and complex security retrofitting later on.
Even infrastructure for developing and deploying updates is considered part of the device's system from a security perspective and must be protected against compromise.

Full episode transcript

Hello and welcome back to the Med Device Cyber Podcast. We're going to be talking about a very interesting topic today, looking at device security architecture. So, we're going to go into how we define the scope of a device, how we're considering security on all these entry points, these internal components, and then looking at what the FDA is really concerned about as far as any specific use cases and how we're addressing security there. Joined by our co-host Christian Espinosa. How are you doing today, Christian? Christian: I'm pretty good. A little bit jet-lagged. I traveled about 20 hour, 28 hours, uh, this weekend. And I haven't slept much, but it's all good. Trevor: Have the same flight, but I got in on Friday, so I got to recover this weekend. You got in yesterday, right? Christian: Uh, I got in Sunday night. So... Trevor: Yeah, yeah, that's a little bit rough. Christian: Cool. Yeah, I'm excited to talk about, uh, this topic. And I know the FDA defines the security architecture reviews, there's four of those, which are commonly misunderstood. So, um, how are you doing? Have you recovered from your jet lag before we jump into the topic? Trevor: Yeah, I have my secret patented recipe for avoiding jet lag, and it's don't sleep for 48 hours during the flight process. And then you're so tired when you land, it doesn't matter what time it is, you'll just wake up. So, and then a healthy dose of caffeine throughout the day to make sure that I don't break the pattern. Christian: Yeah, maybe I should try that. I just had a nitro cold brew. I finished all of it, so. Trevor: There you go. Yeah, so with these architecture views, there are four main ones that the FDA wants to look at, and we'll get into each one. First is the global system view, what is the device? Next is the updateability and patchability view, how are you providing software updates to the device? And then we're looking at multipatient harm view. So what situations can lead to multiple individuals, multiple products, multiple systems getting harmed with one attack? And then secure use case views, which that one is, I think, the most difficult one to really fully wrap your head around. That's when the FDA wants to see, you have all these different use different states for the device, different functionalities, different process flows, and how are you addressing security for each one of those different areas? Uh, typically when we're 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's purely what is the device? How can we outline a data flow diagram, an architecture diagram? The architecture diagram is all the components, what's 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. And it's 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's a big area that leads to efficiencies coming up or any problems with this documentation. Christian: Well I think the clarity needs to be around the FDA specifically defines security architecture views and those four, four, four views you mentioned, which is very different than, like you said, a typical architecture diagram for a software or device, for a software or device. Trevor: Right. Yeah, and I think the further that we can divide the two terms and so saying security architecture views, often times it'll 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. Um, but yeah, I agree. The more that we have that distinction, the better. Now where it does sort of blend in is when we're looking at that first security view. That's that global system view. That's going to actually be fairly similar to an architecture view under a traditional software scope. We're 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's the interoperability components. So I think that the software documentation does lead in as a very valuable first step to the cybersecurity documentation.

1 / 4