If your medical device connects to anything, whether a phone, a hospital network or the internet, your FDA submission now needs a cybersecurity section, and the threat model sits in the middle of it. Since Section 524B of the Federal Food, Drug, and Cosmetic Act took effect in March 2023, FDA can refuse to accept a submission for a "cyber device" that's missing the cybersecurity information the law requires. The guidance describes the documents reviewers expect to see. It says much less about how to produce a threat model they'll accept.
This guide works through one device, a connected insulin pump, from architecture views to residual risk. Along the way it covers the two places most submissions go wrong: scoring security risk like safety risk, and losing the trail from a threat to its control and then to the test that proves the control works.
The short version: draw the whole system, including the phone, the cloud and the update path, as architecture views with trust boundaries. Identify threats per element and flow, and break the serious ones into attack paths. Rate each threat by exploitability and impact rather than probability, and send any threat that could hurt a patient into your ISO 14971 safety risk file as well. Map every control to a test, and keep the model current after clearance, because Section 524B also requires a postmarket plan and an SBOM.
What FDA actually asks for
Two documents set the expectations. Section 524B, added by the Consolidated Appropriations Act, 2023, is the law. It applies to cyber devices: devices that include software, can connect to the internet, and have characteristics that could be vulnerable to cybersecurity threats. Their sponsors must submit a plan to monitor, identify and address postmarket vulnerabilities (including coordinated vulnerability disclosure), show processes that give reasonable assurance the device and related systems are cybersecure, and provide a software bill of materials.
The second is FDA's guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions. It was finalised in September 2023 and has been revised since, so check fda.gov for the current version before you submit. The guidance places cybersecurity inside a secure product development framework (SPDF) and lists the documents reviewers look for. The threat model feeds most of them:
| Submission element | What it shows | Where it comes from |
|---|---|---|
| Threat model | Threats across the whole system, the assumptions behind them, and the countermeasures | The architecture views, threats and attack paths in steps 1 to 3 |
| Security architecture views | Global system, multi-patient harm, updatability and patchability, security use cases | Step 1, plus your update process documentation |
| Cybersecurity risk assessment | Each threat rated before and after controls | Steps 4 and 6 |
| Security controls and testing | That each control exists and that testing shows it works | Step 5 |
| SBOM and component risk | Components, their support status and known vulnerabilities | An SBOM tool, linked to the elements in your model |
| Postmarket plan | How you'll find and fix vulnerabilities after clearance | Step 7 |
The worked example: a connected insulin pump
Our device is an insulin pump with a continuous glucose monitor (CGM). The CGM sends readings to the pump over Bluetooth LE, and the pump's automated dosing algorithm adjusts insulin delivery from them. A companion app on the patient's own phone shows readings, sends bolus commands and installs pump firmware. The app uploads therapy data to the manufacturer's cloud, where a clinic portal lets the diabetes care team review their patients and feed reports into the clinic's EHR over FHIR. Firmware releases are signed with keys held in an HSM.
Notice how little of that is the pump itself. FDA's guidance expects the threat model to cover the device and the systems around it, so the phone, the cloud and the update path are all in scope. A model that stops at the pump's enclosure is one of the most common reasons reviewers send questions back.
Step 1: Draw the architecture views
The guidance asks for several views of the system's security architecture. Three of them are diagrams you'd draw for any threat model anyway:
- Global system view: every component, interface and data flow, from the CGM to the EHR. A data flow diagram does this job. Draw one trust boundary around the on-body devices (anyone within Bluetooth range is outside it) and another around the manufacturer's cloud.
- Multi-patient harm view: where one compromise could affect many patients at once. Here that means the cloud, the clinic portal and the firmware release path, because each one touches every pump or every patient record.
- Updatability and patchability view: how a fix travels from the signing HSM, through the app, to a pump on someone's body, and what checks it passes on the way.
The fourth, security use case views, walks through specific operations with their security controls, for example "patient requests a bolus" or "pump installs an update". Write the operations that can cause harm first.
Step 2: Identify threats element by element
Go through each element and each flow that crosses a trust boundary, and ask what could go wrong with it. STRIDE keeps that systematic, and FDA doesn't require any particular method. For the pump system, nine threats stand out:
- T1 (spoofing): the pump pairs over Bluetooth LE without authentication ("Just Works"), so someone nearby can pair a rogue controller.
- T2 (tampering): bolus commands carry no per-message authentication or freshness, so a recorded command can be replayed.
- T3 (tampering): forged CGM readings make the dosing algorithm deliver insulin the patient doesn't need.
- T4 (elevation of privilege): malware on a rooted or out-of-date phone drives the app to send commands.
- T5 (tampering): a malicious firmware image is installed because only the app, not the pump, checks the signature.
- T6 (spoofing): credential stuffing against the clinic portal, which has no MFA, opens every patient record at that clinic.
- T7 (information disclosure): the portal checks clinic membership but not the patient-clinic link, so changing an ID returns another clinic's patient, a classic IDOR.
- T8 (information disclosure): readings and dosing history travel over Bluetooth without link-layer encryption.
- T9 (information disclosure): the FHIR feed sends a patient's full history, including data they only shared with a different clinic.
T1 and T2 aren't hypothetical. In 2019 FDA warned that some Medtronic MiniMed insulin pumps could be reached over their unauthenticated radio protocol, and the company recalled them. Reviewers know that history, so expect questions about pairing and command authentication on any pump.
Step 3: Break harmful goals into attack paths
For the threats that could hurt someone, build an attack tree with the harm as the goal. The goal here is deliver an unsafe insulin dose. Under it, an OR gate splits into four routes: impersonate the app, spoof CGM readings, use malware on the phone, or install malicious firmware. Impersonating the app is an AND: the attacker needs a radio link they control (T1) and a pump that acts on commands it can't verify (T2).
That AND tells you something useful. Authenticated pairing or authenticated commands would close the path on their own, so you can choose which to rely on and test it hard. The guidance also asks you to state your assumptions, so write the ones the tree depends on, such as "the attacker is within Bluetooth range" or "the phone may be rooted".
Step 4: Assess security risk by exploitability, not probability
This is where device teams most often apply the wrong habit. ISO 14971 safety risk management estimates the probability of harm, which works for component failures with known failure rates. Attackers don't fail at a predictable rate, so FDA's guidance, like AAMI TIR57 and AAMI SW96, steers security risk assessment towards exploitability: how easily someone could carry out the attack, given the access, skill and equipment it needs. Write the reasoning down. "Requires being within 10 metres of the patient with a standard BLE dongle" is a rating a reviewer can check; "2" on its own isn't.
| Threat | Exploitability (1–5) | Impact (1–5) | Score | Patient harm? |
|---|---|---|---|---|
| T2 Replayable bolus | 3 | 5 | 15 | Yes, single patient |
| T4 Phone malware | 3 | 4 | 12 | Yes, single patient |
| T6 Portal takeover | 3 | 4 | 12 | No, but many patients' data |
| T7 Cross-clinic access | 3 | 4 | 12 | No, but many patients' data |
| T1 Unauthenticated pairing | 2 | 5 | 10 | Yes, single patient |
| T3 Spoofed CGM | 2 | 5 | 10 | Yes, single patient |
| T8 Readable BLE | 3 | 3 | 9 | No |
| T9 EHR over-share | 2 | 4 | 8 | No |
| T5 Malicious firmware | 1 | 5 | 5 | Yes, multi-patient |
The last column is the link between the two risk processes. Every threat stays in the security risk assessment. The ones whose exploit could lead to patient harm also go into the ISO 14971 safety risk file as hazardous situations, where they get a severity of harm (an insulin overdose is catastrophic) alongside every other hazard. The data exposure threats, T6 to T9, stay security risks only. They're still real risks, with HIPAA consequences on the cloud side, but they won't hurt a patient physically.
Now look at T5. It has the lowest score in the table, because forging a signed firmware image or stealing a key from an HSM is hard. It's also the only threat where one success harms every patient whose pump installs the update. That's exactly what the multi-patient harm view exists to surface, and why a low exploitability score is never a reason to weaken firmware signing. If your risk register sorts only by score, add the harm scope as a column so reviewers can see it.
Step 5: Choose controls and trace each one to a test
The guidance groups security controls into categories: authentication, authorization, cryptography, code, data and execution integrity, confidentiality, event detection and logging, resiliency and recovery, and firmware and software updates. Naming the category for each control makes coverage gaps visible. Then give each control a test, because the guidance expects testing evidence that the controls work, not just a list of them.
| Threat | Control | Category | Evidence |
|---|---|---|---|
| T1, T2 | Authenticated pairing (numeric comparison or a code shown on the pump); every command carries a MAC and a counter | Authentication, cryptography | Pairing test with a rogue controller; replay of captured commands is rejected |
| T2, T4 | Pump firmware enforces maximum bolus and daily limits, whatever the app sends | Safety risk control | Verification that out-of-range commands are refused |
| T3 | Authenticated sensor link; physiologically implausible jumps are rejected and the pump falls back to safe basal delivery | Data integrity, resiliency and recovery | Fuzzing of the CGM link; fault injection of impossible readings |
| T5 | The pump's bootloader verifies the signature, keys stay in an HSM, downgrades are blocked | Code integrity, firmware and software updates | Unsigned, re-signed and older images are refused; penetration test of the update path |
| T6, T7 | SSO with the clinic's identity provider and MFA; every patient query scoped to the requesting clinic | Authentication, authorization | Automated test with two clinics in CI; penetration test of the portal |
The second row matters more than its length suggests. A firmware dose limit isn't a security control, but it caps the harm of every path in the attack tree, including the ones you haven't thought of yet. Count it in the safety file, and mention it in the security assessment as the reason the residual harm is bounded. The dashed arrow in the figure is there because controls also add risk: the new pairing flow and the HSM are themselves elements to threat model.
Step 6: Re-rate and record residual risk
Re-score each threat with its controls in place. With per-command authentication, T2's attack needs the session key, so its exploitability drops from 3 to 1 and its score from 15 to 5. The dose limits also mean a successful attack can no longer deliver an unlimited bolus. The difference between the before and after scores is your residual risk. Record who accepted it and why it's acceptable, in both files where the threat appears.
Step 7: Keep the model alive after clearance
Section 524B makes postmarket work part of the premarket submission: you must show how you'll monitor, identify and address vulnerabilities, including through coordinated disclosure. The threat model is how you'll judge each new report. Link SBOM components to the elements they run on, so that when a vulnerability lands in the pump's Bluetooth stack, as the SweynTooth flaws did in 2020 for several BLE chipsets used in medical devices, you can reopen T1, T2 and T8 within minutes rather than starting from scratch. Our guide on when to re-threat model lists the other triggers.
What reviewers push back on
- Device-only scope. No phone, no cloud, no update path. The guidance expects the whole system.
- A generic threat catalogue. Hundreds of rows copied from a list, none tied to this device's interfaces, can't be prioritised or defended.
- Probability scores for security risk. Use exploitability, and write down why each value was chosen.
- Broken traceability. A reviewer should be able to pick any threat and follow it to its control, its test and its residual risk, and back again.
- No multi-patient analysis. If one compromise can reach many devices or records, the submission needs to say so and show what limits it.
- A model frozen at submission. The postmarket plan is only credible if the threat model is the thing you update when a vulnerability report arrives.
Frequently asked questions
What is a cyber device under Section 524B?
A device that includes software validated, installed or authorized by the sponsor, has the ability to connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats. FDA reads "ability to connect" broadly, so devices that connect through a phone, a USB port or a hospital network are usually in scope.
Does FDA require a specific threat modeling method?
No. The guidance describes what the threat model and risk assessment must show, not which technique produces them. STRIDE, attack trees and data flow diagrams are all common, and many teams combine them as this example does.
How is security risk assessment different from ISO 14971?
ISO 14971 estimates the probability and severity of harm, which suits random failures. Security risk assessment rates exploitability instead, because attacks aren't random. Threats that could lead to patient harm belong in both: assessed for security, and recorded as hazardous situations in the safety risk file.
What is the multi-patient harm view?
One of the security architecture views in FDA's guidance. It shows where a single compromise, such as of a cloud service, a shared credential or the update path, could affect many patients or devices at once, and what controls limit that.
Is the SBOM part of the threat model?
It's a separate submission element, but the two should be linked. The SBOM lists the components; the threat model shows which elements they run on and which threats a vulnerability in each one would affect. That link is what makes postmarket vulnerability assessment fast.
Building a connected device? See threat modeling for medical devices for how the submission elements map to ThreatTree, and our TARA worked example for the same exercise under the automotive standard.