It usually starts with an email. A security researcher — or a customer’s IT team, or an ICS-CERT advisory — tells you that a device you’ve already shipped, one sitting in hospitals right now, has a vulnerability. The room splits in two. One half wants to push a quiet patch and move on. The other half wants to know whether you’ve just triggered a reporting obligation to the FDA.
Both instincts are reasonable. Both are also premature, because they skip the one determination that decides everything that follows. FDA’s postmarket cybersecurity framework doesn’t ask “is there a vulnerability?” It asks: is the residual risk of patient harm controlled, or uncontrolled? Almost every downstream obligation — whether you report, how fast you must move, whether you can ship a routine patch or must file a correction — hangs on which side of that line you land.
The line that decides everything
FDA defines the two states cleanly:
- Controlled risk — there is sufficiently low (acceptable) residual risk of patient harm from the vulnerability.
- Uncontrolled risk — there is unacceptable residual risk of patient harm, because mitigations and compensating controls are insufficient.
You move from “a vulnerability exists” to one of those two labels through a risk assessment with three inputs: the exploitability of the vulnerability, the impact of exploitation on the device’s safety and essential performance, and the severity of patient harm if it were exploited. Notice what is not on that list: how embarrassing the bug is, how loud the disclosure was, or whether data was exposed. The framework is relentlessly focused on physical patient harm.
A vulnerability that exposes protected health information but does not affect the device’s safety or essential performance is treated as controlled risk. For FDA’s purposes here, loss of confidentiality is not “patient harm,” and the fix is a routine update rather than a reportable correction. Your HIPAA obligations are entirely separate and still very much apply — but that is a different agency and a different statute.
Controlled risk: the routine-update lane
When your assessment lands on controlled, you are in the lane most cybersecurity work lives in. A change made solely to strengthen security against a controlled-risk vulnerability is treated as a device enhancement — a cybersecurity routine update or patch — and is generally not required to be reported under 21 CFR Part 806, the corrections-and-removals rule.
FDA’s own examples make the boundary concrete:
- A blood gas analyzer is found infected with malware, but the malware doesn’t alter data and doesn’t touch safety or essential performance. The manufacturer tells users how to remove it and adds a defense-in-depth control. Routine update. Not reportable.
- A misconfigured database setting could let an unauthorized user view patient data — but not edit it, and safety isn’t affected. The manufacturer publishes the secure configuration. Controlled. Routine update.
- An unused communication port is flagged, but a design feature already blocks unauthorized firmware loads, so exploitation would require physical access. The manufacturer closes the port anyway. Enhancement. No Part 806 report.
One caveat catches PMA holders: even when a change is a routine update, Class III / PMA devices with periodic reporting obligations should still capture it in the annual report under 21 CFR 814.84. “Not reportable as a correction” is not the same as “invisible to FDA.”
Uncontrolled risk: the clock starts
When the residual risk is uncontrolled, the posture changes completely. Now you must remediate as quickly as possible, and you must report the vulnerability to FDA under 21 CFR Part 806 — unless it is already being reported under Part 803 (medical device reporting) or Part 1004.
This is where teams either over-report out of fear or under-report out of optimism. The framework is more specific than either. FDA carved out an explicit set of conditions under which it does not intend to enforce the Part 806 reporting requirement for an uncontrolled-risk vulnerability. Think of it as a safe harbor — and it is all-or-nothing.
1. No known serious harm. There are no known serious adverse events or deaths associated with the vulnerability.
2. Communicate within 30 days. No later than 30 days after learning of it, you notify customers and the user community, identify interim compensating controls, and publish a remediation plan with a documented timeline.
3. Fix within 60 days. No later than 60 days after learning of it, you deploy a validated fix — or a compensating control that durably brings residual risk to acceptable — to your installed base.
4. Active ISAO membership. You actively participate in an Information Sharing and Analysis Organization that shares medical-device threats, and you share the vulnerability with it.
Meet all four, and FDA does not intend to enforce Part 806 reporting for that vulnerability. Miss any one, and you report. The condition that trips up the most manufacturers is the fourth: if you are not an active ISAO member, the safe harbor simply isn’t available to you — no matter how fast you move.
FDA’s own example is blunt about it. A manufacturer learns its implantable cardiac device can be reprogrammed by an unauthorized user because of a hardcoded password — uncontrolled risk, potentially life-threatening. It ships a validated emergency patch within 60 days. But because it is not an active ISAO member, it must report the action to FDA under 21 CFR 806.10. Same speed, same fix — a different reporting outcome, decided entirely by an ISAO membership it could have arranged years earlier.
When it escalates past Part 806
Two escalations sit above the controlled/uncontrolled split.
If harm has occurred. If a vulnerability is exploited and contributes to a serious injury or death — or would be likely to if it recurred — you are into 21 CFR Part 803 medical device reporting territory, on top of any corrective-action reporting. The “view-only data” analyzer and the “a patient was harmed” scenario are worlds apart, and the framework treats them that way.
If you do nothing. FDA’s most consequential sentence on the subject: in the absence of remediation, a device with uncontrolled risk of patient harm may be considered to have a reasonable probability of causing serious adverse health consequences or death — and may be deemed in violation of the FD&C Act, subject to enforcement. Uncontrolled-and-ignored is not a gray area.
The framework doesn’t punish having a vulnerability. Every connected device has them. It punishes being unprepared to triage and respond to one on a clock you didn’t set.
What Section 524B changed
Here is the part that turns all of the above from “good practice” into “the law.” Everything described so far comes from FDA’s 2016 postmarket guidance, which — like all guidance — is non-binding by its own terms. For years, a manufacturer could read it as optional.
That ended with Section 524B of the FD&C Act, added by the Consolidated Appropriations Act, 2023 and effective March 29, 2023. For “cyber devices,” 524B makes a set of postmarket commitments a statutory premarket requirement: a plan to monitor, identify, and address postmarket vulnerabilities; processes that provide reasonable assurance of cybersecurity, including the ability to ship updates and patches; a coordinated vulnerability disclosure process; and a software bill of materials. FDA’s premarket cybersecurity guidance — most recently the Quality Management System Considerations version (February 2026) — now incorporates 524B directly.
The practical consequence: the controlled/uncontrolled framework is no longer just how a responsible manufacturer should behave after a disclosure. It is the operating logic of the postmarket plan that 524B requires you to have committed to before you ever shipped. The plan is the promise; the framework is how you keep it.
The playbook, in order
When a vulnerability lands, the manufacturers who stay out of trouble run the same sequence:
- Acknowledge receipt to whoever reported it — that is your CVD policy doing its job.
- Assess the risk: exploitability, impact on safety and essential performance, and severity of patient harm. Land it on controlled or uncontrolled.
- If controlled: ship the routine update, document it, and (for PMA / Class III) note it in the annual report. Done.
- If uncontrolled: start the clock. Communicate and stand up interim compensating controls within 30 days; deploy a validated fix within 60.
- Decide the reporting question: can you satisfy all four safe-harbor conditions, including active ISAO membership? If not, file under 21 CFR Part 806. If harm occurred, file under Part 803.
- Re-assess significance: is the change large enough to require a new premarket submission (a 510(k) or PMA supplement), not just a postmarket action?
None of these steps are hard in isolation. What makes them hard is doing them for the first time under a 30-day clock, while a researcher’s disclosure deadline runs in parallel and your customers are forwarding the advisory to your sales team.
The takeaway
The difference between a vulnerability that becomes a quiet routine update and one that becomes a reportable correction — or an FD&C Act violation — is rarely the severity of the bug. It is whether you had the machinery in place before the email arrived: a written CVD policy, an active ISAO membership, a postmarket plan that can actually execute on a 30/60-day cadence, and a risk-assessment method that can put “controlled” or “uncontrolled” on a vulnerability with a straight face.
Under 524B, that machinery isn’t a nice-to-have you build after your first incident. It is a statutory commitment you made in your premarket submission. The controlled/uncontrolled framework is simply the moment that commitment gets tested — usually with very little warning.