Published: June 18, 2026
FMEA (Failure Mode and Effects Analysis) and threat modeling answer different questions about a medical device. FMEA asks what can fail by accident, by wear, or by latent defect, and what the patient impact is. Threat modeling asks what an adversary can do on purpose, through which interface, against which asset, with what impact. FMEA lives inside the ISO 14971 risk management file. Threat modeling lives inside the security risk file under AAMI TIR57 and AAMI SW96. Both are expected in a Section 524B submission, and an FMEA does not substitute for a threat model.
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.
Key Takeaways
- FMEA covers accidental failure modes; threat modeling covers intentional adversarial action.
- The FDA's February 3, 2026 final 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.
Table of Contents
- What FMEA Is
- What Threat Modeling Is
- The Core Differences
- Where the Two Must Reference Each Other
- How to Scope Each Artifact for a 524B Submission
- How Blue Goat Approaches the Boundary
- FAQ
Why this matters
The FDA's February 3, 2026 final premarket cybersecurity guidance, "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions," requires a security risk assessment that is distinct from the ISO 14971 safety risk assessment. AAMI TIR57:2016/(R)2023 and AAMI SW96:2023 reinforce the separation and define how the two files connect. The 2023 update to AAMI TIR57 was explicit: security risk analysis methods are not interchangeable with safety risk analysis methods, because the inputs (likelihood, exploitability, attacker capability) and the outputs (mitigations) differ. Submissions that fold cybersecurity into a single FMEA tab consistently draw a major deficiency. Submissions that omit FMEA entirely and submit only a threat model draw a different deficiency on the safety side. Both files are required, and the link between them is itself a reviewer focus.
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.
What Threat Modeling Is
Origin and Method
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 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
| Dimension | FMEA | Threat Modeling |
|---|---|---|
| Question answered | What can fail by accident or defect | What can an adversary do on purpose |
| Likelihood input | Failure rate, defect rate, use error rate | Exploitability, attacker capability, attack path complexity |
| Severity input | Patient harm from the failure | Patient harm or data harm from the attack outcome |
| Governing standard | ISO 14971, with sector annexes | AAMI TIR57, AAMI SW96, IEC 81001-5-1 |
| Output | Design or process mitigation | Security control |
| Lives in | Risk management file | Security risk file |
| Update trigger | Design change, field complaint trend | Design change, new CVE, new attack technique, threat intel |
The FDA's February 3, 2026 final premarket cybersecurity guidance treats the security risk assessment as a distinct deliverable from the ISO 14971 safety risk assessment. A single combined worksheet does not satisfy the requirement, even when its content is otherwise complete.
Where the Two Must Reference Each Other
The files are separate but the analyses are linked. Three explicit linkages belong in a clean submission.
Cyber-Triggered Safety Hazards
See also: MedTech Cyber Standards Every Device Team Must Know, Infusion Pump Cybersecurity: FDA Expectations in 2026, and Data Flow Diagrams for Medical Device Cybersecurity.
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
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
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.
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 cybersecurity deficiencies after our submission, we resolve them at no additional cost. Start with our threat modeling service or our premarket cybersecurity service.
FAQ
Can FMEA replace a threat model in a 524B submission?
No. The FDA's February 3, 2026 final premarket cybersecurity guidance expects a distinct security risk assessment, and a single combined FMEA worksheet is a recurring source of major deficiencies. FMEA covers accidental failure modes; threat modeling covers intentional adversarial action. The likelihood inputs do not transfer between the two methods, so a combined worksheet produces unscoreable cyber rows even when its safety content is otherwise complete.
Does every medical device need both an FMEA and a threat model?
Every device needs an FMEA under ISO 14971. 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. Any device that meets the Section 524B "cyber device" definition (capable of connecting to the internet, software capable of being updated, technological characteristics that could be vulnerable) needs both.
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 cybersecurity deficiencies after our submission, we resolve them at no additional cost. Schedule a discovery call.
Christian Espinosa, Founder, Blue Goat Cyber, CISSP, OSCP. 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.