Section 524B(b)(2) sets two patch duties for cyber devices. Known unacceptable vulnerabilities get updates on a reasonably justified regular cycle. Critical vulnerabilities that could cause uncontrolled risks get updates as soon as possible, out of cycle. The split depends on whether residual patient risk is controlled.
The two duties in plain terms
According to FDA's February 2026 guidance, section 524B(b)(2)(A) requires cyber device makers to make updates and patches available for known unacceptable vulnerabilities on a reasonably justified regular cycle. Section 524B(b)(2)(B) requires updates and patches to address, as soon as possible out of cycle, critical vulnerabilities that could cause uncontrolled risks.
The guidance defines uncontrolled risk as unacceptable residual risk of patient harm due to inadequate compensating controls and risk mitigations.
What counts as known unacceptable
The guidance says a known unacceptable vulnerability contrasts with a critical one that could cause uncontrolled risks. It could be a vulnerability that could not cause uncontrolled risks, one not currently known to cause uncontrolled risks, or one that could present controlled risk as described in FDA's postmarket cybersecurity guidance.
Patches in this group may be meant to keep software supportable. The guidance says software should generally be regularly updated for that reason. It adds that such updates are not made to reduce uncontrolled risk, so they are not made to reduce a risk to health or to correct a violation of the FD&C Act.
What triggers the out of cycle duty
Critical vulnerabilities that could cause uncontrolled risks. A manufacturer may release updates outside its planned cycle to remediate an uncontrolled risk. FDA's example footnote makes that point directly.
How to apply this internally
A workable triage has two questions for every new finding in the device or a component:
- Can this vulnerability, given the compensating controls in the real environment, leave unacceptable residual risk of patient harm?
- If yes, can we ship a fix outside our schedule?
If the answer to the first is yes, the plan should already say who decides and how fast. If not, the finding joins the regular cycle backlog.
Reachability matters when you triage a component vulnerability. If the vulnerable function is never called in your build, the exploitability assessment is different from a case where it is exposed on a network port. Document the reasoning either way, since the guidance expects assessments of each known vulnerability, including device and system impacts.
Why the cycle needs a written reason
The guidance says the regular cycle's length should be justified, usually in the cybersecurity management plan, and risk is a primary factor. See what the management plan should contain.
Safeguard's reachability analysis can show whether a vulnerable dependency function is actually called in your code. That informs the exploitability question and does not make the regulatory decision.
Quick check
Does every CVE in a component trigger an out of cycle patch?
No. Only critical vulnerabilities that could cause uncontrolled risks do. Others follow the regular cycle, with a recorded risk assessment.
Where is the regular cycle justified?
FDA says the justification should typically be in the cybersecurity management plan, with risk as a primary factor.
Sources
- FDA guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 3, 2026)
- FDA page for Postmarket Management of Cybersecurity in Medical Devices (December 2016)
Last reviewed: 19 October 2026.
