Medical device security risk assessment: what FDA asks for
By The PenTest Index · Sources checked October 10, 2026
A medical device security risk assessment is your written analysis of how security threats or failures in the device, or anything it connects to, could affect patient safety or device effectiveness, and which controls reduce that risk. FDA's February 2026 guidance recommends one beside the safety risk file, scored on exploitability, not probability. A penetration test feeds it; it does not replace it.
Below: a 10-point check against FDA's own text, then who should fill each gap, and what it costs where anyone publishes a price.
What is a medical device security risk assessment?
It is one of three linked pieces of work, and people often sell or buy the wrong one. Here is how they differ.
| Piece | The question it answers | What you end up with |
|---|---|---|
| Threat model | What could go wrong, and where? | A map of the system and a list of threats |
| Security risk assessment | How exploitable is each weakness, how bad is the result, and what controls reduce it? | A risk register with controls and a decision on what risk is left |
| Penetration test | Do the controls hold when someone attacks them? | A test report with findings |
Think of a building. The threat model lists the ways a burglar could get in. The risk assessment decides which doors need better locks and why the rest are fine. The penetration test is someone trying the locks.
You remain responsible for the evidence as the manufacturer, even if you hire a firm. FDA discusses security risk management and cybersecurity testing as connected parts of a secure product development framework.
What does FDA ask for?
FDA's guidance recommends a security risk assessment that is separate from your safety risk assessment and linked to it. The guidance is Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, final, issued February 3, 2026. It replaced the June 27, 2025 edition.
Two things are easy to mix up.
The guidance recommends. Every page is headed "Contains Nonbinding Recommendations," and FDA says "should" means suggested, not required. In Section V.A it recommends that makers "conduct both a safety risk assessment and a separate, accompanying security risk assessment."
The law requires less, and something different. Section 524B of the FD&C Act covers "cyber devices" in specified premarket submissions. As FDA quotes it, sponsors must submit a plan for handling vulnerabilities after launch, keep processes that give "a reasonable assurance that the device and related systems are cybersecure," make available patches and updates for known unacceptable and critical vulnerabilities on the law's timelines, and provide a software bill of materials (SBOM), which is a list of software components in the device. The quoted duties do not name a risk assessment. FDA says the guidance is meant to help makers meet them.
In practice, plan to have one. FDA decides what is enough for your submission, and no document guarantees clearance.
The 10-point gap check
We built this from Section V.A of the guidance PDF, read October 10, 2026. Each row is something FDA's text says the file should contain. Mark each one yes, no or unsure.
| # | What FDA's text asks for | Section | Who usually produces it |
|---|---|---|---|
| 1 | A security risk assessment kept separate from the safety one, and linked to it | V.A | Security or software lead, with quality |
| 2 | A security risk management plan and a report, "such as that described in AAMI TIR57 and ANSI/AAMI SW96" | V.A | Quality and security together |
| 3 | A threat model covering the whole "medical device system," with your assumptions written down | V.A.1 | Security or systems engineer |
| 4 | Threats from the supply chain, manufacturing, deployment, other connected devices, updates and decommissioning | V.A.1 | Same, with operations and service |
| 5 | A reason for the threat-modeling method you chose | V.A.1 | Whoever built the threat model |
| 6 | Each risk scored before and after controls, with the scoring method and your acceptance criteria | V.A.2 | Security lead |
| 7 | Your method for passing security risks into the safety risk process | V.A.2 | Quality or risk manager |
| 8 | Known vulnerabilities assessed, with an SBOM and a support level and end-of-support date for each component | V.A.4 | Software lead |
| 9 | Unresolved software bugs checked for security impact | V.A.5 | Software and security leads |
| 10 | Traceability between the threat model, risk assessment, SBOM and testing, plus a conclusion on the risk that remains | V.A | Whoever owns the report |
A "medical device system," in FDA's words, includes the device and what it connects to, "such as healthcare facility networks, other devices, and software update servers." So the phone app and the cloud count.
One row trips up more teams than the rest: row 6. FDA says you cannot score an attack the way you score a random hardware failure, because it is "not possible to assess and quantify the likelihood of an incident occurring based on historical data or modeling." Security risk assessment focuses instead on exploitability, meaning how hard the attack is to carry out. The same section says vulnerabilities on CISA's Known Exploited Vulnerabilities list "should be designed out of the device."
What does one complete risk entry look like?
A complete entry follows one threat from the system, to the control, to the proof, to the decision. Here is a made-up example. The device and every detail are fictional, and we have left scores blank on purpose, because a guessed number is worse than an honest "not yet known."
Say you make a wearable heart sensor. It sends readings over Bluetooth to a phone app. A cloud service stores them and alerts a clinician.
| Field | Example entry | What makes it real |
|---|---|---|
| Where | Phone app to cloud service | Your actual versions and connections |
| Threat | Someone without permission changes the alert threshold, because the cloud service doesn't check who is asking | Your threat model |
| Risk before controls | An alert could be silenced. Exploitability: not yet assessed | Your scoring method and the reasoning |
| Possible patient harm | A missed alert could delay care | Your safety risk owner decides how this enters the ISO 14971 file |
| Control | The cloud service checks the user's role on every change and logs it | A written requirement and an owner |
| Proof | Tests that try the change as the wrong user, with results on file | Test evidence with dates |
| Risk after controls | Not decided until the control is built and tested | Your acceptance decision and who signed it |
| Review when | The app, the cloud service or the firmware changes | A named owner and a trigger |
Use it as a quick test of anything you are sold. A scan report that lists known flaws but never reaches the control, the proof and the decision is useful input. It is not this. A tidy risk spreadsheet with no tested controls has the opposite gap.
Is this the same as an ISO 14971 risk assessment?
No. FDA says "performing security risk management is distinct from performing safety risk management as described in ISO 14971," and that the two should connect. ISO 14971 is the standard for a device's safety risk file.
The difference is how the risk is assessed. A safety file considers the probability and severity of harm. A security file focuses on exploitability, including threats that can cause intentional or unintentional failures. FDA gives the reason in Section V.A.5: a software bug that shows up now and then in normal use may be an acceptable risk, but an attacker can look for that bug and trigger it again and again.
So you can't reuse the safety file as your security file. You link them. Row 7 of the gap check is that link.
Who should do it: your team, a reviewer, a firm or a platform?
Buy the missing work, not the biggest package. And nothing in Section V.A says an outside firm has to write the assessment. The only place the guidance raises independence is testing (Section V.C), where it names both "independent internal testers" and "external testers."
| What you have now | Route to start with | What it won't do |
|---|---|---|
| A team with security skill and time | Do it in-house. FDA's guidance points to the MDIC/MITRE Playbook for Threat Modeling Medical Devices as an educational resource | Give you an outside view. Consider a review before you submit |
| A file already written, quality unknown | An independent gap review | Rewrite the file for you |
| No threat model and no security file | A firm that builds the file with you | Fix the device or run the tests, unless that is in scope |
| Several products, or you want upkeep handled | A platform subscription | Fit a buyer who wants one document, once |
| A file whose controls have no test evidence | Testing of the missing controls, which may include a device penetration test | Stand in for the file |
Offers we read, by the job they do
We read each provider's own page on October 10, 2026. Everything here is what the provider publishes. We have not bought these services or seen a delivered file. Providers are A to Z within each group. This is not a ranking.
Build the file
| Offer | What the provider says you get | Published price (US dollars) | Still open |
|---|---|---|---|
| ArmadilCo, Cybersecurity Risk Assessment | Risk register, risk management plan, traceability matrix, residual risk report, and "safety-risk integration documentation per ISO 14971." Done for you or alongside your team | None. A scoped proposal follows a discovery call | Price, dates, which parts of your system are covered. Penetration testing is a separate service |
| Blue Goat Cyber, Medical Device Threat Modeling | Data flow diagrams, a threat table and attack trees, with each threat traced to a control, a test and a patient harm | None. Fixed fee, quoted within 24 hours of a call | The page says the threat model "is not the cybersecurity risk assessment." Ask if the risk assessment is in the same fee |
| CyberMed, 30-Day CyberSprint | Threat model, risk assessment, controls specification, penetration and fuzz testing, SBOM analysis and a submission checklist | None. "At a fixed price," no amount shown | The amount, and a confirmed start date. Thirty days is the provider's stated length, not a booked slot |
| The RND Group, FDA Premarket Cybersecurity Package | Threat model, four security architecture views, a "security risk assessment linked into your ISO 14971 file," SBOM, risk management report and traceability matrix | None. Scoped after a 30-minute call | Price, dates, whether testing is included |
Review a file you already have
| Offer | What the provider says you get | Published price (US dollars) | Still open |
|---|---|---|---|
| CyberMed, Cybersecurity & Software Gap Analysis | A review of your existing documents, including the risk management file, SBOM and threat model, and a report with a "prioritized remediation roadmap" | None | Price, turnaround, whether fixes to the file are included |
Build your own process, or subscribe
| Offer | What the provider says you get | Published price (US dollars) | Still open |
|---|---|---|---|
| Medcrypt, MSI platform | Software with "guided threat modeling" and "cybersecurity risk assessment," SBOM and vulnerability monitoring, and 15 expert advisory hours a year | Starting at $35,000 per product line, per year, annual term, invoiced annually | Invoice due date and payment terms. Penetration testing is a paid add-on |
| The RND Group, Cyber Quality System Framework | Risk assessment procedures, a risk workbook with initial and residual scoring, a gap assessment against the February 2026 guidance, and training | None | Whether a finished file for your device is part of it |
See ArmadilCo's risk assessment service
See Blue Goat Cyber's threat modeling service
See CyberMed's gap analysis and CyberSprint
See Medcrypt's platform pricing
See The RND Group's cybersecurity offerings
Our read, for one example buyer
Say you make that heart sensor. You plan to submit in three months. You have an architecture diagram and a safety file, but no threat model and no security file. Your engineers can make fixes. You want one finished file, not a subscription.
For that buyer, we would ask ArmadilCo and The RND Group for proposals first, and send Blue Goat Cyber one question before adding it. Here is why.
| Offer | Checked against | Finding | Send this question |
|---|---|---|---|
| ArmadilCo | "Build the file and hand it over" | Supported for the named risk-file artifacts; threat-model creation unresolved. The page names the register, plan, traceability matrix and report, but lists threat modeling as a separate service | "Does this include creating our missing threat model? Does your scope cover our firmware, app, cloud service and update path? What is the total, and the handoff date?" |
| Blue Goat Cyber threat modeling | "Build the file and hand it over" | Unresolved. The page separates the threat model from the risk assessment | "Is the cybersecurity risk assessment included in the threat modeling fee, or quoted on top?" |
| CyberMed Gap Analysis | "Build the file" | Mismatch. It reviews documents you already have | None for this buyer. A good fit once a file exists |
| CyberMed CyberSprint | "One file, nothing bundled" | Mismatch for this buyer. It includes testing. It fits if you need the tests too | "What is the fixed price, and the earliest kickoff date?" |
| Medcrypt MSI | "One file, no subscription" | Mismatch. It is priced per year | "Can we buy the assessment without the annual platform?" |
| The RND Group Premarket Package | "Build the file and hand it over" | Supported. Wider than this buyer asked for, since it adds the SBOM and architecture views | "Can you quote the threat model and risk assessment alone, and the full package beside it?" |
"Supported" means that one condition is backed by what the provider published. It says nothing about the quality of the work, and a written proposal can change any finding.
Change one fact and the answer changes. If you already have a file, start with a review. If you have three product lines and want someone watching new vulnerabilities, the yearly platform starts to make sense.
How much does a medical device security risk assessment cost?
Only one of the seven offers we read publishes a number, and it is for a yearly platform, not a one-time file: Medcrypt lists its MSI platform starting at $35,000 per product line, per year, with an annual term invoiced annually (checked October 10, 2026). ArmadilCo, Blue Goat Cyber, CyberMed and The RND Group do not publish prices for the offers we compared.
So there is no honest "typical price" to give you. A "fixed price" with no amount shown is still an unknown price. What you can do is make every quote answer the same five lines:
| Line | What must be in writing |
|---|---|
| The work | Build, review or both, and which of the 10 rows it covers |
| The system | Device, firmware, radios, apps, cloud, updates: in or out |
| The handoff | Editable files you own, and who signs the risk decisions |
| Changes | How many revision rounds, and the cost of an update after a design change |
| The total | One number, the currency, payment dates, and anything that renews |
A missing line is not a zero. It is an unknown, and the total isn't finished until it's filled in.
Do you also need a penetration test?
FDA recommends considering penetration testing, but it does not have to be bought separately. FDA lists penetration testing under cybersecurity testing (Section V.C), not under risk assessment, and says that for third-party test reports makers "should provide the original third-party report." The test results then go back into rows 6 and 10 of your file.
The order matters. A tester with your threat model in hand knows which controls to attack. A test bought before the threat model exists tends to cover whatever was easiest to reach.
We compared five offers—one with published device-testing prices and one with a published platform price but no test price—on a separate page: compare medical device penetration testing offers. If a seller offers you a scan in place of a test, read the difference between a penetration test and a vulnerability scan first.
What should you send a firm before asking for a quote?
Send every firm the same brief, so a review-only price and a build-the-file price don't look like two bids for the same job. Copy this and fill in the brackets. "Unknown" is a useful answer.
Medical device security risk assessment brief
Product: [name], hardware revision [ ], firmware or software version [ ]. Planned submission: [510(k) / De Novo / PMA / none yet], target date [ ].
System: [device], [firmware], [radios and wired ports], [apps], [cloud services and APIs], [update path], [connections to hospital systems]. Mark each in, out with a reason, or unknown.
What exists today: [architecture diagram], [threat model], [safety risk file], [SBOM], [test reports], [earlier security risk file and its date].
Work we want: [build / update / review] the threat model and security risk assessment. Gap-check rows we are missing: [numbers 1 to 10].
What we need back: editable risk register, risk management plan and report, a matrix tracing each threat to a control and a test, and the method for passing risks to our safety file.
Testing: tell us which controls need test evidence. Quote any testing as a separate line.
After delivery: cost and turnaround for an update when the design changes. Support if FDA asks questions.
Please answer:
- Are you building the file or reviewing ours? Show a redacted sample of what we will receive.
- Which parts of the system are in scope, and which are out?
- What is the total price, with revision rounds included?
- Who on our side must approve each risk decision?
- What are the start date, the draft date and the final handoff date?
This brief is for buying. It is not permission to test anything. Testing needs a separate signed agreement that covers the exact targets and activities.
Still settling the general questions, like who needs the report and by when? Find My PenTest Match is our free scope checklist. It needs no email or sign-up. It is a general checklist and does not list device firms, so use the brief above for the device details.
When should you update the assessment?
Update it when something changes, not only when you submit. FDA says makers "should update their security risk management documentation as new information becomes available, such as when new threats, vulnerabilities, assets, or adverse impacts are discovered during development and after the device is released" (Section V.A.6).
Common triggers:
- a firmware, app or cloud change that adds or alters a connection
- a new vulnerability in a component on your SBOM
- a component reaching its end-of-support date
- a finding from a test
That is why the update cost belongs in the quote. A file that is right on submission day and never touched again can go stale after a software release.
Assessing a device your hospital is buying or running?
That is a different job, and you are not the one who writes the file above. Start with the maker's own disclosure. Ask for the MDS2 form for your exact model and software version. MDS2 is a standard form in which a maker describes a device's security features. Then look at your own setup: which network the device sits on, who can reach it, and what happens to care if it goes down.
Our guide to the MDS2 form explains how to get one and read it. Never test a device that is connected to a patient.
A few remaining questions
Does a device with no network connection need one?
FDA's guidance says it "is not limited to devices that are network-enabled or contain other connected capabilities." It covers devices with software, firmware or programmable logic. The legal "cyber device" definition in section 524B is narrower and includes the ability to connect to the internet. FDA reads that widely and lists USB and serial ports among its examples. Your regulatory lead should make that call.
Can a vulnerability scanner produce the assessment?
No. A scanner finds known flaws, which helps with row 8. It does not build the threat model, tie a threat to patient harm, or decide what risk you accept.
Can a consultant guarantee FDA will accept the file?
No. FDA decides. Ask a firm what it will deliver and what help it gives if FDA comes back with questions, and get that in writing.
How we checked
We compare specific offers against stated buying needs and show our sources. For this page we read FDA's guidance and each provider's public page on October 10, 2026. We did not buy a service, talk to these providers or read a delivered file. The example device and buyer are made up. We don't perform, authorize or certify security work. Read how we check offers and how we make money.
For the guidance's edition history, see our FDA cybersecurity guidance tracker. For the standards FDA names, see medical device cybersecurity standards. For the software parts list, see FDA SBOM requirements.
Sources, all checked October 10, 2026
- FDA guidance page: edition, date, status
- FDA guidance PDF: Sections I to VII.C.1, including security risk management (V.A) and testing (V.C)
- ArmadilCo, Cybersecurity Risk Assessment: deliverables and engagement options
- Blue Goat Cyber, Medical Device Threat Modeling: deliverables and pricing approach
- CyberMed, services: Gap Analysis and 30-Day CyberSprint
- Medcrypt, pricing: platform price and inclusions
- The RND Group, cybersecurity: Premarket Package and Cyber Quality System Framework