How to Establish Patch Management and Security Update Process

To establish a patch management and security update process for a medical device, write a cybersecurity management plan with the elements FDA lists in Section VI.B of its premarket cybersecurity guidance (February 2026), monitor the sources that plan names, assess each vulnerability as controlled or uncontrolled risk, and release patches on the two clocks Section 524B(b)(2) of the FD&C Act sets: a reasonably justified regular cycle for known unacceptable vulnerabilities, and as soon as possible out of cycle for critical vulnerabilities that could cause uncontrolled risk. Then communicate, deploy, and record. This post walks through each step and separates what the statute requires from what FDA recommends.

What governs patching

Three documents set the expectations, and they carry different weight.

Section 524B of the FD&C Act is the statute. It applies to cyber devices, which are devices that include software, can connect to the internet, and have characteristics that could be vulnerable to cybersecurity threats. For those devices, Section 524B(b)(1) requires a plan to monitor, identify, and address postmarket vulnerabilities and exploits in a reasonable time, including coordinated vulnerability disclosure. Section 524B(b)(2)(A) requires updates and patches for known unacceptable vulnerabilities on a reasonably justified regular cycle. Section 524B(b)(2)(B) requires updates and patches as soon as possible out of cycle for critical vulnerabilities that could cause uncontrolled risks. Our guide to Section 524B requirements covers the full statute.

FDA's premarket cybersecurity guidance (February 3, 2026) recommends how to meet those obligations. Section VI.B lists the elements of a cybersecurity management plan. Section VII.C.1 says the plan should describe the timeline, with justifications, for developing and releasing patches. Appendix 1 describes the design features that make patching possible.

FDA's postmarket cybersecurity guidance (December 2016) defines controlled and uncontrolled risk, describes how to assess exploitability and severity of patient harm, and sets out the conditions under which FDA does not intend to enforce reporting under 21 CFR Part 806.

Standards such as ANSI/AAMI SW96:2023, AAMI TIR97:2019 (R2023), and AAMI TIR57:2016 (R2023) describe methods. They are voluntary consensus standards. Conforming to them helps you meet the statute and the guidance, but they are not themselves regulatory requirements.

Step 1: Write the plan

The cybersecurity management plan is both the policy and the premarket deliverable. For a cyber device, the plan is required by Section 524B(b)(1), and FDA recommends it contain the Section VI.B elements:

• Personnel responsible. Name the roles that own monitoring, assessment, patch development, verification, release, and customer communication. Name the decision maker for the controlled or uncontrolled call.
• Sources, methods, and frequency for monitoring and identifying vulnerabilities. The guidance gives examples: researchers, the NIST National Vulnerability Database, and third-party software manufacturers.
• How you identify and address vulnerabilities in CISA's Known Exploited Vulnerabilities Catalog. This is a separate line item in the guidance, so treat it as one in your plan.
• Periodic security testing. State the interval and tie it to risk. Section V.C gives annually as an example.
• Timeline to develop and release patches. This is where the Section 524B(b)(2) cycles live. State the regular cycle, the justification, and the out-of-cycle process.
• Update processes. How a patch moves from build to device, matching the updatability and patchability view in your architecture documentation.
• Patching capability. The guidance defines this as the rate at which updates can be delivered to devices. If updates need a field service visit, say so and estimate the time to reach the installed base.
• Your coordinated vulnerability disclosure process. Intake, acknowledgment, triage, and disclosure. See our chapter on coordinated vulnerability disclosure.
• How you communicate remediations, patches, and updates to customers. Channels, content, and who sends them.

The regular cycle needs a written justification. The guidance's footnote on the topic says the length "may vary depending on numerous factors" and that risk is a primary one. It contrasts a connected thermometer with a connected surgical robot, then adds that exploiting a low-risk device "may provide opportunities to affect other devices within the environment of use." A justification that considers the device's own harm potential and its position in the clinical network will hold up.

Section VII.C.1 adds one more expectation: update the plan as new risks, threats, and vulnerabilities appear, and keep the threat model and risk assessment current so you can judge a new vulnerability's impact quickly.

Step 2: Monitor for vulnerabilities

Monitoring runs on the sources in your plan, at the frequency in your plan. Our chapter on building a vulnerability monitoring program covers each source. The short version:

• NIST NVD, matched against the components in your SBOM. Automate the match. A current SBOM in a machine-readable format is what makes this possible.
• CISA's Known Exploited Vulnerabilities Catalog. Exploitation in the wild changes the exploitability score, so a KEV entry on one of your components triggers an assessment, not a note.
• Supplier advisories for your operating system, Bluetooth stack, TLS library, and other third-party components. The guidance asks you to know each component's level of support and end-of-support date.
• Security researchers and your CVD intake. The postmarket guidance asks manufacturers to acknowledge receipt of vulnerability reports to the submitter.
• ISAO feeds, such as Health-ISAC, if you participate.
• Complaints and field data. A malfunction report can be a cybersecurity signal. Make sure complaint handling knows what to escalate.

Record each signal with the date you learned of it. The 30-day and 60-day conditions in the postmarket guidance both count from when the manufacturer learns of the vulnerability.

Step 3: Assess each vulnerability

FDA's postmarket guidance asks for a process that assesses two things: the exploitability of the vulnerability and the severity of patient harm if it were exploited, taking existing compensating controls into account.

For exploitability, the guidance cites CVSS version 3.0 as one scoring tool and cautions that the weighting of factors should be considered carefully. We recommend scoring with the MITRE rubric for applying CVSS to medical devices, which adjusts the base metrics for device context. For severity, the guidance uses the qualitative ISO 14971 scale from negligible to catastrophic.

The output is binary. The guidance says that "in all cases, FDA recommends that manufacturers make a binary determination that a vulnerability is either controlled or uncontrolled." Controlled risk means the residual risk of patient harm is acceptable. Uncontrolled risk means it is not, given the compensating controls and mitigations in place.

Two points trip teams up. First, loss of confidentiality alone, such as exposure of protected health information, is not patient harm under the postmarket guidance, though you still have obligations under other laws. Second, Section VII.C.1 of the premarket guidance notes that a "known unacceptable vulnerability" under Section 524B(b)(2)(A) is broader than a "critical vulnerability that could cause uncontrolled risks" under (b)(2)(B). A vulnerability can present controlled risk and still need a patch on the regular cycle to keep the software supportable.

Step 4: Decide the response timeline

The assessment drives the clock.

Determination	Statutory clock (cyber devices)	Reporting under 21 CFR Part 806
Controlled risk	Regular cycle, reasonably justified, per Section 524B(b)(2)(A)	Generally not reportable. FDA treats cybersecurity routine updates and patches as device enhancements.
Uncontrolled risk	As soon as possible, out of cycle, per Section 524B(b)(2)(B)	Reportable under Part 806, unless all four enforcement-discretion conditions are met.

The four conditions come from Section VII.B of the postmarket guidance. FDA "does not intend to enforce reporting requirements under 21 CFR part 806" for a vulnerability with uncontrolled risk when:

1. There are no known serious adverse events or deaths associated with the vulnerability.
2. As soon as possible but no later than 30 days after learning of the vulnerability, you communicate with customers and users, identify interim compensating controls, and develop a remediation plan, with the timeline rationale documented.
3. As soon as possible but no later than 60 days after learning of the vulnerability, you fix it, validate the change, and distribute the fix so residual risk is acceptable.
4. You actively participate in an ISAO that shares medical device vulnerabilities and threats, and you give the ISAO your customer communications.

These are conditions for enforcement discretion, not standalone deadlines. Meet all four and no Part 806 report is expected. Miss one, for instance because the fix takes 90 days or you are not an ISAO member, and the correction is reportable under Part 806. The guidance's own examples show a manufacturer that distributes a patch within 60 days but does not participate in an ISAO, and therefore files under 21 CFR 806.10.

The 30-day customer communication has minimum content: describe the vulnerability and its impact as you currently understand it, state that work is under way, describe compensating controls if any, and state that a fix or defense-in-depth strategy is coming and that you will communicate when it is available.

For PMA devices, report vulnerabilities and the changes made in response in the periodic annual report under 21 CFR 814.84, whether the risk was controlled or uncontrolled. Our post on postmarket cybersecurity responsibilities covers the reporting side in more depth.

Step 5: Build, verify, and release the patch

The patch itself follows your software maintenance process under IEC 62304 and your design change controls under the QMSR, which incorporates ISO 13485:2016. The cybersecurity-specific points come from Appendix 1 of the premarket guidance, under Firmware and Software Updates:

• Keep cybersecurity patches independent of feature release cycles, so a security fix doesn't wait for the next feature train.
• Preserve the full build environment, virtual machines, regression test suites, development kits, and tools used for the original release, so you can build and test a patch years later.
• Plan for the update to fail. The guidance asks you to consider what happens when communication is interrupted at each phase of the update.
• Keep third-party licenses current for the supported life of the device, and have a contingency if a supplier stops supporting a component.

Verify the fix closes the vulnerability and validate that it doesn't introduce new risk. The postmarket guidance asks for software validation of the remediation so that it mitigates the target vulnerability "without unintentionally creating exposure to other risks." Rerun the relevant security tests, not just the functional regression suite. Our chapter on developing and deploying patches walks through the engineering steps, and our post on secure software updates covers signing, verification, and anti-rollback in the update mechanism.

Then decide whether the change needs a premarket submission. The postmarket guidance says FDA typically does not need to review cybersecurity routine updates and patches. Section VII.D.1 of the premarket guidance lists changes that may affect cybersecurity and may need a submission: changes to authentication or encryption algorithms, new connectivity, and changes to the update mechanism itself. Document the decision using FDA's guidance on when to submit a 510(k) for a software change.

Step 6: Deploy and confirm

Deployment is where patching capability becomes real. Track three things:

• Uptake. How many fielded devices have the patch, and how fast is the rate approaching the capability you stated in the plan.
• Fielded versions. Section VII.C.1 says the plan should account for differences in risk between devices that updated and devices that didn't. If updates are not automatic, you have two risk profiles, and both need an assessment.
• Follow-up. The 60-day condition includes following up with end users as needed beyond the initial period.

Communicate at each step. Customers need to know a patch exists, what it fixes, how to get it, and what to do until they have it. Keep every customer notice, because you will attach them to the ISAO submission and, for PMA devices, to the annual report.

Step 7: Plan for end of support

Patching has an end date for every component and for the device. The premarket guidance asks that the SBOM documentation include each component's level of support and end-of-support date, and that labeling tell users when the device itself will stop receiving security support. AAMI TIR97 recommends notifying customers of approaching end-of-guaranteed-support and end-of-support dates at least 18 months in advance.

When a component reaches end of support before the device does, the guidance asks for a plan to update or replace it. Write that plan when you select the component, not when the supplier announces the date.

A process the reviewer and the field can both trust

A patch management process for a medical device has a statutory core and a documented edge. The core is Section 524B: a plan, a justified regular cycle, and out-of-cycle fixes for uncontrolled risk. The edge is the FDA guidance that tells you what the plan should contain, how to assess risk, and what to do within 30 and 60 days if you want enforcement discretion on Part 806 reporting. Build the plan to Section VI.B, assess every vulnerability to a binary answer, and keep the records. The same documents that satisfy the premarket reviewer will carry you through the first real vulnerability.

Need help with your cybersecurity management plan and postmarket documentation? Email us at info@cybermed.ai.

Sources

• FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance, February 3, 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
• FDA. Postmarket Management of Cybersecurity in Medical Devices. Final guidance, December 28, 2016. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/postmarket-management-cybersecurity-medical-devices
• Federal Food, Drug, and Cosmetic Act, Section 524B, Ensuring Cybersecurity of Devices (21 U.S.C. 360n-2). https://www.law.cornell.edu/uscode/text/21/360n-2
• 21 CFR Part 806, Medical Devices; Reports of Corrections and Removals. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-806
• MITRE. Rubric for Applying CVSS to Medical Devices. October 2020. https://www.mitre.org/news-insights/publication/rubric-applying-cvss-medical-devices
• CISA. Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• NIST. National Vulnerability Database. https://nvd.nist.gov/
• ANSI/AAMI SW96:2023. Standard for medical device security, Security risk management for device manufacturers. AAMI.
• AAMI TIR97:2019 (R2023). Principles for medical device security, Postmarket risk management for device manufacturers. AAMI.