On this page
Published: · Updated:
Key Takeaways
- FMEA covers accidental failure modes; threat modeling covers intentional adversarial action.
- The FDA's February 3, 2026 final [premarket cybersecurity](/guides/fda-cybersecurity-guidance "FDA premarket cybersecurity") guidance expects a threat model in addition to ISO 14971 hazard analysis, not in place of it.
- Cyber events feed back into safety risk through ISO 14971 only after threat modeling identifies the attack path and likelihood inputs.
- A clean submission links specific FMEA hazards to the threat model entries that could trigger them, and vice versa.
- STRIDE-based threat modeling and a process FMEA on the security program are complementary, not duplicative.
FMEA identifies random and systematic failure modes, such as hardware wear-out or software defects, commonly evaluated by severity and occurrence (and, in some methods, detectability); occurrence estimates may draw on data, engineering judgment, or other justified evidence, not necessarily empirical failure rates. Threat modeling instead examines deliberate adversarial action, scoring exploitability and attacker capability rather than failure rates. An applicable submission should link its cybersecurity assessment to its safety risk-management analysis; FMEA is one possible safety-analysis technique, not a universally mandatory artifact.
A frequent finding in FDA cybersecurity deficiency letters is that the manufacturer submitted a thorough hazard analysis and FMEA in place of a threat model. The two artifacts look similar at a glance, but reviewers reject the substitution because they answer fundamentally different risk questions. This post explains the boundary, where the two artifacts must reference each other, and what a clean separation looks like in a 524B submission.
Why this matters
The FDA's February 3, 2026 guidance recommends distinct but linked cybersecurity and safety risk assessments. AAMI TIR57:2016/(R)2023 denotes a reaffirmation, not a 2023 technical revision. FMEA is one possible safety-analysis technique; neither a mandatory FMEA file nor two separate physical files follows from Section 524B. Preserve the different analytical inputs and traceability between assessments.
Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); FDA Cybersecurity resources for medical devices; FDA Cybersecurity in Medical Devices FAQs (Section 524B).
What FMEA Is
Origin and Method
FMEA originated in aerospace and automotive safety engineering and entered medical devices through ISO 14971 risk management and process-validation practice. It is a structured enumeration of failure modes for components, subsystems, or process steps, scored by severity, occurrence, and detectability. Variants include design FMEA (dFMEA), process FMEA (pFMEA), and use FMEA (uFMEA).
What It Covers Well
FMEA covers random hardware failure, wear-out, latent software defects activated by normal operation, manufacturing process variability, and use error. The likelihood input is empirical or statistical: failure rates, defect rates, error rates from human factors studies. The output is a set of design or process mitigations and a residual risk score.
Where It Falls Short on Cybersecurity
FMEA likelihood scoring breaks down for adversarial events. There is no empirical failure rate for "an attacker exploits a heap overflow on the BLE stack." Severity scales transfer cleanly, but occurrence and detectability do not, because an adversary chooses when and how to attack. Trying to score cyber events on an FMEA worksheet produces numbers that are not defensible to a reviewer.
dFMEA Specifically: How It Feeds ISO 14971 and the Threat Model
Design FMEA (dFMEA) is the variant most teams reach for first, because it walks the design bottom-up: component, subsystem, interface, function. Done well for a connected medical device, it produces two outputs reviewers care about, the hazard inputs the ISO 14971 file consumes, and the list of cyber-triggerable failure modes that hand off to the threat model.
Scoring on a medical scale. Generic automotive 1-10 scales do not match ISO 14971 expectations. Severity should map to the harm bands from ISO 14971 Annex C (negligible, minor, serious, critical, catastrophic), the same bands the rest of the risk file uses. Occurrence should use the same probability bands as the hazard analysis. If the dFMEA uses one scale and the hazard analysis uses another, the file is internally inconsistent and reviewers will flag it.
RPN is a triage signal, not an accept/reject rule. A severity-5 patient-harm row with low occurrence and high detection can produce a low RPN. ISO 14971:2019 requires risk acceptability decisions against pre-defined severity-gated criteria, not against an arbitrary RPN threshold.
The two columns that earn their keep. Add Cyber-triggerable (Y/N) and Linked threat model ID(s) to the dFMEA. Any row touching a network interface, software update path, exposed port, wireless link, or external data input is Y and gets one or more threat model IDs. Maintain the reverse mapping in the threat model. Those two tables together are the traceability evidence reviewers actually open.
A dFMEA row whose effect is "device crashes on malformed input" belongs in the ISO 14971 file. The matching threat model row is the attack path that produces that input. Same failure mode, two artifacts, with a cross-reference between them.
What Threat Modeling Is
Origin and Method (Threat Modeling)
Threat modeling in medical devices is grounded in AAMI TIR57, AAMI SW96, IEC 81001-5-1, and the FDA's premarket cybersecurity guidance. The method enumerates assets, trust boundaries, data flows, and adversaries; identifies attack paths; rates each path by exploitability and impact; and assigns mitigations. STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) is the most common categorization scheme; PASTA and attack trees are also used.
What It Covers Well (Threat Modeling)
Threat modeling captures interface-level attack surface (wireless, wired, USB, cloud, app), trust boundary crossings, credential and key handling, update integrity, and data flow exposure. The likelihood input is exploitability and attacker capability, not failure rate. The output is a set of security controls and residual cybersecurity risk.
Where It Stops
A threat model does not address random component failure or normal-use defects. It assumes a working device and asks how an adversary subverts it. A device with no adversarial exposure (truly air-gapped, no software updateable interfaces, no data ports) still has an FMEA; it may not need a substantive threat model.
The Core Differences
Preserve distinct cybersecurity and safety analyses and their traceability. A combined record can do this; file separation alone does not determine adequacy.
Where the Two Must Reference Each Other
The analyses are distinct but linked, whether maintained in separate files or a combined record. Three explicit linkages belong in a clean submission.
Cyber-Triggered Safety Hazards
Any safety hazard in the ISO 14971 file that could be triggered or accelerated by a cybersecurity event references the threat model entries that describe those events. Example: a hazard "unintended drug delivery" is linked to threat model entries covering tampering with the infusion rate parameter and spoofing of the clinician interface.
Safety-Constrained Security Controls
See also: Design FMEA for Medical Devices: dFMEA, Cybersecurity Hazard Analysis for Medical Devices: CIA to Harm, and Medical Device Cybersecurity: Nanotech.
Any security control that constrains a safety function (for example, an authentication step in front of a clinical setting change) is reflected in the FMEA's use-error analysis, because the control introduces a step that can be performed incorrectly under time pressure.
Shared Residual Risk
The total residual risk presented to the FDA combines safety and cybersecurity residuals with explicit reasoning about how cyber mitigations affect safety risk and vice versa. The reasoning is documented in the risk management report and cross-referenced from the security risk report.
How to Scope Each Artifact for a 524B Submission
If you want this done for your device, see our medical device threat modeling service.
FMEA Scope
Cover the device's intended use, foreseeable misuse, and the patient population. Include hardware failure modes, software defect modes activated by normal operation, manufacturing variability, and use error. Do not score adversarial events on the FMEA worksheet.
Threat Model Scope
Cover every interface (wired, wireless, USB, cloud, app, service), every trust boundary, every data flow that crosses a boundary, and the update mechanism. Apply STRIDE per interface and per data flow. Include the attack paths that produce safety impact and link them to the corresponding FMEA hazards.
Process FMEA on the Security Program
A pFMEA on the postmarket cybersecurity process itself (SBOM ingestion, VEX triage, CAPA initiation, advisory release) is a useful complement to threat modeling, not a substitute. It catches process failures that let real attacks land, without trying to score attacker behavior.
Need help? Our team supports manufacturers with FDA cybersecurity submissions end-to-end. Explore our medical device cybersecurity services or book a discovery call.
How Blue Goat Approaches the Boundary
We build the threat model and the FMEA-to-threat-model linkage table that submissions actually need, alongside (not inside) the existing ISO 14971 file. The threat model uses STRIDE per interface and per data flow, with exploitability scoring grounded in AAMI TIR57 and SW96 rather than failure-rate scoring. We produce the explicit cross-references that connect cyber-triggered safety hazards to the threat model entries that could trigger them, and we draft the residual risk reasoning that reconciles both files. Our team holds CISSP, OSCP, and prior military red-team credentials, and we ground our work in Section 524B, the FDA's February 3, 2026 guidance, AAMI TIR57:2016/(R)2023, AAMI SW96:2023, IEC 81001-5-1:2021, and ISO 14971:2019. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. Start with our threat modeling service or our premarket cybersecurity service.
FAQ
Can FMEA replace a threat model in a 524B submission?
A combined record may be appropriate if it preserves distinct cybersecurity and safety analyses and their traceability. Do not substitute failure-rate scoring for assessment of adversarial attack paths, exploitability, and consequences. FMEA is not universally mandatory.
Does every medical device need both an FMEA and a threat model?
ISO 14971 requires a risk management process, not FMEA as a mandatory method. A device that is genuinely air-gapped with no software updateable interfaces, no data ports, and no wireless may not need a substantive threat model. For applicable cyber-device submissions, provide the required cybersecurity information and appropriate linked safety risk-management evidence; FMEA itself is not universally mandatory.
Should we use STRIDE, PASTA, or attack trees for medical device threat modeling?
STRIDE is the most common starting point in the medical device space because it aligns with AAMI TIR57 and SW96 categorization and produces a reviewer-friendly structure. PASTA is useful for higher-complexity systems where business-impact analysis drives prioritization. Attack trees are useful for deep-diving on a specific high-severity attack path. Most submissions use STRIDE as the primary method and supplement with attack trees on the highest-risk paths.
How does threat modeling feed back into ISO 14971?
Through the cyber-triggered safety hazard linkage. Threat modeling identifies attack paths and their outcomes; any outcome that produces patient harm becomes (or augments) a hazard in the ISO 14971 file. The ISO 14971 entry references the threat model entry that justifies its existence and its residual risk. Without the linkage, the safety risk file has cyber-triggered hazards floating without justification and the security risk file has attack paths without patient impact tracing.
What is process FMEA on a cybersecurity program?
A pFMEA applied to the steps of the postmarket cybersecurity workflow itself: SBOM regeneration, VEX triage, CAPA initiation, advisory release, customer notification. It scores process failure modes (a step skipped, a handoff dropped, a deadline missed) rather than adversarial events. It complements threat modeling by addressing the operational reliability of the security program, not the security of the device.
Where do FMEA and threat modeling appear in the FDA submission?
FMEA appears inside the risk management file (per ISO 14971) referenced in the submission. The threat model appears inside the security risk file (per AAMI TIR57 and SW96) and is one of the security documents the February 3, 2026 guidance expects in the Cybersecurity Section of the submission. The linkage table connecting the two should appear in both files and be referenced from the cybersecurity submission summary.
Ready to draw the line between safety and security risk?
If your submission folds cybersecurity into a single FMEA, or your threat model has no traceability back to ISO 14971 hazards, you have a deficiency exposure. We can build the linked pair the FDA expects. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. Schedule a discovery call.
Christian Espinosa, Founder, Blue Goat Cyber. Christian has led premarket and postmarket cybersecurity programs for connected medical devices across Class II and Class III submissions and previously commanded military red-team operations. Read more at christian-espinosa.
About the author
Christian Espinosa, MBA · Founder & CEO, Blue Goat Cyber
U.S. Air Force Academy graduate and veteran with 30+ years in cybersecurity. Founded Alpine Security in 2014 (acquired 2020), then Blue Goat Cyber in 2022. Has supported 275+ medical devices, with no cybersecurity-related rejections to date. Author of three books including The Smartest Person in the Room. Ironman triathlete and mountaineer.
Sources & references
Primary sources cited in this article. Links open in a new tab.
