Cybersecurity Hazard Analysis for Medical Devices: CIA to Harm

Reviewed October 13, 2026

Most device hazard analyses were built for random failures: a sensor drifts, a battery dies, a user presses the wrong button. Cybersecurity adds a different cause. Someone does it on purpose, they can repeat it, and they can do it to many devices at once. When the hazard analysis has no rows for those causes, the threat model and the risk file tell two separate stories, and the reviewer has to guess how a security finding could hurt a patient. That gap is a potential reason for cybersecurity questions in FDA review. The fix is not a second risk file. It is a small set of security-caused rows in the hazard analysis you already maintain, written in the same terms as your safety rows, with a clear link back to the threat that causes each one and forward to the control and test that address it.

Why This Matters

The FDA's February 3, 2026 premarket cybersecurity guidance asks manufacturers to run a security risk assessment alongside the ISO 14971 safety risk process and to show where security risks can lead to patient harm. AAMI TIR57 and AAMI SW96 describe the same link: security risk management feeds safety risk management, and the two share hazards and controls where they overlap. FDA guidance recommends that link in the documents, not only in an engineer's head. When a pen test finding has no path to a harm, its severity looks arbitrary. When a hazard is caused by tampering but the control is only an alarm, the reviewer asks what stops the tampering. A hazard analysis that names the security causes answers both questions before they are asked.

Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); FDA eSTAR Program; FDA Cybersecurity in Medical Devices FAQs (Section 524B); NIST Cybersecurity Framework.

What Is a Cybersecurity Hazard Analysis?

A cybersecurity hazard analysis is the part of your risk analysis that covers hazards caused on purpose through a security weakness. It uses the same ISO 14971 chain as any other hazard:

1. Cause: a threat that breaks confidentiality, integrity, or availability.
2. Hazard: a potential source of harm, such as a wrong dose command or lost therapy.
3. Hazardous situation: the patient exposed to that hazard.
4. Harm: the injury, death, or privacy damage that results, with a severity.

The threat model supplies the causes. The hazard analysis supplies the rest. For a deeper comparison of the two standards behind this, see our ISO 14971 vs AAMI TIR57 hazard analysis guide.

How Do You Turn a CIA Loss Into a Hazard?

Ask one question for each asset in the threat model: if an attacker broke this, what would the device do differently, and who would be exposed?

Two rules keep this honest. First, a confidentiality loss of keys or credentials is rarely the end of the chain. Follow it to the integrity or availability hazard it enables. Second, do not stop at "device compromised." That is a cause, not a hazard. Name what the device does and what happens to the patient.

Free to share with a link to this page: <a href="https://bluegoatcyber.com/resources/infographics/threat-to-harm-to-control">One hazard analysis row from threat to vulnerability to CIA loss to hazardous situation to harm rated per ISO 14971, then security control and verification test, linked by shared IDs. (Blue Goat Cyber)</a> Full-size infographic and text version

What Does an Example Row Look Like?

Here is one row for a fictional insulin pump with a phone app:

The security control stops the cause. The safety control limits the harm if the security control fails. Reviewers like seeing both, because it shows the design does not depend on one layer. Our threat model template uses the same threat ID so the row traces cleanly.

How Should Security Rows Be Scored?

ISO 14971 scores probability of occurrence. Attacks don't have a stable probability, so the FDA guidance and AAMI TIR57 recommend scoring exploitability instead. A common approach:

• Keep severity on the same scale as your safety rows, so a critical harm means the same thing everywhere.
• Score exploitability using a defined method, such as the Exploitability field of FIRST's CVSS v4.0 calculator, which Blue Goat Cyber uses.
• Combine them in a safety risk matrix for findings that can reach a patient, and rate every finding on a separate security matrix of exploitability and security impact, then carry the resulting hazards and controls into the ISO 14971 file.

The free CVSS v4.0 calculator for medical devices helps with the exploitability side. Whatever method you choose, write it down and use it the same way on every row.

Which Risk Controls Belong on Each Row?

See also: Design FMEA for Medical Devices: dFMEA, FMEA vs Threat Modeling for Medical Devices, and Medical Device Cybersecurity Risk: Why the Bare Minimum Fails in 2026.

Pick controls in this order, the same order ISO 14971 uses:

1. Secure design that removes the weakness, such as signed firmware, authenticated commands, or removing an unused port.
2. Protective measures in the device or system, such as rate limits, safe-state fallback, and logging.
3. Information for safety, such as labeling for network setup and customer security guides.

Every control needs a verification test with a result. Then check whether the control created a new hazard. Lockouts can stop a clinician in an emergency, and a forced update can interrupt therapy. Those become new rows. This is where the traceability matrix earns its place: it ties each row to its requirement, control, and test.

Don't Forget the Multi-Patient View

A random failure usually affects one device. An attack can hit every device on the same firmware at once. Add rows for fleet-wide hazards, such as a compromised update server or cloud outage, and rate their severity with the number of patients in mind. The February 2026 guidance calls this out, and reviewers check for it.

How Does a Cybersecurity Hazard Analysis Help Your FDA Submission?

For a cyber device under FDA Section 524B, the eSTAR Cybersecurity section asks for a threat model, a cybersecurity risk assessment, and evidence that controls were tested. A hazard analysis with security-caused rows ties those pieces together in four ways:

• It shows patient impact. The reviewer can see why a threat matters clinically, not just technically, which supports the severity you assigned.
• It justifies your controls. Each security control points to the hazard it reduces, so no control looks arbitrary and no hazard looks uncovered.
• It connects testing to risk. Pen test findings map to rows, so the reviewer can see that residual risk was reassessed after testing.
• It keeps documents consistent. One set of IDs across the threat model, risk assessment, ISO 14971 file, and traceability matrix removes the mismatches that often lead to cybersecurity deficiency questions.

A clear hazard analysis does not guarantee a clean review, but it answers the questions reviewers most often ask about how security risk links to patient safety.

How Blue Goat Cyber Approaches This

We start from your existing hazard analysis rather than replacing it. Our team maps each threat in the threat model to a CIA loss, follows it to a hazard and harm, and writes the rows in your format with matching IDs. Then we check that every row has a security control, a safety control where it makes sense, a test, and a residual risk decision. If you already have a threat model, our threat model gap assessment lists missing hazard links ranked by patient risk. If you are starting fresh, the free Threat Model Starter gives you a first draft of the threats to work from.

Need ongoing help keeping your hazard analysis current after clearance? See our medical device security advisory.

Related reading: TARA Threat Analysis and Risk Assessment for Medical Devices, CIA Triad vs. NSA Controls in Medical Device Cybersecurity.

FAQ

Is a cybersecurity hazard analysis a separate document?

It doesn't have to be. Most teams keep the security risk assessment as its own document and add the security-caused rows to the existing ISO 14971 hazard analysis. What matters is that the two link by ID.

Does the FDA require the CIA triad?

No. The FDA guidance does not require any specific model. Confidentiality, integrity, and availability are a simple, widely used way to make sure no type of security loss is missed. Some teams add authenticity or other properties.

Can a confidentiality loss cause physical harm?

Directly, rarely. Indirectly, yes. Stolen keys or credentials can let an attacker change settings or block therapy later. Follow the chain until you reach the integrity or availability hazard.

Why not use probability for security rows?

Attackers choose when and where to act, so there is no reliable failure rate. Exploitability describes how hard the attack is, which is something you can assess and defend.

How many security rows should a hazard analysis have?

There is no fixed number. You need at least one row for every threat in the threat model that could lead to a hazard. Threats that can't lead to any hazard should still be listed, with the reason.

Where do I start if I only have a safety hazard analysis?

Start with the threat model. List each asset and interface, ask how losing its confidentiality, integrity, or availability would change device behavior, and add a row for each answer.

CTA

If you want help linking your threat model and hazard analysis so the FDA reviewer can follow every chain, book a free 30-minute discovery call. You get a fixed-fee proposal afterward, and nothing is billed until you approve it.

Book a discovery call