Design FMEA for Medical Devices: dFMEA

Updated September 24, 2026

A dFMEA can support risk analysis, but neither the FDA nor ISO 14971 mandates that particular technique. 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.

If dFMEA is used, include relevant cyber-triggered failure modes and link them to the security risk assessment; dFMEA itself is not mandatory.

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, Cybersecurity Hazard Analysis for Medical Devices: CIA to Harm, and Medical Device Cybersecurity: Nanotech.

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 a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. 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 FDA guidance recommends 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. Threat modeling and safety-risk linkage are recommended; dFMEA is one optional supporting technique.

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. Use documented risk acceptance criteria and device-specific security risk analysis, rather than treating an RPN as sufficient evidence of acceptability.

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 identify potential evidence gaps before you submit. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed.

---

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