FDA recommends at least four security architecture views in a premarket submission: a global system view, a multi-patient harm view, an updatability and patchability view, and security use case views. Each pairs diagrams with explanatory text, and the amount of detail scales with the device's cybersecurity risk.
Why views at all
The guidance asks manufacturers to keep security architecture documentation as part of designing and maintaining the system. It serves two jobs. It shows reviewers how controls were applied, and it helps the manufacturer find impacted functionality when a corrective action is needed later.
The number of views depends on the attack surfaces found in threat modeling. FDA says a system with network or cloud access would be expected to have more security use case views than one that has only a USB interface. If one view already captures another, or the threat model covers it, duplication is not expected. If a view does not apply, explain why it is left out.
Global system view
This describes the overall system, including the device and all internal and external connections. For networked devices it should identify all interconnected elements, including update infrastructure, healthcare facility network impacts, intermediary devices, cloud connections and patient home network impact.
Multi-patient harm view
Connected devices can be compromised together. The guidance gives an example of multiparameter bedside monitors all restarting at once, so every monitor on a network stops watching vitals while staff cannot cover every patient. A compromised non-device function that can affect device function is also in scope.
This view should show how the device and its system defend against, or respond to, attacks that could harm many patients. FDA notes such risks may need to be rated differently in the risk assessment.
Updatability and patchability view
This view describes the end to end process for delivering updates and patches. The guidance gives an example of pushing software from an update server to an in-clinic cardiac implant programmer. End to end means the whole path to that programmer, which likely crosses technology the manufacturer does not control. The design should protect that path and account for the added risk.
Security use case views
Use cases should cover all functionality where a security compromise could affect safety or effectiveness. They should span operating states such as power on, standby and transition states, and clinical states such as programming, alarming, delivering therapy, sending and receiving data, and reporting diagnostic results.
Use cases that share the same security assessment can be described together. The guidance notes that programming commands and data transfer may share one protocol and so share a view even if their clinical risk differs.
What each view should do
The guidance says the views should identify security relevant elements and interfaces, define the security context, domains, boundaries, critical user roles and external interfaces, align the architecture with security objectives, and establish traceability from architecture elements to security requirements.
Quick check
Do I need all four views for every device?
FDA recommends these four at minimum, but it says a view may be skipped with an explanation, and overlapping views need not be duplicated. Scale follows cybersecurity risk.
Are diagrams enough?
No. The guidance recommends both diagrams and explanatory text with enough detail to show how assets function together.
Sources
Last reviewed: 19 October 2026.
