FDA 2026 explicitly enumerates the architecture views a cyber-device submission must include: a Global System View, a Multi-Patient Harm View, an Updateability/Patchability View, and a view of the security use environment. A 'missing security architecture views' deficiency is written when a submission contains a single block diagram and calls it the architecture, or when the views provided do not depict trust boundaries, data flows, and the cybersecurity-relevant interfaces in a form a reviewer can analyze.
Paraphrased patterns from real deficiency letters. Not verbatim FDA quotes.
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.
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.
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.
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 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.
Already responding to this deficiency?
Our deficiency response engagement rebuilds the underlying artifact and produces a reviewer-ready response narrative.
FDA Cybersecurity Deficiency Response serviceBring us the letter. We will map a clean response and rebuild the underlying artifact to FDA 2026 expectations.
