FDA Deficiency: Missing Security Architecture Views

What FDA reviewer language looks like

Paraphrased patterns from real deficiency letters. Not verbatim FDA quotes.

• Pattern 1

  The submission does not include all security architecture views described in the FDA's premarket cybersecurity guidance. Provide a Global System View, a Multi-Patient Harm View, and an Updateability View for the device under review.

• Pattern 2

  The provided architecture diagram does not clearly identify trust boundaries between the device, the customer network, and the manufacturer's cloud services. Update the architecture views so trust boundaries, data flows, and authentication points between components are explicit.

• Pattern 3

  The Updateability View does not describe the chain of trust used to verify software updates, including how update integrity and authenticity are confirmed on the device prior to installation.

Why this happens

• Engineering reuses a marketing or systems-engineering block diagram instead of producing a security-specific architecture view.
• Teams treat 'architecture' as a single artifact rather than the four-or-more distinct views the guidance calls out.
• Cloud and back-office components are excluded because the cyber package is scoped to 'the device,' even though they are inside the system trust boundary.
• The views do not show authentication points, key storage, or update verification because those details are buried in separate design documents.

How to fix it

• Produce four discrete views: Global System View (everything inside and adjacent to the trust boundary), Multi-Patient Harm View (paths by which one compromise reaches multiple patients), Updateability View (chain of trust for OTA/field updates), and Security Use Environment View (the network and operational context).
• Annotate every view with explicit trust boundaries, data flows (with directionality and protocol), authentication points, and key/credential storage locations.
• Show the manufacturer cloud, mobile apps, gateways, and service tools inside the system boundary if they touch device data or device control paths.
• Use the same component IDs across all views and link them to the SBOM and threat model so reviewers can trace a finding from architecture to control.

The Multi-Patient Harm View is the one teams forget

Of the four required views, the Multi-Patient Harm View is the most frequent cause of this deficiency. Many submissions include a global system view and an updateability view but provide nothing that lets a reviewer reason about how a single compromise (e.g. a stolen service credential, a compromised update server, a malicious SBOM component) could propagate to harm more than one patient. FDA expects this view to make explicit the shared infrastructure, shared keys, shared update channels, and any 'one-to-many' command paths in the system. If your device talks to a cloud, has a fleet management portal, or shares a manufacturing key across units, you need this view.

Architecture is the substrate the rest of the package rests on

Architecture views deficiencies rarely arrive in isolation. The threat model derives from the architecture; the cybersecurity risk assessment scores risks against the assets in the architecture; the penetration testing scope is bounded by the architecture; the post-market plan monitors components surfaced in the architecture. When the architecture is judged insufficient, every dependent artifact is implicitly suspect. Fix the architecture first and the supporting deficiencies often dissolve when reviewers re-read the package.

Standards involved

• FDA 2026FDA Premarket Cybersecurity Guidance (Feb 3, 2026)
• SPDFSecure Product Development Framework
• ANSI/AAMI SW96ANSI/AAMI SW96:2023 - Standard for Medical Device Security - Security Risk Management
• AAMI TIR57AAMI TIR57:2016 (R2023) - Principles for Medical Device Security - Risk Management

Already responding to this deficiency?

Our deficiency response engagement rebuilds the underlying artifact and produces a reviewer-ready response narrative.