Medical-device security architecture
Sytance · Updated
A security architecture shows how the medical device and its connected systems are protected. It identifies the interfaces an attacker could reach and explains where controls restrict access, protect data or verify software updates.
Architecture as evidence
FDA recommends architecture views that help reviewers understand the device’s exposure to attack and the protection built into the system. In an EU technical file, the same design information supports the applicable MDR or IVDR requirements. The regulatory explanation may differ, but the underlying architecture should describe the actual device and its intended environment.
For example, a remote-support connection may cross from a service provider’s network into a hospital. The architecture should show which endpoint authenticates the technician and which part of the device restricts maintenance actions.
System boundary
Identify the device and the external systems it relies on. State which parts the manufacturer controls and which parts depend on the healthcare organisation or another provider.
Trust boundary
Mark changes in trust or authority. A command arriving from a mobile app, for example, needs to be checked before the device allows it to change a clinical setting.
FDA architecture views
FDA's February 2026 final guidance recommends architecture views that scale with the device architecture and cybersecurity risk. Each view explains a different aspect of how the system can be attacked and how it is protected.
Show the device in the complete system used to deliver its intended function. Include the connected services and the hospital or home network where they affect security. For a complex system, use supporting diagrams to explain the protocols and data flows that would be unreadable in the overall view.
Explain how a single compromise could affect several devices or patients. For example, a compromised central monitoring service may disrupt alarms from many bedside monitors. Show how the system limits that spread and maintains or restores the affected functions.
Follow a software update from its approved source to installation on the device. Show how the device checks authenticity and integrity, what the user must do, and what happens if installation fails. Identify any step that depends on technology outside the manufacturer’s control.
Describe a particular operation that can affect safety or effectiveness. For remote configuration, show the requesting user, the command path and the permission checks before a setting changes. Use additional views for operations with different actors or controls.
EU technical file views
The MDR and IVDR do not prescribe the FDA view names. Architecture information supports the assessment of software security and the device’s interaction with its intended IT environment. It should explain the design assumptions behind the risk assessment and the conditions the user needs to maintain.
- A data-flow view shows where clinical data can be read or changed and which controls protect it along that path.
- An interface view identifies the permitted connections and the checks that restrict their use. These details support the relevant general safety and performance requirements (GSPRs).
- An operating-environment view explains the protection expected from the healthcare organisation, such as restricting the network segment that can reach a maintenance service.
- An update-path view explains how a tested patch reaches the intended devices and how an unsuccessful installation can be recovered.
MDCG 2019-16 Rev.1 explains how manufacturers and healthcare organisations share responsibility for secure operation. The guidance helps relate design assumptions to the minimum IT requirements and security information supplied with the device.
System dependencies
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. Dependencies that affect device safety or security should be included even when the customer operates the connected system.
Cloud and remote services
Include a remote service when the device depends on it for secure operation. For example, loss of an identity service may affect who can access the device and how local access is restored.
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
A patient’s phone and home network introduce controls the manufacturer may not manage. Explain which protections the device provides itself and which settings the user must maintain.
Shared clinical infrastructure
A central monitoring or hospital information system can connect many devices. Show how access through that shared system could affect other devices or patients.
Linking architecture to risk controls
For each important interface, the architecture should help a reviewer find the threat being addressed and the test that checks the protection. If the design relies on a hospital network restriction, the user information needs to describe that restriction so it can be maintained during use.