Security Architecture Views: The FDA's Four Required Diagrams

Part of our Medical device security controls, architecture, and integrity primitives series. For the full overview, start with Code and Data Integrity Controls for Medical Devices.

Reviewed September 17, 2026

Architecture views are one of the few submission elements where a reviewer can see, in a few seconds, whether the manufacturer understands their own attack surface. A diagram either shows trust boundaries and what crosses them, or it shows boxes connected by unlabeled lines. The second kind is common, and it generates questions.

These views also do work for you internally. The scope of your penetration test, the completeness of your threat model, and the coherence of your risk file all depend on having an accurate picture of what connects to what. Drawing them properly once makes several later documents easier.

Why Four Views Instead of One Diagram

The February 3, 2026 premarket cybersecurity guidance frames architecture documentation as a set of views because a single diagram cannot carry the information a reviewer needs. A picture that shows every component at once becomes unreadable, and a picture simplified enough to read leaves out the detail that matters.

Separating the views also separates the questions. One asks what the system is and where its boundaries lie. One asks what happens when the failure is not confined to a single patient. One asks how the device changes after it is deployed. One asks how a specific security-relevant interaction actually works, step by step.

Reviewers use these views as an index into the rest of the submission. When a threat model references an interface, the reviewer looks for it in the views. When a penetration test report covers a component, the reviewer checks whether the views show it. Inconsistency between them is one of the fastest ways to draw a deficiency question, because it suggests the documents were produced by different people who did not reconcile them.

The Four Views and What Each Must Show

The global system view is the one most manufacturers already have in some form, usually as an engineering block diagram. Converting it into a security view means adding what the engineering diagram leaves out: where trust changes, what protocol carries each connection, what authenticates at each hop, and which side of each boundary you control.

The multi-patient harm view is the one most often absent. It exists because a compromise of a single device harms one patient, while a compromise of the cloud service that configures every device harms all of them. The view should identify every place where one action affects many patients: management APIs, configuration servers, shared credentials, drug libraries, model update pipelines, and hospital-side aggregation points.

The updateability view has to show authentication, not just delivery. A diagram with an arrow labeled "firmware update" tells a reviewer nothing. The view should show where the update originates, how it is signed, where the verification key lives, what verifies the signature before installation, what happens if verification fails, and whether the device can roll back.

Security use case views are narrative diagrams for individual interactions. Pick the interactions that carry security weight, typically initial pairing, user authentication, firmware update, remote access, and data export, and show each one as a sequence with what is exchanged at each step.

[KEY REQUIREMENT] Every boundary in every view should be labeled with what crosses it, what protects it, and what authenticates at it. An unlabeled arrow is an unanswered question.

Mistakes That Draw Deficiency Questions

The cloud icon problem is worth dwelling on. For a connected device, the back end usually holds the capability with the broadest reach: it can push configuration, deliver firmware, and read data from the whole fleet. Compressing all of that into one icon removes precisely the detail the multi-patient harm view exists to expose.

Keeping the Views Consistent With Everything Else

Views are cross-referenced, so consistency is a submission-level property rather than a diagram-level one. A short reconciliation pass before filing catches most of what reviewers would otherwise find.

See also: Data Flow Diagrams for Medical Device Security, Home Use vs Hospital Device Cybersecurity Requirements, and Attack Tree Threat Modeling for Med Devices | Blue Goat.

That last row is the one with the most use. If the multi-patient harm view identifies a cloud path that can affect every deployed device, the risk file should rate the harm accordingly. When the two documents disagree about how bad something is, the submission tells two different stories.

Practical Advice on Drawing Them

Use whatever tool your team already uses. The FDA does not prescribe a notation, and a clear diagram in a common format beats a formal notation nobody on your team can maintain. What matters is legibility at submission resolution, consistent labeling, and a legend that explains your symbols.

Keep the views under version control alongside the design documentation, because they will change and a stale view is worse than a simple one. When an interface is added late in development, the views are the first thing that should be updated, since everything downstream references them.

Finally, write a short paragraph alongside each view explaining what it shows and what conclusions to draw. A reviewer who has to interpret a diagram unaided may interpret it differently than you intended.

How Blue Goat Cyber Approaches This

We build architecture views as the foundation of the submission rather than as an illustration added at the end, because the views determine what the threat model must cover and what the testing must include. That means working from your actual interfaces, marking trust boundaries you may not have drawn before, and making the multi-patient paths visible.

Our threat modeling engagements produce all four views alongside the threat analysis, and our medical device penetration testing scopes directly from them so the two documents agree.

Frequently Asked Questions

What are the FDA's security architecture views?

They are the architecture documentation the premarket cybersecurity guidance expects: a global system view showing the whole system and its boundaries, a multi-patient harm view showing where one failure affects many patients, an updateability and patchability view showing how the device changes after deployment, and security use case views showing specific security-relevant interactions step by step.

Can we submit one diagram instead of four views?

You can submit whatever you like, but a single diagram answers one of the four questions the views exist to answer. Reviewers use the views to cross-check the threat model, testing scope, and risk file, and a submission that provides only a general system diagram commonly receives a request for the missing views.

What is the multi-patient harm view for?

It identifies the paths through which a single compromise can affect more than one patient, such as cloud management APIs, configuration servers, firmware distribution, shared credentials, and hospital-side aggregation. It exists because the severity of a multi-patient event is categorically different from a single-device event, and the risk file should reflect that difference.

Does the FDA require a specific diagram format?

No. The guidance describes what the views must communicate, not which notation to use. Clarity matters more than formality: label every boundary and connection, include a legend, keep the diagrams readable at submission resolution, and add a short explanation of what each view shows.

How detailed should the updateability view be?

Detailed enough to show how an update is authenticated. That means the origin of the update, the signing process, where the verification key resides, what performs verification before installation, what happens when verification fails, and whether rollback is possible. An arrow labeled "OTA update" does not answer any of those questions.

How often should the views be updated?

Whenever an interface changes. The views sit upstream of the threat model, the test scope, and the labeling, so a stale view propagates errors into all three. Keeping them under version control with the design documentation is the practical way to avoid filing a submission whose diagrams describe an earlier revision of the device.

Need Views a Reviewer Can Follow?

We can turn your engineering diagrams into the four views the FDA expects, with trust boundaries labeled and the multi-patient paths made visible. Book a strategy session.

---

Blue Goat Cyber specializes in medical device cybersecurity, from threat modeling and penetration testing through premarket submission support. Our team works exclusively with device manufacturers preparing FDA submissions. Learn more about Christian Espinosa, our founder and CEO.