Security Architecture
Security architecture evidence explains how the medical device system is built, how data and updates move, which trust boundaries exist, and how controls are placed across the device and its related systems. It is not a generic diagram pack.
Architecture as evidence
FDA and EU files use architecture evidence for different legal and review questions. FDA asks for security architecture views in premarket submissions so FDA can understand security context, interfaces, external entities, trust boundaries and control placement. EU MDR and MDCG files use the same engineering facts to support Annex I software, information-security, risk-management, minimum-IT and user-information requirements.
A useful security architecture view therefore starts from the device system and its intended environment. It should show enough detail to explain why the selected controls fit the real deployment, not just that a diagram exists.
System boundary
The boundary should show the device, manufacturer-controlled services, external systems, user roles, data stores and interfaces that affect safety, performance or security.
Trust boundary
Trust boundaries should show where data, commands, identities, software updates or operational control cross between different control domains.
FDA architecture views
FDA's February 2026 final guidance recommends architecture views that scale with the device architecture and cybersecurity risk. The named FDA view types are not decorative labels. Each view answers a review question about how the system can be attacked and how it is protected.
This view describes the overall medical device system, including the device, internal and external connections, intermediary devices, software update infrastructure, facility network effects, cloud connections and patient home network effects. Complex systems may need supporting views for protocol and data-flow detail.
This view explains whether compromise of one product, service, network path or non-device function can affect multiple devices or multiple patients. It matters most for connected systems, shared services, central monitoring, update infrastructure and fleet-level dependencies.
This view describes the end-to-end update path. It should include the source of update packages, distribution path, authentication, integrity checks, rollback constraints, deployment assumptions, user action and any technology outside manufacturer control.
These views explain specific functionality that can carry safety or effectiveness risk, such as implant programming, remote configuration, cloud analytics, remote access, administrator functions or data export.
EU technical file views
The MDR and IVDR do not require FDA-named architecture views. The EU file should instead map architecture evidence to MDR or IVDR terms: intended purpose, intended operating environment, software lifecycle, risk management, information security, interaction with the IT environment, interoperability, verification, validation, instructions for use and postmarket surveillance.
- Data-flow views can support the risk-management file by showing how clinical data, commands, logs, updates and credentials move through the system.
- Interface views can support GSPR mapping by showing network ports, wireless paths, APIs, removable media, local service ports and interoperability constraints.
- Operating-environment views can support minimum IT requirements by showing expected network segmentation, access control, patching, monitoring, backup and physical-security assumptions.
- Update-path views can support lifecycle evidence by showing how security patches are created, validated, distributed, installed, recovered and communicated.
MDCG 2019-16 is useful because it links cybersecurity to safety, effectiveness, intended use, intended operational environment and joint responsibility. It should be treated as EU guidance for MDR and IVDR implementation, not as an FDA submission format.
Dependencies that change the file
Architecture depth should follow the actual device system. A simple local device may need fewer views than a cloud-connected, mobile, networked or fleet-managed system. The file becomes weak when those dependencies are hidden or treated as customer-only assumptions.
Cloud and remote services
Cloud storage, analytics, identity services, remote support and update servers can be part of the security architecture when device safety, performance or security depends on them.
Update paths
Update architecture should explain the full path from release approval to fielded device, including authenticity, integrity, deployment failure and recovery.
Mobile and home use
Mobile apps, patient home networks, Bluetooth, cellular paths and consumer devices can change trust boundaries and user responsibilities.
Shared clinical infrastructure
Hospital networks, PACS, HIS, middleware, monitoring stations and identity systems can create multi-device and multi-patient paths that the architecture must explain.
Traceability without a checklist
The architecture should be traceable to threat modelling, security requirements, risk controls, testing, labelling and postmarket monitoring. That traceability is different from a generic checklist. It shows why the view contains the chosen system elements and why the selected controls are adequate for the intended use environment.
- A data-flow boundary should point to the threat or risk that makes the boundary relevant.
- An interface should point to the security requirement, test evidence and user information that control its use.
- An update path should point to patch validation, communication and recovery evidence.
- A customer-network assumption should point to labelling or technical documentation that tells the healthcare organisation what it must provide.