On this page
Published: June 25, 2026
Key Takeaways
- A dFMEA is a design-level analysis; process-FMEA (pFMEA) and use-FMEA (uFMEA) are separate artifacts with different scopes.
- Cyber-triggered failure modes must flow into the ISO 14971 risk file with the same severity scale used for clinical hazards.
- AAMI TIR57 [threat modeling](/services/threat-modeling-services "medical device threat modeling") and dFMEA are complementary, dFMEA identifies what can fail, TIR57 identifies who or what makes it fail.
- Risk Priority Number (RPN) alone is not a valid acceptance criterion under the Feb 3, 2026 FDA guidance; severity-based thresholds are required.
- Every cyber failure mode needs a traceable design control, a V&V test, and a postmarket monitoring plan.
Updated July 4, 2026
A design FMEA (dFMEA) for a connected medical device catalogs every functional failure mode of the design, scores it for severity, occurrence, and detection, and links each cyber-triggered failure mode into the ISO 14971 risk file and the AAMI TIR57 threat model. Run it in parallel with your security risk assessment so the FDA reviewer sees a single, consistent picture of patient harm across safety and cybersecurity under the Feb 3, 2026 premarket guidance.
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 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.
Table of Contents
- Why this matters
- What is a dFMEA and how does it differ from pFMEA and uFMEA?
- How does a dFMEA connect to ISO 14971 for medical devices?
- How do you add cybersecurity failure modes to a dFMEA?
- How does dFMEA relate to AAMI TIR57 threat modeling?
- How Blue Goat approaches dFMEA for connected devices
- Design FMEA FAQs
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 threat model, and the ISO 14971 hazard analysis to reference the same failure modes with the same severity ratings.
FDA's CDRH FY2024 performance report identified cybersecurity as one of the top-three deficiency categories driving 510(k) Additional Information requests. 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.
| FMEA type | Scope | Primary standard alignment |
|---|---|---|
| dFMEA | Design components, interfaces, software architecture, wireless stacks | ISO 14971, IEC 62304, AAMI TIR57 |
| pFMEA | Manufacturing, sterilization, assembly, supply chain | ISO 13485, 21 CFR 820.30 |
| uFMEA | User interaction, workflow, human factors | IEC 62366-1, FDA HFE guidance |
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.
Under the Feb 3, 2026 FDA guidance, RPN thresholds cannot be the sole acceptance criterion. Any failure mode with Severity ≥ high-harm must have a documented risk control regardless of occurrence or detection scores.
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.
See also: FMEA vs Threat Modeling for Medical, FDA AI Cybersecurity Threats: 7 Attacks, and Infusion Pump Cybersecurity: FDA.
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
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 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 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 guarantee 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?
FDA does not name dFMEA in guidance, but 21 CFR 820.30(g) requires design risk analysis, 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 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 (CISSP, 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.