Master Data Flow Diagrams for Medical Devices: 4 Critical Components

A data flow diagram (DFD) is a key ingredient in identifying cybersecurity risks in medical devices. The DFD helps you understand where data goes, how it gets there, and where it's stored. That's why data flow diagrams for medical devices are so important. They give your team a clear picture of how information moves through the system and where potential security risks may exist.

Mapping is thorough. It covers:

• External entities of a system
• Processes
• Data stores
• Data flows

The DFD is especially useful for threat modeling. It identifies trust boundaries. These show where data crosses between systems or components with different levels of trust. Why are they important? Because without them, your diagram may show how the system works, but it won't tell you much about where security problems could develop.

It should be pointed out that the FDA's February 2026 premarket cybersecurity guidance doesn't specifically require a DFD. Still, the recommendations of this guidance for threat modeling (Section V.A.1) and security architecture views (Section V.B.2 and Appendix 2) rely on the same kind of system information.

In this article you will discover the components of a medical device DFD. Also, you can learn how to build a DFD. And, most importantly, learn how a DFD supports the cybersecurity documentation FDA reviewers expect to see.

Why the DFD comes first

Before you can identify cybersecurity threats, you need a clear picture of the system you're trying to protect.

That's the idea behind DFD threat modeling. You start by mapping the system's components, connections, and trust boundaries. Then you use that information to identify where security problems might occur.

Threat modeling starts with four questions. The first is simple: "What are we working on?" The MITRE and MDIC Playbook for Threat Modeling Medical Devices, which FDA references as an educational resource, recommends using a data flow diagram (DFD) to answer that question.

A DFD shows the entities involved in operating a medical device, how they interact, and where the team assumes trust boundaries exist.

This matters for two reasons.

First, STRIDE, one of the most widely used threat modeling methods, examines individual elements of a DFD to identify what could go wrong. If something is missing from your diagram, it could also be missing from your threat assessment.

Second, FDA's premarket cybersecurity guidance addresses architecture diagrams in Appendix 2. It identifies DFDs as one acceptable method and calls for explanatory text describing the sequence of processes or protocol steps in detail.

That means your DFD can serve more than one purpose. Add the necessary detail, and you can use it to support the Global System View in your FDA submission. There's no need to start from scratch each time.

The four components

The MITRE and MDIC playbook uses DFD3 notation, which relies on a handful of simple shapes. The idea is to make diagrams easy to follow during design reviews, even when someone prints them in black and white.

Here's what goes into a DFD:

• External entities: These appear as rectangles with sharp corners. Think patients, clinicians, service technicians, hospital networks, app stores, cloud providers, and connected electronic health record (EHR) systems. They're outside your control, so you show how they interact with your system without trying to map their internal workings.
• Processes: Rounded rectangles represent running software. Examples include device firmware, sensor-processing tasks, Bluetooth stacks, companion apps, cloud services, and update servers. If your team develops or ships the code, it belongs here.
• Data stores: These use drum-shaped symbols to show where information is kept. That includes device flash memory, credential stores, local app databases, cloud storage, log files, and backups.
• Data flows: Arrows show how information moves between processes, external entities, and data stores. Examples include Bluetooth Low Energy (BLE) connections, HTTPS sessions, USB provisioning connections, and firmware downloads. Double-headed arrows are common because communication usually goes both ways.

Make sure every element has a label. You can also group related processes and data stores inside a larger device shape to keep the diagram readable.

Pay attention to the direction of communication, too. If it matters which component starts a connection, show that. Use a one-way arrow only when traffic genuinely travels in one direction, such as a UDP broadcast.

The fifth component: trust boundaries

The first four components tell you how your medical device system works. Trust boundaries help you identify where security problems might occur.

When you're identifying trust boundaries in a medical device, you're looking for places where data moves between components with different levels of trust. These boundaries can reveal potential security weaknesses that might otherwise go unnoticed.

The MITRE and MDIC playbook represents these boundaries as closed shapes with dashed lines. They're not necessarily physical barriers. Instead, they reflect your team's assumptions about which components can communicate and what level of trust exists between them.

So where should you draw them?

• Where security controls exist or should exist. Authentication, access control lists, Bluetooth pairing, firewalls, and physical locks are all reasons to consider a trust boundary.
• Where data or code moves beyond your control. Examples include a patient's smartphone, an app store, a hospital network, or cloud services managed by another company.
• Where someone could bypass normal security controls. A sealed device enclosure or an exposed debug header may create a boundary even if legitimate users never interact with it.
• Where a failure could affect another component. For example, separating external interfaces from the control plane and core operating system helps you assess what might happen if the Bluetooth stack crashes or is compromised.

One important detail: Always draw trust boundaries as complete, closed shapes. A partial line makes it difficult to tell which components are inside the boundary and which are outside.

You should also investigate boundaries that don't have a data flow crossing them. The playbook points out that these may indicate communication paths that haven't been documented or evaluated. Physical access to a port, an untrusted sensor input, or a service connection could be involved.

The playbook illustrates this using two levels of detail.

At the system level, it separates components the organization controls from those it doesn't. The medical device, companion app, and cloud environment each have their own boundaries.

At the device level, the diagram goes deeper. Separate boundaries surround the external interfaces, control plane, and core operating system, including its flash storage.

Both views are worth keeping. The system-level diagram helps you understand the broader environment, while the device-level diagram gives you the detail needed to examine individual components and their security risks.

How to build one for a medical device

You don't need to map every detail of your medical device on the first attempt. Start with the big picture, then work your way down to the individual components and connections.

The MITRE and MDIC playbook recommends an iterative approach. Here's how to put it into practice.

1. Start with the major components. Use your product requirements to identify the device, companion app, cloud services, and update infrastructure. Draw a box for each and connect the ones that communicate. The playbook's first example uses just three boxes, but it establishes an important detail: The device doesn't communicate directly with the cloud.
2. Include everyone who interacts with the device. Think beyond patients and clinicians. Service technicians, manufacturing personnel, contract manufacturers responsible for provisioning keys, and app stores may all play a role. Section V.A.1 of FDA's guidance calls for threat modeling that considers supply chain, manufacturing, deployment, maintenance, and decommissioning risks. You need these actors on the diagram to identify the threats associated with them.
3. Identify how data moves. Label each connection with its communication protocol or interface, such as Bluetooth Low Energy (BLE), Wi-Fi, cellular, USB, JTAG, or HTTPS. These details help you evaluate encryption, authentication, and what happens when a connection fails.
4. Show where information is stored. Include data stores on the device, in the companion app, and in the cloud. Don't overlook credentials, encryption keys, logs, or patient readings. These are important when evaluating information disclosure threats.
5. Add the trust boundaries. Begin by separating the components your organization controls from those it doesn't. Then identify boundaries within the device itself. Check whether your planned security controls are positioned at the appropriate boundaries.
6. Document your assumptions. Don't leave reviewers guessing about the conditions you considered. For example, FDA's guidance describes an attacker who controls a hospital network and can modify, drop, or replay packets. You might also assume a patient's phone is rooted or that your cloud provider secures the hypervisor while your team is responsible for the software above it. Write these assumptions alongside the diagram.
7. Review the diagram for missing pieces. Compare it against your product requirements and lifecycle activities. Does it show every interface, every relevant actor, and every location where data is stored? The playbook recommends checking completeness before moving forward. If your STRIDE sessions repeatedly uncover threats involving components that aren't shown, you probably need to revise the DFD.

And don't expect the first version to be the last.

The playbook treats DFD development as an iterative process. As the design changes, the diagram needs to change with it. Otherwise, you risk submitting a threat model that no longer reflects the device you're building. That can raise questions during FDA review and potentially contribute to a deficiency letter.

From DFD to the documents FDA reads

Once you've completed your DFD, you can use it to support several parts of your FDA cybersecurity documentation. In fact, much of the information you've already collected can be reused rather than recreated.

Here's where it fits.

1. It provides the starting point for STRIDE.

STRIDE uses six threat categories, with different questions applied to different DFD element types. Flows that cross trust boundaries deserve particular attention because they may expose components to less-trusted systems.

Our STRIDE for medical devices post explains how to run a session. For a deeper look at the methodology, see the STRIDE threat modeling guide.

2. It supports the Global System View.

Section V.B.2 of FDA's guidance calls for a Global System View showing the complete medical device system and its internal and external connections.

When preparing FDA architecture views and diagrams, your goal is to show reviewers how the different parts of your medical device system communicate and where cybersecurity controls come into play.

That includes update infrastructure, facility networks, intermediary devices, cloud connections, and the potential impact of home networks.

Your top-level DFD provides the foundation. But FDA expects more than a collection of connected boxes.

Appendix 2 describes the additional information that should accompany each communication path, including:

• Protocol names and versions
• Ports and communication channels
• Whether the connection carries data, software code, or commands
• Authentication methods and their strength
• How communication sessions are established and terminated
• How credentials are generated and stored
• What happens if a connection fails during a transfer

These details help reviewers understand not just how components communicate, but how those communications are secured.

Our article on the architecture security view explains how to develop this documentation. You can also read our book chapter on security architecture views to see how FDA's four recommended views work together.

3. It helps define the other architecture views.

Your DFD can also serve as the starting point for three additional views described in FDA's guidance.

• Updatability and Patchability View: Follow the software update process from beginning to end, including connections and infrastructure outside your organization's control.
• Security Use Case View: Focus on the components and data flows involved in a particular clinical function.
• Multi-Patient Harm View: Identify shared data flows, services, and storage that could allow a cybersecurity problem to affect multiple patients or devices.

You don't have to create entirely separate diagrams if the information is already there.

FDA's guidance explains that when threat modeling documentation adequately captures a required architecture view, duplicating that information isn't necessary.

The important thing is completeness. A DFD with the appropriate Appendix 2 details can support both threat modeling and the applicable security architecture views.

Common mistakes

Even an experienced engineering team can overlook important details when building a DFD. Here are six mistakes worth watching for.

• Confusing a hardware diagram with a DFD. A hardware block diagram shows components such as chips and buses. A DFD follows the information moving between them. For example, a reviewer should be able to trace a sensor reading from the device to the cloud.
• Leaving out systems you don't control. Hospital networks, patient smartphones, and cloud providers still belong on the diagram. These external connections often introduce some of the most important cybersecurity risks.
• Drawing incomplete trust boundaries. A dashed line running across the page doesn't clearly establish what's inside or outside a boundary. Use a closed shape so there's no confusion.
• Forgetting lifecycle activities. Manufacturing, provisioning, servicing, and decommissioning all create potential security exposures. Think about where encryption keys are loaded, how devices are maintained, and what happens to stored data when a device is retired. If these activities aren't represented, their associated threats may be missed.
• Trying to fit everything into one diagram. A system-level view is useful for showing major components and connections, but it won't capture every internal process. Use a top-level DFD and additional diagrams for individual trust boundaries. Keep element identifiers consistent so you can trace information between views.
• Letting the diagram become outdated. A DFD prepared early in development may no longer reflect the final device. Keep the diagram's source files under version control alongside your software so changes can be tracked. The version included in your FDA submission should accurately represent the device you intend to market.

Tools

You don't need specialized software to create data flow diagrams for medical devices. Tools such as draw.io, Lucidchart, and Visio can all do the job.

If your team prefers keeping diagrams alongside its code, consider text-based options such as Mermaid or PlantUML. These let engineers store diagrams in the same repository as the software and review changes through pull requests.

For teams that want threat modeling built into the process, the Microsoft Threat Modeling Tool and OWASP Threat Dragon support DFDs with STRIDE analysis.

The best choice comes down to how your team works. A sophisticated diagramming tool won't help much if nobody updates the diagrams. Pick something your engineers already use and can easily maintain as the design evolves.

Start with the diagram

A good DFD does more than show how your medical device handles data. It gives your team a starting point for the cybersecurity work that follows, including STRIDE analysis, FDA security architecture views, and penetration testing.

The goal isn't to create a perfect diagram on the first attempt. It's to build one that accurately represents your system and stays useful as the design changes.

For a closer look at how DFDs fit into the larger process, read our article on threat modeling for cloud-connected medical devices or the book chapter on threat modeling.

Need help with your data flow diagrams and threat model? Our FDA cybersecurity documentation service builds them, and penetration testing checks the boundaries hold. Email us at info@cybermed.ai.

Sources

• FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance, February 3, 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
• MITRE and MDIC. Playbook for Threat Modeling Medical Devices, November 2021. https://www.mitre.org/news-insights/publication/playbook-threat-modeling-medical-devices
• Adam Shostack. DFD3 notation. https://github.com/adamshostack/DFD3
• AAMI TIR57:2016 (R2023). Principles for medical device security, Risk management.