A cyber issue becomes an FDA issue when it can affect how a medical device works or put a patient at risk. That is the short answer.
If I had to boil the article down, I’d put it this way:
- A vulnerability is not the same as an incident
- An event is not always reportable
- FDA cares most about device safety, performance, and intended use
- MDR can apply even if no one was hurt, if the problem could lead to death or serious injury if it happens again
- Part 806 can apply when a fix or field action is made to reduce a risk to health
- Timing matters: MDR is often 30 calendar days for manufacturers, while Part 806 is often 10 working days from starting the correction or removal
- Your records matter as much as your decision
In plain terms, I’d ask one question first: Can this cyber issue change therapy, delay care, block alarms, alter outputs, or stop the device from working as expected? If the answer is yes, it likely needs FDA review.
A few examples make the line clearer:
- Malware on a hospital network with no effect on device function: often an IT problem, not an FDA reporting issue
- A cyber exploit that changes an infusion pump’s dose: likely FDA-reportable
- Alarm disruption in an ICU device: likely FDA-reportable
- A portal flaw with no path to patient harm: often not reportable
Here’s the key split:
| Item | What it means | What I’d do first |
|---|---|---|
| Vulnerability | A weakness that could be used | Check whether it can affect patient care with medical device cyber risk management |
| Event | Something happened, like malware detection or a failed access attempt | Check device impact before treating it as an incident |
| Incident | The issue affects, or could affect, device safety or performance | Review MDR and Part 806 right away |
So the core lesson is simple: FDA does not focus on the cyberattack alone. It focuses on what the cyber issue could do to the device and the patient.
That’s the frame I’d use for every review, every report decision, and every incident file.
A Quick Primer on FDA's Final Guidance for Cybersecurity in Medical Devices
sbb-itb-535baee
How FDA defines a cybersecurity incident
FDA defines a cybersecurity incident based on what it could do to a device's safety, performance, or intended use, not just whether data was exposed or a network was hit.[7][10] In plain English, the issue matters to FDA when an exploit could stop therapy, slow it down, change it, interfere with key clinical performance, or lead to serious harm.[8][10][11]
FDA's 2016 Postmarket Management of Cybersecurity in Medical Devices guidance draws a clear line between controlled and uncontrolled risk. A vulnerability is controlled when the residual risk is low and acceptable. It becomes uncontrolled when exploitation could reasonably cause harm.[6][13]
How FDA separates vulnerabilities, events, and incidents
FDA's framework gets easier once you break it into three terms: vulnerability, event, and incident.[7][10][12]
| Term | What it means | FDA relevance |
|---|---|---|
| Vulnerability | A weakness in software, hardware, configuration, or architecture that could be exploited | Not automatically reportable; depends on exploitability and patient harm potential |
| Event | An occurrence or observation related to that environment, such as malware detection, anomalous device traffic, or an unauthorized access attempt | Assessed for patient-safety or device-performance impact before it is treated as an incident |
| Incident | An event or vulnerability that affects, or could reasonably affect, device safety or performance | Potentially triggers MDR or Part 806 reporting obligations |
That line matters. It decides whether the issue stays a routine security problem or moves into FDA reporting review.
Why device risk is the central question, not general IT impact
FDA looks at cyber issues through one main lens: their effect on a medical device's safety, performance, and intended use.[7][10][4] So, not every cyber problem turns into an FDA issue.
A hospital-wide ransomware attack that disrupts scheduling software, while connected devices keep working as intended, is mainly an IT problem. But an exploit that lets someone change an infusion pump's dose rate, or disable a life-support function, is a different story. That sits squarely in FDA territory because the risk of serious patient harm is direct.[10][2][11]
If the issue could disable alarms, change therapy, delay diagnosis, or affect life-support, treat it as an incident-level risk.
When a cybersecurity issue becomes reportable to FDA
FDA Medical Device Cybersecurity: Vulnerability vs. Event vs. Incident Reporting Guide
Once a cyber issue affects device safety, performance, or intended use, it needs a closer look under FDA reporting rules. At that point, the main question is simple: does this issue cross the line into device risk? If it does, you then test it against MDR and Part 806 thresholds.
Medical Device Reporting triggers under FDA rules
Under 21 CFR Part 803, a cybersecurity issue becomes MDR-reportable when a device caused or contributed to a death or serious injury, or when it malfunctions in a way that would likely cause death or serious injury if it happened again.[16][5][18]
That point matters because FDA does not limit MDRs to harm that already happened. A near-miss can count too, as long as the malfunction would likely lead to harm if it recurred.[14][10]
There are also firm reporting deadlines. Manufacturers must submit MDRs within 30 calendar days of becoming aware of a reportable event. User facilities must report device-related deaths to FDA and the manufacturer within 10 work days, and serious injuries to the manufacturer within that same period.[5][17]
A practical way to assess each case is to use the same plain-language test: does the issue create a credible path to patient harm?
| Cybersecurity scenario | Likely MDR-reportable? | Why |
|---|---|---|
| Ransomware disrupts infusion pumping, causing unintended stop or incorrect dosing | Yes | Unintended stop or incorrect dosing can cause serious harm; a repeat near-miss is also reportable[14][10] |
| Exploitation of a cardiac implant programmer causes incorrect parameter settings with plausible risk of arrhythmia or cardiac arrest | Yes | Incorrect parameter settings create a plausible risk of arrhythmia or cardiac arrest if it recurred[14][4] |
| Cyber attack disables ICU alarm notifications, leading to delayed response and serious injury | Yes | Delayed response to critical alarms can lead to serious injury[14][10] |
| Vulnerability in a non-clinical analytics portal with no pathway to affect therapy or critical monitoring | No | No credible pathway to patient harm[1][10] |
| Temporary loss of access to historical data with no influence on immediate diagnosis or treatment | No | No serious harm pathway identified[1] |
When corrections and removals may require 21 CFR Part 806 reporting
Under 21 CFR Part 806, a correction or removal must be reported when it is made to reduce a risk to health or to fix a violation that may present a risk to health.[15][2]
In practice, that usually means the reason for the action matters more than the fact that an update was issued. For example, a mandatory update meant to reduce a direct risk to health - such as stopping remote tampering with life-support equipment, paired with urgent field communications that require immediate action - will generally trigger Part 806 reporting.[15][2]
By contrast, routine patches are usually not reportable unless they address a risk to health. Standard operating system updates, vulnerability patches, and standard hardening measures that do not reflect an uncontrolled risk to health fall outside Part 806 scope.[1][10][3]
For each decision, document the trigger you relied on and the facts that support it.
FDA reporting pathways and a comparison of incident types
Mandatory and voluntary reporting channels
Once a cybersecurity issue crosses the FDA-relevance threshold, the next step is simple: route it based on who is reporting and what happened.
FDA reporting duties change depending on the reporter and the kind of event involved. Manufacturers and importers report under MDR. They also file Part 806 reports when they start a correction or removal to reduce a risk to health or to address a violation that may present that kind of risk. Device user facilities - such as hospitals, ambulatory surgical facilities, nursing homes, and outpatient diagnostic or treatment facilities - have MDR duties too. Deaths must be reported to both FDA and the manufacturer. Serious injuries go to the manufacturer, or straight to FDA if the manufacturer is unknown.[23]
Healthcare providers and patients don't have mandatory MDR duties. Still, FDA urges them to report concerns through MedWatch - Form 3500 for healthcare providers and Form 3500B for patients and caregivers.[2][19] That matters because MedWatch can help FDA spot patterns before an issue becomes something that must be reported. This proactive approach is essential for measuring what matters for cybersecurity in clinical environments.
How to use the comparison table
When a cybersecurity issue lands on your desk, begin with the Report trigger column. Then check Reporter to see whether the duty sits with your organization or someone else. A single issue can lead to more than one report, so this table helps sort the event before you decide whether MDR, Part 806, or MedWatch fits.
| Incident type | Reporter | FDA pathway | Report trigger |
|---|---|---|---|
| MDR-reportable event | Manufacturer, importer, or device user facility as applicable | Medical Device Reporting | Death, serious injury, or a recurring malfunction likely to cause either[21][22][23] |
| Correction or removal | Manufacturer or importer | 21 CFR Part 806 | Correction or removal to reduce a risk to health[20] |
| Voluntary cybersecurity concern | Healthcare provider, patient, caregiver, or other voluntary reporter | MedWatch | Safety concern or suspected device problem[2][19] |
One timing point trips people up: Part 806 reports are due within 10 working days of starting the correction or removal, not when the vulnerability was first found.[20] MDR timelines are separate.
A practical way to triage the issue is to ask three short questions:
- Was there harm?
- Was there a corrective action?
- Who is the reporter?
Those three checks help route the issue and document why you made that call. They also give you a clean starting point for the incident record and the reporting decision.
How to document the incident assessment and close the loop
Key records FDA-related teams should maintain
Use the same facts that shaped the MDR or Part 806 decision to build the incident file. Once the reporting path is set, create the record that backs it up. That file should show how the issue affected, or could have affected, device safety and performance. Start with the basics: device identification, including product code, trade name, model, serial or lot number, and FDA clearance or approval. Then add a plain description of the vulnerability or exploit, how it was found, and whether the device was in active clinical use at the time.[2]
Next comes the patient safety question. The record should answer it directly. Document whether clinical performance could be affected, such as delayed alarms, incorrect therapy delivery, or altered device outputs, and include the evidence behind that conclusion.[7][9] If bench testing or simulated scenarios were used to check whether the vulnerability changed device behavior, include the protocols, test environments, and results. If testing shows no clinical impact, say that plainly and tie it to the decision not to file under MDR or Part 806.[7][24]
The reporting decision rationale should have its own place in the file. Write down why the issue is or is not reportable, who made that call, and when the call was made. Record the exact reason for the correction or removal and who approved it. Keep copies of customer notices, along with the date sent, the intended audience, and the remediation timeline.[25][26]
After testing and documentation, the last step is showing that residual risk is acceptable. Close the loop with a monitoring log. After patching or applying a configuration fix, record the validation steps, deployment timeline, and any follow-up testing that confirms the residual risk is now at an acceptable level.[7][27] In plain English, this shows the fix reduced risk, not just the symptoms. The log becomes the record that the risk came down and the issue was closed.
A shared platform can help teams keep these records current. Censinet RiskOps™ can support collaborative risk assessments, documentation workflows, and risk tracking for medical devices and connected vendor environments.
Conclusion: The practical test for FDA relevance
FDA's framework is device-centered and risk-based. A vulnerability sitting on a network server is an IT issue. That same vulnerability becomes a potential FDA matter if it could change how a patient monitor reports vitals or how an infusion pump delivers therapy.[7][9] That's the line that matters: does this affect device safety or clinical performance? Every assessment should answer that question and document the answer.
Not every vulnerability becomes reportable. The practical test is simple: does it affect device safety or clinical performance?
Clear records help protect patients, support defensible compliance, and give FDA the information it needs to spot patterns across the device ecosystem. The point isn't paperwork for its own sake. It's being able to show, at any time, that the right people asked the right questions and acted on the answers.
FAQs
What counts as a credible path to patient harm?
A path to patient harm exists when a vulnerability sets up a realistic chain of events that could lead to death or serious injury. You do not need proof that harm has already happened.
Instead, manufacturers look at two things: how exploitable the vulnerability is, and what the clinical impact could be. In plain terms, they assess whether it could realistically disrupt device function or clinical care and create an unreasonable risk to patient safety.
Can a near-miss still be reportable to FDA?
Yes. A near-miss can still be reportable if a cybersecurity issue or device malfunction could lead to death or serious injury if it happens again.
Routine security updates usually aren't reportable. But if a vulnerability leads to a correction or removal to reduce a health risk, it must be reported under 21 CFR Part 806 within 10 working days.
Manufacturers should also document the investigation and the reason behind their reporting decision.
How should teams document a non-reportable cyber issue?
If a cyber issue doesn't meet the FDA reporting threshold, teams should still document it through internal tracking and QMS change control. They should also note why it wasn't reportable in the device's risk management file and keep that record ready for inspection.
If the decision involves not filing a report for an apparent malfunction, a qualified professional must document the reason.
