Updated November 19, 2025
Cybersecurity used to be an afterthought in the medical device world. Not anymore. The devices we rely on today—infusion pumps, wireless wearables, implantables, cloud-managed sensors—operate more like miniature distributed systems than traditional equipment. And with that shift, the FDA has become very clear: cybersecurity is now part of device safety, not a separate concern.
In its 2025 Cybersecurity in Medical Devices guidance, the FDA highlights four Security Architecture Views manufacturers should present in their submissions. These views aren’t just paperwork—they’re a way to demonstrate that you understand how your device behaves within a real, modern ecosystem.
Below, we walk through each of the four views, providing practical examples and commentary based on our experience working with medical device manufacturers on a daily basis.
1. Global System View
If you’ve ever diagrammed your device ecosystem and thought, “Wow, this is more complicated than it looked in my head,” you already understand why the FDA requires this view.
What the FDA’s looking for
A solid Global System View shows:
- every hardware and software component
- where data flows
- what connects to what (and why)
- trust boundaries between internal and external systems
- mobile apps, cloud platforms, hospital networks, and third-party integrations
- authentication, encryption, and session handling across connections
It’s not just a device diagram—it’s a map of the entire ecosystem your device depends on.
A practical example
Take a wireless insulin pump. It might:
- talk to a Continuous Glucose Monitor over BLE
- sync with a mobile app
- push telemetry to a cloud analytics service
- allow clinicians to view readings remotely in a dashboard
Each of those connections is a potential entry point, data path, and risk vector.
In our experience at Blue Goat Cyber, this is where manufacturers tend to underestimate the number of “hidden” interactions—debug ports, intermediate servers, legacy protocols—until the diagram forces them into the open.
2. Multi-Patient Harm View
This view exists because one compromised device is bad, but one compromised system is catastrophic.
What the FDA expects
Manufacturers must show:
- how a cyber event could affect multiple patients
- which shared components (cloud, gateways, networks) could propagate risk
- whether the device’s functionality could be hijacked or modified at scale
- how the design contains blast radius and prevents cascading harm
A real-world scenario
Imagine a cloud-managed telemetry system used in an ICU. If the cloud platform were compromised—or even just misconfigured—all connected monitors could start displaying delayed or inaccurate vitals. Clinicians might not immediately notice, and that’s where safety risk escalates quickly.
The FDA wants proof that you’ve analyzed those systemic interactions—not just the device in isolation.
Blue Goat’s experience
We’ve reviewed systems where a single shared update service, if compromised, could alter medication doses across dozens of infusion pumps. Manufacturers are often surprised when they see how one weak link can ripple out across an entire patient population.
3. Updateability & Patchability View
Cyber threats evolve faster than any device lifecycle. If your device can’t be updated safely and reliably, the FDA will flag it.
What needs to be demonstrated
This view should show:
- how updates are built, packaged, signed, and transported
- how the device verifies them
- rollback behavior if something goes wrong
- logging of update attempts and failures
- how clinicians and patients are notified
- long-term support for third-party components in the SBOM
Example: Firmware updates for an implantable cardiac device
An implantable ICD may receive updates through a home transmitter that relays firmware over a secure channel. The update process must:
- cryptographically validate firmware
- place the device in a safe update mode
- keep the patient’s immediate safety as priority
- fall back to a known-good firmware if validation fails
- log all update events for regulatory and forensic use
If any part of that process is unclear or fragile, the FDA will request additional details.
Why this matters so much
We’ve helped several manufacturers address this exact issue. The sticking point is often not the cryptography—it’s the operational details:
“How do we ensure updates don’t disrupt a device mid-treatment?”
“How do we maintain update servers for a decade?”
“How do we plan for third-party library end-of-life?”
These are the questions FDA reviewers are now asking.
4. Security Use Case Views
If the first three views set the stage, the Security Use Case Views zoom in on the action.
These views demonstrate how security controls function during real workflows—not just theoretically.
What the FDA wants to see
- detailed call-flow or sequence diagrams
- authentication and authorization steps
- how the device handles invalid or malicious input
- how commands travel through the system
- how logs are generated
- how sessions are established and terminated
- failure / attack handling behavior
Example: Remote programming of an infusion pump
A typical secure programming sequence might look like this:
- Clinician authenticates to a workstation.
- Workstation authenticates to the pump using certificates.
- Commands are cryptographically signed before transmission.
- Pump validates signatures, checks clinician role, and confirms safe-state.
- Any anomalies (e.g. unsigned commands, replay attempts) are automatically rejected.
- Every action is logged locally and centrally for auditing.
This view is where the FDA verifies that your security controls actually work in the real world.
Our observation
This is also where attackers focus. If a device has a solid architecture but weak command validation, session management, or logging, a compromise is still realistic. Including strong Security Use Case Views shows the FDA you’ve addressed these practical attack vectors.
How Blue Goat Cyber Helps Manufacturers Prepare These Views
Through hands-on device assessments and regulatory preparation, we help manufacturers create FDA-ready cybersecurity documentation that holds up under scrutiny.
Our areas of expertise include:
- Secure Product Development Framework (SPDF) design
- Threat modeling aligned with FDA expectations
- SBOM creation and verification
- Detailed architecture diagrams
- Cybersecurity risk assessments
- Medical device penetration testing
- Cloud/mobile ecosystem security assessments
- TPLC cybersecurity program development
Under the leadership of Christian Espinosa, we’ve supported devices across cardiovascular, diagnostic imaging, remote monitoring, and surgical robotics categories.
Conclusion
The FDA’s Security Architecture Views offer a structured way to demonstrate that your device is secure by design—not secured as an afterthought. With clear examples and practical insights, these views help you communicate exactly how your device protects patients, withstands cyber threats, and operates safely in complex environments.
If your next submission includes connected capabilities, cloud components, or mobile apps, these views are essential. Blue Goat Cyber can help you assemble them in a way that reflects real-world operation and stands up to regulatory review.
Medical Device Security Architecture View FAQs
- Global System View
- Multi-Patient Harm View
- Updateability and Patchability View
- Security Use Case Views
These views collectively demonstrate how cybersecurity is integrated into the medical device design and its operating environment.
The Global System View provides a high-level diagram of the medical device and its ecosystem, including all connected components such as cloud services, mobile apps, hospital networks, and other systems. It helps reviewers understand data flows, trust boundaries, and external dependencies.
This view addresses risks where a cybersecurity event could impact multiple patients at once—such as shared cloud platforms or remote management systems. It shows how your device architecture prevents or mitigates systemic, widespread harm.
This view shows how the medical device can receive security updates and patches after deployment. It includes mechanisms for secure update delivery, authentication, rollback prevention, and timelines for applying patches—key to lifecycle risk management.
Security Use Case Views present operational scenarios (e.g., authentication, remote connection, or data transfer) that illustrate how the device enforces security during normal and edge-case usage. These views demonstrate that security controls are functional, effective, and well-integrated in real-world conditions.
Each view should be detailed enough to clearly illustrate security controls, data flows, access points, and risk mitigation strategies. The FDA expects enough granularity to understand how vulnerabilities are prevented, detected, and managed across the system.
Yes. The Global System View must include all software modules, cloud services, APIs, and third-party platforms the device interacts with. This ensures the FDA can evaluate external risk exposure and trust boundaries.
You can use standard modeling tools such as Microsoft Visio, Lucidchart, or UML-based design tools. The key is clarity—diagrams should be easy to interpret and supported by explanatory text to meet FDA expectations.
Yes. While primarily part of premarket submissions, this view also supports FDA postmarket expectations by showing how your device maintains cybersecurity throughout its lifecycle via secure updates and patching procedures.
These views demonstrate that cybersecurity has been integrated across the device ecosystem—not just the embedded software. They show the FDA how your device prevents unauthorized access, protects data integrity, and minimizes risk across interconnected components.