Medical Device Security Architecture: How to Build the View FDA Expects

A medical device security architecture view shows FDA where security lives in your design: the components, the trust boundaries between them, and the controls at each boundary.

This guide helps medical device manufacturers show FDA how their security protections work and how they align with FDA cybersecurity guidelines, AAMI TIR57, AAMI SW96, and industry best practices.

Introduction

Connected medical devices create even greater cybersecurity threats to data and patients. As a result, FDA premarket cybersecurity guidance (February 2026) calls for manufacturers to document their security architecture as a set of views (Section V.B.2).

AAMI TIR57 and ANSI/AAMI SW96:2023 guide cybersecurity risk management, while FDA specifies the architecture views used to document it.

This guide outlines how to create a security architecture view so your design is secure and your submission shows it.

For the full set of views FDA expects and how they fit together, see our book chapter on security architecture views.

Step 1: Define the System Architecture

Before you can map your device's security protections, you need to understand how the entire system fits together.

Key actions

• Identify hardware components (e.g., microcontrollers, sensors, communication modules, memory units).
• Map out software layers (e.g., embedded firmware, operating system, middleware, application software, security modules).
• Define communication pathways (e.g., Bluetooth, Wi-Fi, cellular, cloud services, hospital networks).
• Determine data flow (e.g., patient data transmission, logging, and storage mechanisms, remote monitoring, and control features).
• Identify interactions with external systems, such as electronic health records (EHRs), mobile applications, and cloud-based analytics platforms.

Then produce the views. FDA's guidance recommends four at minimum (Section V.B.2). You can add other security analyses (teams often do), but make sure FDA can distinguish them from its four recommended FDA architecture views.

The four views FDA recommends

Global System View

This is the big-picture diagram showing the device, its components, and everything it connects to.

For networked devices, the guidance asks it to identify all interconnected elements, including software update infrastructure, healthcare facility network impacts, intermediary devices, cloud connections, and patient home network impact. It covers:

• The device ecosystem, including cloud services, mobile apps, hospital networks, and update servers.
• Dependencies and third-party integrations, identifying security risks in shared software components.

Example: A cloud-connected patient monitoring device that interfaces with hospital EHR systems and protects every path end to end.

Multi-Patient Harm View

FDA wants manufacturers to consider whether one cyberattack could affect multiple devices or patients simultaneously.

The guidance notes that when devices connect to networks or the internet, multiple devices can be compromised simultaneously. In addition, the guidance asks how the device and the system defend against and respond to such attacks. These are common scenarios:

• A single exploit in a connected infusion pump system disrupts multiple patient treatments.
• A ransomware attack on a hospital-wide medical device network prevents multiple patients from receiving timely care.

Example: Networked ventilators in an ICU that could be remotely controlled or disabled by one attacker.

Updatability and Patchability View

FDA wants to see how security updates travel from the manufacturer to the medical device. This includes the safeguards that stop attackers from interfering with those updates.

The updatability patchability view describes the end-to-end process that delivers software updates and patches to the device, including segments of the path the manufacturer does not control. It covers:

• Secure firmware and software update mechanisms that prevent unauthorized modifications.
• Patch management policies to address vulnerabilities promptly without disrupting patient care.

Example: A remote defibrillator that supports digitally signed firmware updates to prevent malicious tampering.

Security Use Case Views

These views examine particular ways a device operates and whether a cybersecurity problem during those operations could affect patient safety or device performance.

FDA wants manufacturers to show how a cyberattack could affect a medical device during different activities, such as starting up, delivering treatment, or transmitting patient data.

Keep this in mind: The more ways a device connects and operates, the more security scenarios manufacturers generally need to examine. A cloud-connected device will typically need more security use case views than a simple USB-connected device.

If several activities involve the same security risks and protections, manufacturers can cover them in one view rather than creating separate diagrams.

Additional analysis lenses

The following are useful ways to analyze the design. They are not FDA-named views, so present them as supporting analysis or fold them into the Security Use Case Views.

Access control lens. How users and systems access the device and what they are allowed to do.

• User authentication methods such as biometrics, passwords, or multi-factor authentication.
• Role-based access control (RBAC) to enforce different permission levels based on user roles.

Example: A hospital-administered insulin pump where only clinicians can modify dosage settings, while patients can view logs.

Data integrity lens. This lens covers how the manufacturer prevents unauthorized changes to device data and detects possible tampering. It includes:

• Encryption and checksum mechanisms to detect unauthorized data alterations.
• Audit logs and anomaly detection to identify potential tampering.

Example: A cloud-based patient monitoring device that uses cryptographic signatures to verify the authenticity of transmitted health data.

Be sure to use data flow diagrams and system architecture diagrams to visualize these elements. Appendix 2 of the guidance names data flow, state, swim-lane, and call-flow diagrams as acceptable methods, each paired with explanatory text.

Step 2: Identify Security Boundaries and Trust Zones

Think of trust boundaries as checkpoints where data or commands move between areas with different levels of security.

This step is about how manufacturers need to identify which parts of their medical device system can be trusted, which connections pose security risks, and where protections are needed.

Key considerations

• Trusted zones: These aren't automatically secure. They're secure areas such as on-device storage, cryptographic modules, hardware security modules (HSMs), and authenticated user access points where specific security protections and access rules apply.
• Untrusted zones: External connections such as network connections, cloud services, third-party APIs, and public networks. These need additional security controls and should not be trusted by default.
• Interfaces and entry points: Define attack surfaces where data enters and exits the system, including user interfaces, remote access points, wireless communication channels, and firmware update mechanisms.
• Data classification: This simply means identifying sensitive information (e.g., patient health records, device operational data, cryptographic keys) and deciding how to protect it.

A threat model (using frameworks like STRIDE or DREAD) identifies possible attacks at these boundaries and evaluates their risks. STRIDE helps identify threats; DREAD helps assess them.

Step 3: Define Security Controls and Countermeasures

Once you've identified the risks, decide how to protect the device. FDA's cybersecurity guidance calls out eight categories of security controls in Section V.B.1, with additional recommendations in Appendix 1:

The eight categories are:

• Authorization
• Authentication
• Cryptography
• Code, Data, and Execution Integrity
• Confidentiality
• Event Detection and Logging
• Resiliency and Recovery
• Updatability and Patchability

Tip: Manufacturers should choose controls appropriate for their devices, including cryptography that follows current NIST recommendations.

Key security controls

• Authentication and access control:
  • Implement multi-factor authentication (MFA) for user and device access.
  • Enforce role-based access control (RBAC) to limit permissions.
  • Use biometric authentication for high-security applications.
• Data protection and encryption:
  • Use AES-256 encryption for data at rest and TLS 1.3 for data in transit.
  • Implement secure boot and code signing to prevent unauthorized firmware modifications.
  • Employ secure enclaves for sensitive computation and key storage.
• Network security:
  • Apply firewalls and intrusion detection/prevention systems (IDS/IPS) at communication endpoints.
  • Enforce secure pairing and communication protocols for Bluetooth and Wi-Fi.
  • Use zero-trust network architecture to restrict access between different device components.
• Monitoring and incident response:
  • Enable real-time logging and anomaly detection to identify security breaches.
  • Develop an incident response plan aligned with FDA's postmarket cybersecurity guidance (December 2016).

Step 4: Align with Regulatory and Compliance Standards

Here's where you want to check your security architecture against FDA guidance and the industry standards it references.

Relevant standards and guidance

• FDA premarket cybersecurity guidance (February 2026): Recommends threat modeling, a cybersecurity risk assessment, security architecture views, and an end-to-end update path (Sections V.A and V.B). For cyber devices, Section 524B(b) of the FD&C Act adds statutory requirements, covered in FDA Section 524B requirements.
• ANSI/AAMI SW96:2023: Specifies security risk management across the lifecycle within the ISO 14971 framework.
• ISO 14971:2019: Defines the safety risk management process that security risks with a patient harm path transfer into.
• ISA/IEC 62443-4-1: Describes a secure product development lifecycle; the guidance cites it as an example framework.

Remember: Keep a record of your security decisions, the controls you've implemented, and the evidence that they work. You'll need that information when preparing your FDA submission.

Our book section on security architecture views for eSTAR submissions details how to package these views for FDA review.

Step 5: Continuously Monitor and Improve Security

Cybersecurity doesn't end when your medical device reaches the market. New vulnerabilities will emerge, software will change, and security protections will need regular attention.

Practices for continuous security

• Conduct regular security assessments (e.g., penetration testing, vulnerability scans).
• Update software and firmware with security patches as threats evolve.
• Monitor cybersecurity alerts and threat intelligence feeds, including CISA's Known Exploited Vulnerabilities catalog. (This one is particularly important.)
• Train personnel on security practices and the procedures in your Cybersecurity Management Plan.

Conclusion

Security architecture views help FDA reviewers understand your device's cybersecurity risks and the protections you've designed to address them.

Keep it organized.

• Start by mapping the system and its trust boundaries.
• Then identify the security controls.
• Organize them around FDA's eight categories.
• Document the four recommended FDA architecture views using details described in Appendix 2.
• Keep those views updated as your device changes.

Need help with your medical device FDA security architecture views? Contact CyberMed or email us at info@cybermed.ai.

Sources

• FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance, February 3, 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
• FDA. Postmarket Management of Cybersecurity in Medical Devices. Final guidance, December 28, 2016. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/postmarket-management-cybersecurity-medical-devices
• ANSI/AAMI SW96:2023. Standard for medical device security, Security risk management for device manufacturers.
• AAMI TIR57:2016 (R2023). Principles for medical device security, Risk management.
• ISO 14971:2019. Medical devices, Application of risk management to medical devices.
• ANSI/ISA 62443-4-1. Security for industrial automation and control systems, Part 4-1: Product security development life-cycle requirements.