FDA Cybersecurity Architecture Views for Medical Devices

Architecture views are the diagrams and supporting text that explain how your device and its connected systems fit together from a security point of view. Reviewers read them first, because they give the threat model, security risk assessment and test reports a shared map. This guide explains what each view should show, how the views connect to the rest of the premarket package, and where early-stage teams can start. If you are still at the prototype stage, the early-stage readiness checklist covers the data flow diagram that later becomes your global system view.

Why this matters

The guidance treats architecture views as part of the security risk management documentation for a premarket submission. A threat model without architecture views is hard to review: the reviewer cannot tell which component owns which threat, or whether a control sits on the right side of a trust boundary. We see the same gaps again and again in submissions we review:

• Trust boundaries drawn differently in the architecture views and in the design history file.
• A single block diagram standing in for all four views.
• No multi-patient harm view for a device that talks to a shared cloud backend.
• An update path described in prose only, with no diagram of signing, delivery and rollback.

Each of these makes the threat model harder to follow, and gaps like these tend to draw reviewer questions.

The four architecture views

1. Global system view

The global system view shows the whole system: the device, companion mobile apps, cloud services, update servers, hospital or home networks, third-party services and any manufacturer service tools. It should show every asset, every interface and the communication protocol at each hop, with a trust boundary wherever data passes from one party's control to another's.

What reviewers look for:

• Every external interface, including service ports, debug interfaces and removable media.
• Protocols and authentication at each connection.
• Clear lines between what you control, what the customer controls and what a cloud provider controls.

2. Multi-patient harm view

This view shows where a single compromise could affect more than one patient or device. Common examples are a shared cloud tenancy, a central programming or provisioning server, and a fleet-wide over-the-air update channel. The view should show the path from the shared component to each affected device, and the controls that limit how far an attack can spread.

For a standalone device with no network connection this view may be short, but the guidance still expects you to explain why multi-patient harm is or is not possible.

3. Updatability and patchability view

This view traces the full path a software update takes from your build system to a device in the field: code signing, key storage, distribution servers, any intermediate systems such as a phone app or hospital server, verification on the device, and rollback protection. It should also show how long you can support each component and what happens at end of support.

Section 524B of the FD&C Act requires cyber device manufacturers to have processes to provide updates and patches after release. This view is where you show the design actually supports that.

4. Security use case views

Security use case views show how security works in each important operating state or workflow, such as therapy delivery, alarming, clinician programming, patient pairing, software update and standby. For each one, show the actors, the data exchanged, the security controls in play and what an attacker could do at that point.

These views are where security and safety meet. They give your ISO 14971 and security risk assessment a concrete scenario for each harm.

How the views connect to the rest of the submission

The views are the base layer. The rest of the security documentation builds on them:

1. Threat model: every threat should point to a component or trust boundary shown in a view. See our threat model template and worked example and STRIDE guide.
2. Security risk assessment: risks tie back to threats, and through the security use case views to patient harm.
3. SBOM: components named in the views should match your SBOM.
4. Testing: penetration testing scope should cover every interface the global system view shows.
5. Traceability: the 18 deliverables map shows where each of these lands in eSTAR.

If you change the architecture, update the views first, then the documents that depend on them.

Common mistakes

• Drawing the views once for the submission and never updating them after design changes.
• Leaving out manufacturer-side systems such as build servers, signing infrastructure or support tools.
• Showing the cloud as one box with no detail on what you configure versus what the provider runs.
• Treating the views as marketing diagrams instead of engineering records with versions and owners.
• Writing security use cases only for normal operation and skipping update, service and decommissioning.

Where to start

At the prototype stage, start with a rough data flow diagram: external entities, processes, data stores, data flows and trust boundaries. That diagram grows into the global system view. Add the update path as soon as you choose a firmware update method, and note any shared backend that could become a multi-patient harm path. Write security use cases once the main workflows are stable.

How Blue Goat Cyber approaches this

Architecture views are part of the threat modeling work we do on every full-service FDA premarket engagement. We start from your software architecture, instructions for use and hazard analysis, build the four views with your engineers, and keep the trust boundaries consistent across the threat model, risk assessment and test scope. If you already have diagrams, we review them against the guidance and tell you what is missing.

Frequently asked questions

Does the FDA require exactly four architecture views?

The February 2026 guidance recommends these four kinds of views as part of the security architecture documentation. Guidance is not binding, but following it is the most direct way to give reviewers what they look for. You can add more views if your device needs them, and security use case views usually come as a set, one per workflow.

What format should the views use?

The guidance does not mandate a diagram notation. Data flow diagrams with clearly marked trust boundaries work well, supported by short text and tables describing each interface. Consistency across documents matters more than the drawing tool.

Are architecture views the same as the threat model?

No. The views describe the system. The threat model uses them to list threats against each component and trust boundary. Reviewers expect both, and they expect them to agree.

Do software-only devices need architecture views?

Yes. Software as a medical device still has interfaces, cloud services, third-party components and an update path. The views look different from a hardware device's, but the same four questions apply.

When should we start the views?

Start a rough data flow diagram at the prototype stage and refine it as the design settles. Finalize the views once hardware and software are stable, before formal threat modeling and penetration testing.

Get help with your architecture views

Not sure whether your diagrams will hold up in review? Book a discovery session and we will look at your architecture and tell you what each view still needs.