Data Flow Diagrams for Medical Device Security

Why this matters

The FDA's Feb 3, 2026 final premarket cybersecurity guidance expects a coherent story: a threat model, a security risk assessment, security architecture views, and verification testing that all map to the same underlying system definition. The DFD is that system definition. When teams skip it, the threat model lists threats that have no diagram element to attach to, the architecture views show components the threat model never analyzed, and verification testing exercises interfaces nobody documented.

AAMI TIR57 (now supplemented by ANSI/AAMI SW96:2023):2016/(R)2023 calls out data flow modeling as a foundation of medical device security risk management. IEC 81001-5-1:2021 requires that security activities be traceable to system architecture. The DFD is the artifact that lets you produce that traceability without re-modeling the system three times.

What is a data flow diagram in a medical device context?

A data flow diagram is a structured model that shows how data moves through your device ecosystem, where it stops, who or what acts on it, and where trust changes. For a connected medical device, the ecosystem typically includes the device itself, a companion mobile or desktop app, cloud APIs, an update server, hospital network connectivity, and identity or key management services.

A DFD is not a network diagram, a UML sequence diagram, or a marketing architecture slide. It is an analysis tool. Its job is to make every place data is created, transformed, stored, or transmitted visible, so you can reason about confidentiality, integrity, and availability at each one.

The five elements of a DFD

Every DFD element falls into one of five categories. Using consistent shapes across your team prevents the "what does this box mean?" problem that wrecks reviews.

• External entity (rectangle): an actor or system outside your trust boundary. A clinician, a patient, a hospital EHR, a third-party analytics platform.
• Process (circle): a transformation of data. Authenticating a session, validating a command, computing a therapy parameter, signing a telemetry packet.
• Data store (parallel lines): persistent storage. Device flash, app local storage, cloud database, log files, key material at rest.
• Data flow (directional arrow): data moving between two elements. Always labeled with what is moving (PHI, commands, firmware images, telemetry).
• Trust boundary (dashed line): the place where your security assumptions change. Device-to-app over BLE, app-to-cloud over TLS, cloud-to-third-party API, service mode vs production mode.

DFD vs Security Architecture Views vs threat model

These three artifacts get conflated constantly. They are not the same and they are not interchangeable.

The DFD is the substrate. The architecture views are higher-level abstractions drawn from the same underlying system. The threat model is the analysis layered on top of the DFD. If you maintain only one of these and try to derive the others on the fly, they drift. Maintain the DFD as the source of truth and regenerate the views and threat model from it.

For the FDA's four architecture views in detail, see FDA Security Architecture Views for medical devices. For the threat modeling method, see STRIDE threat modeling for medical devices.

How to build a DFD for a connected medical device

Step 1: Define scope in one sentence

Write a single sentence describing what is in scope. Example: "The implanted device, its companion mobile app, the cloud telemetry service, the OTA update server, and the clinician programmer." If a component can influence patient safety or handle regulated data, it is in scope until you can justify excluding it.

Step 2: Draw the Level 0 (context) diagram

One process in the middle representing the entire system. External entities around it: patient, clinician, hospital network, third-party services. Label every data flow with what is moving and over what interface. Place trust boundaries between the system and each external entity.

Step 3: Decompose to Level 1

Expand the single process into the major subsystems: device firmware, companion app, cloud API, update service, key management. Add internal data stores (device flash, app DB, cloud DB, key vault). Add trust boundaries between subsystems where the security assumptions change.

Step 4: Decompose to Level 2 only where risk is concentrated

See also: Security Architecture Views: The FDA's Four Required Diagrams, Home Use vs Hospital Device Cybersecurity Requirements, and FDA AI Cybersecurity Threats: 7 Attacks.

Most submissions do not need a full Level 2 DFD of every subsystem. Decompose further only where you have safety-critical workflows: therapy command processing, firmware update verification, clinician authentication, remote service access.

Step 5: Version-control the DFD

The DFD must be a living artifact under change control. When you add a new interface, a new third-party dependency, or a new cloud service, the DFD updates first and the downstream threat model and architecture views update next.

How DFDs feed STRIDE and the FDA submission

DFD to STRIDE in one step: Every DFD element type maps to a fixed subset of STRIDE categories. Walk the diagram element by element, apply the categories below, and you have a first-pass threat model with no guesswork. External entities get Spoofing and Repudiation. Processes get all six. Data stores get Tampering, Repudiation, Information disclosure, and Denial of service. Data flows get Tampering, Information disclosure, and Denial of service. Trust boundaries tell you which flows need the strongest controls. See STRIDE threat modeling for medical devices for the per-category threat tables.

STRIDE walks each DFD element and asks six questions: can it be spoofed, tampered with, repudiated, disclosed, denied, or elevated? The mapping is deterministic:

That mapping is why STRIDE without a DFD produces a generic threat list. With a DFD, every threat is attached to a specific element, every mitigation is attached to a specific control, and every control is testable.

For the FDA submission, the DFD shows up indirectly in several places. The threat model attachment references DFD elements. The security architecture views are higher-level abstractions of the same system. The verification testing plan exercises the interfaces and trust boundaries the DFD identified. The SBOM impact analysis uses the DFD to determine which third-party components are reachable from which trust zones. For how all of this fits the eSTAR v7.0 submission package, see the FDA's 18 cybersecurity deliverables.

Common DFD mistakes that trigger FDA questions

• Missing trust boundaries. The diagram shows components but not where trust changes. Reviewers cannot tell where you authenticate, encrypt, or validate integrity.
• Unlabeled data flows. "An arrow" is not a data flow. Each arrow needs the data type, the interface, and the direction.
• Treating the cloud as one box. "Cloud" is not a DFD element. Decompose into API gateway, application servers, database, key store, third-party integrations, and update distribution.
• Forgetting the update path end-to-end. Build, sign, distribute, verify, install, rollback. Every step is a DFD element with its own threats.
• Service mode invisibility. Field service tools, debug ports, and manufacturing modes are real interfaces. If they exist, they belong on the DFD.
• No version control. A DFD that has not been updated since the original submission is a postmarket finding waiting to happen.

How Blue Goat approaches DFDs

We build DFDs as the foundation of every FDA premarket threat modeling engagement, not as a deliverable produced after the fact. Our team includes CISSP and OSCP-credentialed engineers with ex-military red team experience, and we have built DFDs for implantables, wearables, surgical robotics, IVDs, and SaMD across hundreds of FDA submissions. The DFD we deliver is the same artifact our threat modelers, pen testers, and submission reviewers work from, which is what makes the downstream artifacts consistent.

If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. See our medical device threat modeling services for how DFDs fit our engagement model.

Book a Discovery Session to discuss your device architecture and submission timeline.

FAQ

What is a data flow diagram for a medical device?

A data flow diagram is a structured model of every process, data store, external entity, data flow, and trust boundary in a medical device's ecosystem. It is the foundational artifact for STRIDE threat modeling and for tracing the FDA's Security Architecture Views back to a consistent system definition.

How is a DFD different from a security architecture view?

A DFD is a low-level analysis model showing data movement and trust boundaries. The FDA's Security Architecture Views are higher-level abstractions (global system, multi-patient harm, updateability, security use cases) that describe how the system is architected for security. Both should be traceable to the same underlying system, but they answer different questions.

Do we need a DFD for an FDA submission?

The FDA's Feb 3, 2026 final premarket cybersecurity guidance does not name "DFD" as a required deliverable. However, the threat model, security risk assessment, and architecture views all assume a coherent system definition. A DFD is the simplest way to produce one, and reviewers expect to see that traceability.

What level of DFD detail does the FDA expect?

Most submissions need a Level 0 (context) and Level 1 (major subsystems) DFD. Level 2 decomposition is appropriate for safety-critical workflows like therapy commands, firmware updates, and clinician authentication. Decompose further only where risk is concentrated.

What tool should we use to draw DFDs?

Use any tool your team will maintain: draw.io, Lucidchart, Visio, or a Threat Modeling Tool like OWASP Threat Dragon. The tool matters less than versioning the diagram in source control and updating it before the downstream threat model and architecture views.

How often should we update the DFD?

Update the DFD whenever a new interface, third-party dependency, cloud service, or trust boundary is introduced. Treat it as the source of truth: the threat model and architecture views are regenerated from it, not maintained in parallel.