12 Essential FDA Cybersecurity Risk Assessment Rules

An FDA cybersecurity risk assessment looks at two things: how easily an attacker could exploit a weakness and what would happen if they succeeded. Simple enough, right?

However, the process can turn complicated rapidly when FDA reviewers start asking medical device manufacturers questions about satisfying these two conditions.

FDA's February 2026 premarket cybersecurity guidance and ANSI/AAMI SW96 explain how to approach this work. Each risk needs to:

• Connect to a threat in your threat model
• Be evaluated before and after mitigation
• Be measured against documented acceptance criteria.

If a cybersecurity risk could harm a patient, it also needs to be addressed through ISO 14971.

Truth is, many teams preparing their first FDA submission can get into trouble in the blink of an eye.

Why?

FDA expects cybersecurity risk assessments to focus on exploitability, not probability. If you're used to ISO 14971, you've probably spent years evaluating risks based on the probability and severity of harm. So quite naturally, you may be inclined to use that same approach for cybersecurity.

But here's the problem:

Attackers don't behave like components that fail at predictable rates.

Section V.A.2 of FDA's February 2026 guidance gets into all this. It clearly points out you can't calculate the probability of someone discovering and exploiting a SQL injection vulnerability the way you might estimate a component failure rate. You need to look at it by understanding how an attacker could exploit the weakness followed up by the likely consequences.

It all begs the big question: So how do you know whether your medical device cybersecurity risk assessment will hold up during FDA review?

I use the twelve rules (below) to check assessments before submission. Each connects to FDA guidance or ANSI/AAMI SW96. They cover the issues reviewers are likely to question, from threat modeling and risk scoring to mitigation and documentation.

For a closer look at the process, see our book chapter on security risk assessment. If your assessment satisfies all twelve rules, you'll be in a much better position to explain and defend your decisions when FDA comes back with questions.

If your assessment can pass all twelve, you can defend it in a reviewer call.

And sleep a lot better.

Quick map: rule, guidance source, and where reviewers look

Section numbers below follow the February 2026 FDA guidance and the current edition of SW96.

#	Rule	Guidance reference	Reviewer artifact
1	Capture risks and controls from the threat model	SW96 Clause 5.4; FDA Sections V.A.1, V.A.2	Threat model + traceability matrix
2	Score pre- and post-mitigation	SW96 Clauses 5.5, 7.3; FDA Section V.A.2	Risk assessment table
3	Document acceptance criteria	SW96 Clauses 4.2, 4.4; FDA Section V.A.2	Security risk management plan
4	Transfer cyber risks with safety impact to ISO 14971	SW96 Clause 6.2; FDA Section V.A.2	Safety and security assessment of vulnerabilities
5	Use exploitability, not probability	FDA Section V.A.2	Risk assessment methodology section
6	Treat known vulnerabilities as foreseeable	FDA Sections V.A, V.A.2, V.A.4(b)	SBOM analysis + risk assessment
7	Consider TPLC when evaluating vulnerabilities	FDA Sections V.A.2, V.A.6	Risk assessment + cybersecurity management plan
8	Evaluate device risk in system context	SW96 Clause 6; FDA Sections V.A, V.B.2	Security architecture views + threat model
9	Design out CISA KEV vulnerabilities	FDA Sections V.A.2, V.A.4(b)	SBOM analysis + design rationale
10	Assume worst-case or justify the exploitability rating	FDA Section V.A.2	Risk assessment narrative
11	Build TPLC into acceptance criteria	SW96 Clause 4.2; FDA Sections V.A.2, V.A.6	Acceptance criteria + post-market plan
12	Cover both intentional and unintentional failures	FDA Section V.A.2	Threat model

If you read nothing else, that table is the deliverable. How the finished assessment gets packaged for FDA is covered in our book section on cybersecurity risk assessment documentation for eSTAR submissions.

The twelve rules

1. Capture risks and controls from the threat model

It's important to make connections, like every risk in your assessment should connect to a threat in your threat model. Security controls need similar connections. This is important because when an FDA reviewer can't follow those connections, questions pop up. Questions like whether your assessment supports your security decisions.

And you don't want that.

Equally crucial, your threat model should cover the device's entire lifecycle, from manufacturing and deployment to updates and retirement. The idea is to give each threat a unique ID and reference it in your risk assessment. Then link each control to the relevant risks and threats. And don't ghost the Test reports. They should reference those controls as well.

For more on this process, see our guide to threat modeling for cloud-connected medical devices.

2. Score pre- and post-mitigation

So you ask, what exactly is the point of pre- and post-mitigation scoring?

It's a fair question. And yes, there is a solid answer.

You must show that your controls do something.

Pre-mitigation assumes no controls. Post-mitigation reflects the residual risk after planned controls are implemented and verified. Both scores. Same methodology. The good news: Document the methodology only once and apply it consistently.

Here's an example.

Let's say a risk scores 8 before mitigation. And only 7 afterward. Not a big change. This is the kind of thing an FDA reviewer will bring up.

But if that same score drops from 8 to 3 you have joyously verified the control. In other words, you have results you can defend.

Keep in mind through all this that CVSS (Common Vulnerability Scoring System) works as a starting point for the exploitability factors, but you'll need to adjust for how the medical device is actually used.

Think of it this way.

A vulnerability that requires someone to interact with the device may pose a different risk for a trained clinician than a patient using it at home.

3. Document acceptance criteria

FDA reviewers will need to see how you decide which risks are acceptable and which need more work. In other words, your criteria should explain:

• Which risks are acceptable, conditionally acceptable, or unacceptable.
• When a risk needs to be escalated.
• Who can approve risks at each level.
• What triggers another risk assessment.

One way to handle this is to divide risks into four categories: low, medium, high, and critical. But you also need to explain what your team does with each one. For example, requiring additional controls before accepting a critical risk gives reviewers something concrete to evaluate. On the flip side, saying you'll handle critical risks case by case doesn't explain much.

Why is this necessary at all?

ANSI/AAMI SW96 requires documented security risk acceptance criteria (Clause 4.2) in your SW96 security risk management plan (Clause 4.4). FDA also addresses these criteria in Section V.A.2 of its guidance.

4. Transfer cyber risks with safety impact to ISO 14971

A cybersecurity threat is bad. A threat to patients is even worse.

A lot worse.

This kind of ugly cybersecurity gaff can cause everything from unauthorized data exposure to incorrect doses, loss of therapy, or false alarm suppression.

That's why FDA wants manufacturers to have a documented process for moving that risk from their cybersecurity team to their patient safety team in the form of a handoff plan. The cybersecurity team identifies the threat and the patient safety team then evaluates the possible harm using ISO 14971, the standard for medical device risk management.

SW96 Clause 6.2 and FDA Section V.A.2 address how these two risk management processes should work together.

In plain English: If a cybersecurity threat could hurt a patient, you can't leave it to the cybersecurity team alone. The safety team needs to evaluate it, and both teams need to document what they found, what they decided, and what they did about it.

5. Use exploitability, not probability

You may be used to evaluating medical device safety risks under ISO 14971. But expect a different approach when it comes to medical device cybersecurity.

FDA wants your attention focused on how easily an attacker might exploit a weakness with CVSS providing a way to score these factors.

Factors that go into that determination:

• Access vector: Can an attacker reach the device remotely, through a nearby connection, or only with physical access?
• Attack complexity: How difficult would it be to carry out the attack?
• Privileges required: Does the attacker need user or administrator access, or no special permissions at all?
• User interaction required: Does someone have to take an action for the attack to work?
• Exploit maturity: Is the attack only theoretical, has it been demonstrated, or is it already happening?

This will require some effort, but there is additional assistance in the form of FDA's postmarket guidance references CVSS v3.0, and the MITRE approach to applying CVSS to medical devices offers additional guidance.

There is an additional thing to remember. You must use the same scoring method throughout your assessment and explain how you arrived at each score.

This is for the benefit of an FDA reviewer who needs to follow your calculations without having to ask how you did them.

For specific guidance on adapting CVSS to medical devices, see the CVSS for medical device risk assessment breakdown.

6. Treat known vulnerabilities as foreseeable

Pay close attention to this rule.

We have learned from client experience that this rule trips up teams that try to score a known CVE as "unlikely."

But the truth is this:

If the vulnerability exists in your device, the risk is already there. What matters here is how easily someone could exploit it and the damage that unfortunately could follow.

And that's not all.

This same vulnerability impacts your SBOM and weaknesses found during your own security testing.

Even vulnerabilities listed in CISA's Known Exploited Vulnerabilities catalog affect your device or its supporting systems.

And that is a surprise to many as well.

7. Consider TPLC when evaluating vulnerabilities

A reviewer who sees a one-shot risk assessment with no TPLC consideration will assume the team hasn't thought past day one.

This isn't surprising because exploitation tools mature, defensive controls age, and components reach end-of-support. A hacker might discover a new way to exploit a weakness in the device's software. Or a software supplier might stop providing security updates for a component the device uses.

A risk scored at device launch is not the same risk several years later.

An FDA reviewer understands this. And so should you.

Your risk assessment should explain how cybersecurity threats might change over the device's lifetime and how your team plans to handle them.

8. Evaluate device risk in system context

Medical devices rarely operate on their own.

They connect to electronic health records, hospital networks, smartphones, and cloud services. So not surprisingly, FDA reviewers think along these lines:

If someone hacks into a device, what else could they access?

It's just another area that your risk assessment needs to consider.

A vulnerability that poses little risk in a standalone device could become a serious problem when connected to hospital imaging systems, a patient's phone, or a clinician's computer.

Be certain your threat model covers various scenarios including where access is restricted (trust boundaries) and how an attacker might move from one connected system to another (lateral movement).

For examples, see how to create data flow diagrams for medical devices.

9. Design out CISA KEV vulnerabilities

As you might expect, FDA takes a firm position on vulnerabilities listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.

These are security weaknesses that hackers have already exploited. FDA expects manufacturers to address them through design changes rather than simply accept the risk.

Best approach here: Check your software bill of materials (SBOM) against the KEV catalog before every release. If you find a match that affects your device, flag it for action rather than accepting it.

Be aware you can also build this check into your continuous integration (CI) process so affected software doesn't move forward until the issue is addressed.

10. Assume worst case or justify the exploitability rating

It's more than likely you don't have strong evidence about exploitability because attackers don't publish their capabilities.

What do you do? Default to worst-case. If you want to assess as something less than worst-case, document the justification like this:

• What technical barrier reduces exploitability?
• What evidence supports the assessment?
• How will the assessment be revisited over TPLC?

There's a line in the methodology section saying "we score conservatively unless explicit justification is provided." And that's a good thing. It carries weight with reviewers. It signals the assessment was done deliberately.

11. Build TPLC into acceptance criteria

Rule 7 says model the risk over time. Rule 11 says model the acceptance threshold over time.

They're related but not the same.

A useful pattern, and this one is my practice rather than guidance text, is staged acceptance:

• Years 0–2 from launch: standard criteria apply.
• Years 3–5: reduced acceptance thresholds; certain conditional risks get reassessed.
• Years 5+: enhanced controls required, or end-of-life trigger.

The pattern works because FDA reviewers recognize that the post-market plan is real, not a placeholder.

12. Cover both intentional and unintentional failures

FDA reviewers want to see intentional as well as unintentional scenarios in the threat model.

The reason is this: Cybersecurity failures don't all come from attackers.

In fact, it's not all that uncommon to have a cybersecurity failure from misconfigured authentication settings to a key rotation procedure that nobody ran.

This means every authentication boundary should have a failure mode under the "misconfigured" heading as well as "attacked."

Digging deeper, every cryptographic operation should also have a failure mode for "key compromised by mistake" in addition to "key cracked." The control set should address both classes.

For the controls side, see how to implement cybersecurity controls.

What gets FDA cybersecurity risk assessment flagged by reviewers?

After reviewing enough FDA submissions, you start noticing the same problems. Here are the ones I see most often:

• Probability disguised as exploitability. Same scoring method, different name. Reviewers notice.
• Threat models and risk assessments with no shared IDs. Without them, you can't trace risks between documents.
• Controls with no matching threats. Often a sign someone copied a generic checklist.
• Acceptance criteria handled "case by case." That doesn't tell reviewers how decisions are made.
• No connection to patient safety. The Safety and Security Assessment of Vulnerabilities is incomplete or too generic.
• CISA KEV overlooked. Known exploited vulnerabilities weren't checked or properly addressed.
• No TPLC planning. The assessment covers launch day but ignores how risks may change afterward.

A pattern from submissions

One costly mistake I see in FDA submissions is a well-written risk assessment that doesn't match the controls section.

The assessment uses one scoring method, but the controls section uses another. Now the FDA reviewer wants an explanation. What should have been a simple clarification turns into a major rewrite of the cybersecurity documentation.

The solution? Use one scoring method, explain it in your cybersecurity management plan, and stick with it throughout the submission. Reviewers expect consistency. If your documents contradict each other, expect questions.

Where to go next

Want to see how your FDA cybersecurity risk assessment measures up against these twelve rules? Start with our FDA 524B Cybersecurity Readiness Assessment. For help with related documents, including threat models, security controls, testing, and SBOMs, see our FDA cybersecurity requirements overview.

If you already know what needs fixing, our 30-day CyberSprint can help you complete the cybersecurity documentation on a fixed timeline, including the risk assessment.

This article is based on published FDA guidance and ANSI/AAMI SW96. It isn't regulatory advice for your specific submission. Consult a regulatory professional familiar with your device.

Need help with your risk assessment? See our FDA cybersecurity documentation service or email info@cybermed.ai.

Sources

• FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance, February 3, 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
• FDA. Postmarket Management of Cybersecurity in Medical Devices. Final guidance, December 28, 2016. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/postmarket-management-cybersecurity-medical-devices
• ANSI/AAMI SW96:2023. Standard for medical device security, Security risk management for device manufacturers. AAMI, 2023. https://array.aami.org/doi/book/10.2345/9781570208621
• ISO 14971:2019. Medical devices, Application of risk management to medical devices. ISO. https://www.iso.org/standard/72704.html
• MITRE. Rubric for Applying CVSS to Medical Devices. Version 0.12.04, revised October 27, 2020. https://www.mitre.org/news-insights/publication/rubric-applying-cvss-medical-devices
• CISA. Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• FIRST. Common Vulnerability Scoring System (CVSS). https://www.first.org/cvss/