Design FMEA for Medical Devices: dFMEA

Updated September 24, 2026

Skipping a rigorous dFMEA is the fastest way to earn a cybersecurity Additional Information (AI) request. Reviewers under Section 524B of the FD&C Act expect a documented line from every remote-exploitable failure mode back to a patient-harm scenario in the ISO 14971 risk file, and forward to a mitigating design control tested during V&V.

The dFMEA is where that line starts. When it is missing, incomplete, or disconnected from the threat model, the AAMI TIR57 / ANSI/AAMI SW96:2023 residual-risk table has nothing credible to anchor to, and the submission stalls.

This guide walks through how to scope, run, and integrate a dFMEA that satisfies both the safety and cybersecurity halves of a premarket submission.

Why this matters

The FDA's Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (Feb 3, 2026 final guidance) explicitly ties security risk analysis to the ISO 14971 safety risk file. Reviewers now expect the dFMEA, the AAMI TIR57 / ANSI/AAMI SW96:2023 threat model, and the ISO 14971 hazard analysis to reference the same failure modes with the same severity ratings.

The FDA's FY2025 MDUFA Performance Report lists cybersecurity among the subject-matter expert areas that may be involved in reviewing a device submission, alongside sterility, biocompatibility, and software. When the dFMEA scores a network failure mode as Severity 2 but the TIR57 threat model scores the same exploit as catastrophic, that inconsistency alone is enough to trigger an AI cycle.

ANSI/AAMI SW96:2023 and IEC 81001-5-1 both reinforce this integration: security risk-management activities are expected to feed the same design-controls process as safety risk-management activities. A stand-alone dFMEA that never touches the threat model is a red flag.

What is a dFMEA and how does it differ from pFMEA and uFMEA?

A dFMEA analyzes failure modes inherent to the design itself, components, interfaces, algorithms, and communication paths. It answers the question, "How can this design fail to deliver its intended function?"

A pFMEA analyzes manufacturing and assembly processes, and a uFMEA analyzes user-interaction failure modes tied to IEC 62366-1 usability engineering. All three feed the ISO 14971 risk file, but each has a distinct scope and reviewer expectation.

For a connected device, the dFMEA is the artifact that must include cyber failure modes.

How does a dFMEA connect to ISO 14971 for medical devices?

Every failure mode with a plausible sequence of events leading to patient harm becomes a hazardous situation in the ISO 14971 hazard analysis. The dFMEA severity score and the ISO 14971 harm severity must use the same scale, a common cause of AI letters is a five-point RPN scale in the dFMEA that never reconciles with a three-point severity scale in the risk file.

Practically, the dFMEA row identifies the failure mode; the ISO 14971 hazard analysis identifies the harm and the risk control. The design control listed in the risk file must appear in the dFMEA's "current controls" column, and the V&V test that verifies it must be traceable in both.

How do you add cybersecurity failure modes to a dFMEA?

Start by enumerating every external interface: wireless stacks (Bluetooth, Wi-Fi, cellular), wired ports (USB, Ethernet), removable media, firmware update channels, cloud APIs, and clinician-facing UIs. For each, add rows covering the CIA triad, confidentiality, integrity, and availability failures.

Typical cyber failure modes on a connected device include:

• Unauthenticated command injection over the network interface causing therapy delivery outside prescribed parameters
• Firmware update tampering causing execution of unsigned code
• Denial-of-service on the wireless stack causing loss of alarm annunciation
• Credential leakage causing unauthorized clinician-role escalation
• Session replay on the cloud API causing duplicate dose delivery

See also: FMEA vs Threat Modeling for Medical Devices, Home Use vs Hospital Device Cybersecurity Requirements, and AAMI SW96 vs TIR57: Did SW96 Replace It?.

Score each with severity anchored to the clinical harm, not the technical impact. A denial-of-service that suppresses an alarm on a life-supporting device is Severity Catastrophic, not Severity Moderate.

How does dFMEA relate to AAMI TIR57 threat modeling?

AAMI TIR57 / ANSI/AAMI SW96:2023 threat modeling is the security-side analog of the dFMEA. Where the dFMEA asks "what can fail," TIR57 asks "what threat actor, using what capability, exploits which asset, to trigger that failure."

The two artifacts must share failure-mode identifiers. When the TIR57 threat model documents a spoofing attack against the Bluetooth pairing state machine, the corresponding dFMEA row for "loss of pairing integrity" should reference the same ID. The FDA's Feb 3, 2026 guidance names this bidirectional traceability as an expected element of a premarket cybersecurity submission.

If the two artifacts are maintained by separate teams with separate templates, expect an AI request asking for a reconciliation matrix.

How Blue Goat approaches dFMEA for connected devices

Our medical-device cybersecurity engineers, CISSP, OSCP, and ex-military red team backgrounds, run the dFMEA and the AAMI TIR57 / ANSI/AAMI SW96:2023 threat model as a single integrated workshop, not two sequential exercises. We map every cyber failure mode to a specific line item in the ISO 14971 risk file, tie it to a design control, and generate the reviewer-ready traceability matrix as part of our FDA cybersecurity submission service.

If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. That commitment is only credible because the dFMEA-to-threat-model traceability is airtight before the eSTAR goes out the door.

FAQ

Is a dFMEA required for FDA clearance of a medical device?

The FDA does not name dFMEA in guidance, but the Quality Management System Regulation (21 CFR Part 820, in effect since February 2, 2026) incorporates ISO 13485:2016, which requires risk management in design and development (clauses 7.1 and 7.3), and reviewers expect the analysis to identify failure modes. Most manufacturers use dFMEA as the vehicle. Skipping it forces you to demonstrate an equivalent analysis in some other form, which is almost always more work than doing the dFMEA.

Can we use the dFMEA severity scale for cybersecurity risks?

Yes, and you should. Using a separate scale for cyber risks creates reconciliation gaps that the FDA flags. Anchor both scales to clinical harm, the same S=Catastrophic value should mean the same patient outcome whether the trigger is mechanical wear or a network exploit.

What is the difference between dFMEA and threat modeling?

A dFMEA enumerates what can fail. A threat model enumerates who or what causes those failures and how. AAMI TIR57 / ANSI/AAMI SW96:2023 explicitly positions threat modeling as complementary to safety risk analysis, not a substitute for it. Both are expected in a modern premarket cybersecurity submission.

Does RPN still matter under the Feb 3, 2026 FDA guidance?

RPN is useful for prioritizing engineering effort but is not a valid acceptance criterion by itself. The guidance requires severity-based thresholds, high-severity failure modes need risk controls regardless of occurrence or detection scores.

How often should the dFMEA be updated?

Update the dFMEA whenever the design changes, when postmarket vulnerability intelligence reveals a new failure mode, or when a security patch modifies an interface. Treat it as a living document tied to your change-control process, not a one-time premarket artifact.

Ready to align your dFMEA with the FDA's cybersecurity expectations?

Book a scoping call with our medical-device cybersecurity team. We'll review your current dFMEA, threat model, and ISO 14971 risk file, and show you exactly where the reviewer will push back before you submit. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.

---

Christian Espinosa, Founder & CEO, Blue Goat Cyber (MBA, ex-Air Force cyber warfare officer). Christian has led hundreds of medical-device cybersecurity submissions across Class II and Class III devices, and works directly with FDA reviewers on premarket cybersecurity deficiency responses.

---

More on this topic

• ISO 14971 and AAMI TIR57 Synergy
• TARA for Medical Devices: FDA Premarket