Medical Device & SaMD

The Four Security Architecture Views, and What Actually Goes in Them

Bill Barksdale, CISSP

In short

FDA recommends four security architecture views: global system, multi-patient harm, updateability and patchability, and security use case. They are not four drawings of the same diagram. Each answers a question a reviewer has, and three of them are questions a single block diagram cannot answer.

Most companies answer this requirement with the system architecture diagram they already have. It is accurate, it is current, and it does not do the job.

That diagram was drawn to explain how the product works to the people building it. These four views are drawn to answer specific questions about how it fails, and about who is affected when it does. A drawing optimized for the first purpose does not incidentally serve the second.

FDA recommends four view categories, and the value of the recommendation is that each one is a question in disguise.

Global system view

What is the full extent of the thing, and where does trust change along the way?

This view holds the device plus everything it touches. Internal connections and external ones. The update infrastructure. The facility network it sits on. Intermediary devices and gateways. Cloud services and the third parties behind them. What you are drawing is trust boundaries and end-to-end connections, not a component decomposition, and the difference shows up in what you choose to collapse. A subsystem with no external interface can be one box. A wire that crosses an ownership boundary cannot be left implicit.

The most common omission is the update infrastructure. It does not feel like part of the product - it is a build server, a signing process, a distribution mechanism - and it is the most privileged path into every unit in the field. Leave it off and the view describes a system that cannot be updated, which is a different product from the one you are submitting.

Multi-patient harm view

Can compromising one unit hurt more than one patient?

That question is not answerable from a block diagram, and it is the question a reviewer most wants answered, because it is the difference between a device problem and a fleet problem. The view has to show propagation paths - how access to one thing becomes access to another - and the controls that break them. Segmentation. Per-unit credentials. Rate limiting. Authorization that runs server-side rather than in a client anyone can modify.

If your position is that multi-patient harm cannot happen, this is the diagram where you demonstrate it. Demonstration means showing the paths and showing what stops each one. An assertion in prose that units are isolated is what this view exists to replace.

A shared credential is the cleanest case for why the view exists at all, because it collapses every propagation path on the diagram into a single arrow that reaches every unit in the field. One credential, every device, is what the CISA advisory I went through describes, and the multi-patient consequence is the whole of why that advisory matters rather than a detail of it.

Nobody picks a shared credential on the merits. It is a go-fast decision. There is a deadline, or the thing is only a proof of concept, or something just has to work by Thursday. Standing up a secrets store takes time and makes the code more complicated. Hard-coding an account you already have, or creating one by hand and pasting the password into the source, takes an afternoon. Given unlimited time we would all take every precaution, and we are never given unlimited time - "we will come back and secure it later" is an extremely convincing thing to say to yourself while in a hurry.

None of that reasoning survives being drawn. A paragraph can leave the credential model unstated. An arrow that reaches every unit in the field cannot.

Updateability and patchability view

If you had to ship a fix tomorrow, what would actually happen?

Draw it end to end. Where the signing key lives and who can reach it. How the artifact travels from the build server to the field. What the device checks before it applies anything, and in what order. What happens when an update fails halfway through, and what state the device is in while that is true. Whether there is a rollback, and whether the rollback can be induced by an attacker who wants an older version with a known hole in it.

This is the view most likely to expose a real design gap while it is being drawn, and the reason is structural rather than accidental. The update path is usually the least reviewed part of a product and it carries the most privilege. It gets built once, early, by whoever was available, and then it works, so nobody looks at it again.

Security use case views

What is the product doing right now, and who is allowed to do what while it does that?

Security posture is not constant across a device's operational states, so one view per state and per clinical use case is the expectation. Normal operation. Servicing. Provisioning. Degraded or fallback mode. End of life and decommissioning.

Vulnerabilities cluster in the states nobody diagrams. Servicing and provisioning are where credentials appear, where interfaces are enabled that are closed the rest of the time, and where a human being is standing in front of the device with a laptop and a deadline. Degraded mode is where fallback behavior that was designed for safety turns out to also be a way around a control. End of life is where the data goes somewhere and the credentials often do not get revoked.

How many of each

Complexity sets the count, not a template.

A simple device with a single hardware connection likely needs one of each view, and a small set of use case views. A wirelessly connected platform may need several multi-patient harm views and several updateability views, because there is more than one route to multi-patient harm and more than one thing in the system that gets updated - device firmware, a companion app, a gateway, a server-side service, each on its own pipeline with its own signing story.

The test is whether a reader can find the answer to each of the four questions. If one diagram tries to carry two answers, it usually carries neither.

The views have to trace to something

The part that gets missed: these are not illustrations of the architecture section.

The views are expected to identify security-relevant system elements and interfaces, define the security context, domains, boundaries and external interfaces, align to your security objectives and requirements, and establish traceability from architecture elements to user and system security requirements. That last clause is doing real work. An element on the diagram that traces to no requirement is either unnecessary or ungoverned. A requirement that appears nowhere in any view is controlling something you have not drawn.

Both are gaps, and surfacing them is the point of the exercise rather than a side effect of it. Run the trace in both directions once the views are drawn and the requirements are written, and expect to find something.

Draw them to find out what you do not know

Teams treat these views as documentation of decisions already made, which is why they feel like overhead and get delegated to whoever is least busy.

They are more useful as an analysis technique. The reliable experience is sitting down to draw the update path, getting three boxes in, and discovering that nobody in the room can say with confidence what the device verifies before it applies an image. That is not a documentation problem you found. It is a design question you had not asked, and it surfaced because a diagram will not let you be vague in the way a paragraph will.

Build them alongside the threat model rather than after it, and build them early enough that what you find is still cheap to change.

This is engineering guidance, not legal or regulatory advice.

This is the work I do - FDA cybersecurity submissions, penetration test remediation, and security ownership for companies too small for a full-time CISO. bill@bato.com.

This is the work I do — FDA cybersecurity submissions, penetration test remediation, and security ownership for companies too small for a full-time CISO. bill@bato.com.

Common questions

Can these be part of our threat model documentation?

Yes. FDA allows the views to be provided as part of the threat modeling documentation, and in practice they are built together, because drawing trust boundaries and enumerating threats against them is one activity rather than two.

What tool should we use?

Any of them. Legibility and accuracy are what a reviewer evaluates, and neither is a property of the drawing package. A view that is current and readable beats a beautiful one that describes last year's architecture.

Our device has one USB port and nothing else. How much is this?

You likely need one of each view, and the security use case set will be small. Fewer diagrams, the same four questions. Scope scales with complexity; the questions do not go away.

Do we need to redraw these for every submission?

You need them to be current. A view describing a previous architecture is worse than no view at all, because a missing diagram is a gap and an inaccurate one is a claim. Reviewers treat those differently, and so does anyone reading it after an incident.

We are SaMD, with no hardware anywhere. Do the four still apply?

The same four. Global system spans your services and the third parties you call, multi-patient harm is your tenancy and authorization model, updateability is your deployment pipeline, and the use case views are your operational states.

What Does FDA Actually Want in a Threat Model?Why Your Security Risk Assessment Cannot Live in Your 14971 File Your Security Controls Are Not Requirements Yet One Credential, Every Device: Reading a CISA Advisory as a Design Failure

← More in Medical Device & SaMD