A Guide to Post-Market Cybersecurity Management

Manufacturers have ongoing post-market cybersecurity obligations that extend throughout the lifespan of an FDA-cleared device, guided by FDA's 2016 Postmarket Management of Cybersecurity guidance. For example, Section 524B(b) of the FD&C Act requires sponsors of submissions for “cyber devices” to have a post-market vulnerability plan and to make updates and patches available on a reasonably justified regular cycle for known unacceptable vulnerabilities, and as soon as possible out of cycle for critical vulnerabilities that could cause uncontrolled risks. Additionally, FDA does not intend to enforce reporting requirements in 21 CFR Part 806 for specific vulnerabilities with uncontrolled risk if the manufacturer (1) communicates with customers and the user community within 30 days of learning of the vulnerability, identifies interim compensating controls and develops a remediation plan, (2) fixes the vulnerability, validates the change and distributes the deployable fix within 60 days of learning of the vulnerability to bring residual risk to an acceptable level, (3) has no known serious adverse events or deaths associated with the vulnerability and (4) actively participates in an ISAO that shares medical device vulnerabilities and threats, providing it with customer communications when customers are notified.

Summary

• FDA clearance marks the beginning, not the end, of cybersecurity responsibilities
• Manufacturers should monitor cybersecurity vulnerabilities continuously from multiple sources (including results from SBOM analysis, penetration testing, coordinated vulnerability disclosure, and other activities). We recommend covering six sources.
• Each vulnerability should be classified as either controlled or uncontrolled risk. For those classified as uncontrolled risk, the 30-day customer communication and 60-day validated fix are conditions for enforcement discretion on Part 806 reporting, not standalone deadlines.
• Active participation in an ISAO is one of those four conditions, alongside no known serious adverse events or deaths associated with the vulnerability.
• Legacy devices need planning for end-of-support transitions
• A structured vulnerability management process protects patients and reduces regulatory risk

Introduction: the post-market reality check

Your medical device just received FDA clearance. The champagne bottles are empty, the team is celebrating, and you're ready to move on to the next project. But here's the reality check: your cybersecurity responsibilities have just begun.

New vulnerabilities are discovered in the software or hardware components you used when creating the device. Attackers develop new methods. Healthcare networks and devices evolve and interconnect. Your device is frozen in time when it’s released. How do you keep it safe as the environment changes around it?

The FDA expects you to have a proactive cybersecurity program in place for the entire product lifecycle. Its 2016 Postmarket Management of Cybersecurity guidance document recommends such a program. Separately, Section 524B(b)(1) of the FD&C Act requires sponsors of submissions for cyber devices to submit a plan to identify, monitor, and address post-market discovered vulnerabilities. In short, you have ongoing regulatory obligations and responsibilities to patients.

What are your post-market cybersecurity obligations?

The guidance recommends the elements of a post-market cybersecurity program be consistent with the five NIST Cybersecurity Framework (CSF) core functions it cites: Identify, Protect, Detect, Respond, and Recover (the CSF 2.0 guide published in 2024 adds Govern as a sixth core function). The requirements in the quality management system regulation (QMSR), 21 CFR Part 820 address these responsibilities, including corrective action (under ISO 13485:2016, incorporated as part of the QMSR, in Clause 8.5.2) to address post-market discovered issues. Note: ISO 13485:2016 became effective as part of the QMSR on February 2, 2026.

Learn more about FDA's overall cybersecurity device requirements in our guide on FDA cybersecurity requirements for medical devices.

Post-market cybersecurity steps include:

• Monitoring: Vigilantly monitor for cybersecurity vulnerabilities from multiple sources, both internal and external. Also include monitoring your software bill of materials (SBOM) and all third-party components, as noted in AAMI TIR97:2019 (R2023).
• Resolve: Quickly resolve identified vulnerabilities that present an uncontrolled risk to patient safety. As outlined in FDA guidance from 2016, remediation should occur as quickly as possible. Communicating with customers within 30 days and distributing a validated fix within 60 days are two of the four conditions for enforcement discretion on Part 806 reporting. Your patch management and security update protocol should enable you to meet these timelines.
• Collaborate: Effectively collaborate with healthcare delivery organizations (HDOs), other IT solution providers, and security investigators. Establish clear communication pathways and delineate responsibilities.
• Document: Rigorously document all risk determinations, vulnerability assessments, and remedial actions. For PMA devices with periodic reporting requirements under 21 CFR 814.84, incorporate information about vulnerabilities, device changes and compensating controls into annual reports.

The six sources of vulnerability discovery

AAMI TIR97:2019 (R2023) outlines recommended practices for managing post-market cybersecurity. This includes monitoring guidance on developing and maintaining a vulnerability management program to discover, assess, and resolve vulnerabilities. The six sources below are our framework, not an FDA-mandated list. The six sources of vulnerability discovery we recommend monitoring are detailed in the book chapter on building a vulnerability monitoring program, which provides recommended processes for managing each source.

Proactive internal sources

1. SBOM reviews: Conduct regular reviews of the software bill of materials; which includes all of a device's software components, for known vulnerable versions based on the standard vulnerability sources such as the NIST National Vulnerability Database (NVD) and CISA's Known Exploited Vulnerabilities Catalog. Note: ANSI/AAMI SW96:2023 treats this as a post-production activity, whereas the SBOM creation itself is a part of the secure software development lifecycle (SDLC) done during the device development.
2. Penetration testing/fuzzing: Conduct independent security testing, such as scheduled penetration testing or application fuzzing, to uncover vulnerabilities that were missed during the development. The new FDA premarket guidance for medical device cybersecurity (dated February 2026) states that post-market testing should be done at a frequency commensurate with the risk posed, for example annually. For information about how to conduct effective medical device pentesting, check out our blog post.
3. Internal Detection - Include in Quality System: Flag unusual device activity that can indicate cyber-attacks. Unusual device activity can include performance issues, device communicating on an unusual network/protocol/port, application/system log activity, unexpected configuration changes etc. Conduct regular security code reviews during development and enough resources devoted to post-market monitoring to identify potentially exploitable vulnerabilities before they're exploited in the wild.

External sources

4. Participate in a ISAO: Being part of a Information Sharing and Analysis Organization (ISAO) can alert device manufacturers earlier about potential threats that can impact medical devices. Participation in ISAOs is encouraged by the FDA guidance. Health-ISAC (Information Sharing and Analysis Center) is the primary ISAC for the healthcare sector.
5. Handling of potential security-related complaints: Sometimes healthcare providers will be the first to notice changes in their device behavior. Make sure your internal complaint handling process (see Clause 8.2.2 of ISO13485 under the QMSR) includes steps for forwarding security-related complaints to your cyber security team.
6. Coordination of vulnerability disclosure (CVD): It's very important to provide security researchers with guidance as to how to disclose vulnerabilities they discover in your devices. The disclosure process should be transparent and include details about acknowledgment timelines, information sharing, and others as outlined in ISO/IEC 29147:2018.

Building your vulnerability management process

Your vulnerability management process forms the heart of post-market cybersecurity. We cover the full triage-to-remediation workflow in our book section on vulnerability assessment and response. Let's walk through each step:

Initial triage and assessment

AAMI TIR97 recommends a multidisciplinary approach to the triage and assessment of reported vulnerabilities, and in practice that means clinical, regulatory, and engineering input. Once a report has been received, immediate triage should assess its validity and impact. Key questions to ask about the vulnerability at this stage are:

• Is this a vulnerability in our device or is it falsely reported?
• Which versions of the device are affected?
• Is this vulnerability currently being exploited?
• What is the clinical impact of the vulnerability?

Risk evaluation methodology

Not every vulnerability will require immediate action. A risk assessment should be conducted prior to the initiation of remediations. Key aspects to assess when considering vulnerability risk for a medical device include the following:

• Exploitability: How easy would it be for an adversary to exploit the vulnerability? This includes assessment of the following: the level of access required, the technical skill needed and any exploit tools that exist to automate the attack. The FDA Guidance published in 2016 recommends consideration of using the Common Vulnerability Scoring System (CVSS) version 3.0. Regarding medical device specific vulnerability assessments, using CVSS scores with the MITRE rubric provides a standardized approach.
• Severity: In the worst case scenario, what is the impact of the vulnerability? Is there an impact to safety or essential performance?
• Mitigations: Risks can be mitigated. Are there (or can there be) additional controls put in place to reduce the risk? Your security architecture should incorporate defense-in-depth, and you should consider existing controls and additional compensating controls healthcare providers can implement in your risk analysis.

The FDA distinguishes between controlled and uncontrolled risks, with the latter defined as an unacceptable residual risk of patient harm given the mitigating controls in place. Planned controls do not reduce residual risk until implemented. The 30- and 60-day conditions discussed below run from learning of the vulnerability, not from completing the risk assessment. The guidance recommends a binary decision regarding risk (controlled vs. uncontrolled) for every vulnerability.

Documentation requirements

Every vulnerability assessment needs thorough documentation including:

• Discovery source and date
• Affected products and versions
• Risk assessment rationale
• Decision justification
• Remediation timeline
• Customer communications

This documentation supports regulatory submissions and demonstrates your quality system's effectiveness.

The critical decision points

Three decision points determine your response path:

Decision 1: is this a new vulnerability?

This may seem like common sense, but duplicate reports are all too common. Check your vulnerability database before proceeding. If a report on this vulnerability is already open, link the new report to the old one.

Decision 2: is it in an external component?

A vulnerability in a third-party component may require the vendor's involvement to fix, but you are still responsible for the risk it poses to your device. The discovery of this type of vulnerability triggers your coordinated vulnerability disclosure process with the external vendor.

Decision 3: is the risk acceptable?

When you have identified a vulnerability, you need to assess the risk to patients and users and decide what action to take.

This is where your risk assessment pays off. Acceptable risks might receive fixes in the next scheduled update. Unacceptable risks need immediate action.

Remember: "acceptable" doesn't mean "ignorable." Document your rationale and implement any available mitigations.

Creating your response playbook

Having a clear playbook prevents panic and ensures consistent response.

External component vulnerabilities

• Notify the component vendor through their CVD process
• Assess alternate mitigations while awaiting vendor response
• Prepare customer communications explaining the issue and interim measures
• Plan for component updates including validation and deployment

Patch development and deployment

For vulnerabilities in your code:

• Develop the fix following your design and development controls (see ISO 13485 Clause 7.3 under the QMSR)
• Validate thoroughly. Rushed patches can introduce new vulnerabilities.
• Determine the regulatory pathway. Does this need a new 510(k) or PMA supplement? See the latest FDA cybersecurity guidance update for current expectations.
• Deploy efficiently using your established update mechanisms. Consider implementing secure software updates and remote update capabilities as cybersecurity requirement. For validation and regulatory pathway decisions, see our book section on developing and deploying patches.

Communication protocols

For an uncontrolled risk, Section VII.B of FDA's 2016 guidance sets out what it expects to see if you want enforcement discretion on Part 806 reporting:

As soon as possible, and no later than 30 days after learning of the vulnerability:

• Describe the vulnerability and your current impact assessment
• Identify interim compensating controls, if any
• State that work is under way to address the risk and that you will communicate when a fix becomes available
• Develop a remediation plan to bring residual risk to an acceptable level and document the timeline rationale

As soon as possible, and no later than 60 days after learning of the vulnerability:

• Fix the vulnerability and validate the change
• Distribute the deployable fix to customers and the user community to bring residual risk to an acceptable level
• Follow up with end users as needed beyond the 60-day period
• Where the correction is a recall, document effectiveness checks consistent with 21 CFR 7.42

In some circumstances, a compensating control can provide a long-term solution if it brings the risk of patient harm to an acceptable level. Controls should not introduce more risk to device safety and essential performance than the original vulnerability.

The goal is clear, timely communication to maintain trust and enable healthcare providers to protect patients.

Coordination

Post-market cybersecurity is a team sport.

Post-market cybersecurity cannot be left to one team. The following groups can contribute:

• Quality, regulatory, engineering, clinical, and other internal teams
• Device component vendors
• Cybersecurity researchers and others who discover weaknesses in your device
• Customers, including healthcare delivery organizations (HDOs), home users, and service providers
• Regulatory bodies and cyber incident information sharing organizations (ISAOs), at home and abroad, including the FDA

What happens when a device becomes legacy?

When a device becomes legacy, patient safety responsibilities continue.

AAMI TIR97:2019(R2023) defines key moments in a device lifecycle:

• End of Life (EOL): The device is no longer sold, but support continues.
• End of Guaranteed Support (EOGS): The device will not receive guaranteed full support.
• End of Support (EOS): The device will no longer receive any support.

Early communication

Patients and healthcare providers must be prepared for these moments. TIR97 recommends early communication with customers (at least 18 months before EOGS and EOS take effect) so that they can plan for replacements or accept the risks transferred with continued use.

Risk transfer documentation

The outgoing support team should clearly document the transfer of responsibilities. Include as much information as possible so that customers can make informed decisions about continued use. Suggested topics include:

• Remaining risks and known vulnerabilities
• Customer responsibilities, including patient and provider responsibilities
• Device decommissioning recommendations and procedures
• Data sanitization requirements

Component obsolescence

Support teams should be aware that third-party components may become obsolete before the device does. To mitigate this risk:

• Consider supporting critical components internally
• Redesign the platform to minimize dependencies in future versions of the device
• Clearly communicate any reduced capabilities

The ISAO advantage: enforcement discretion on Part 806 reporting

Below are conditions for communicating and addressing vulnerabilities in a timely fashion, without waiting for a safety event.

FDA's 2016 guidance says it does not intend to enforce Part 806 reporting requirements for specific vulnerabilities with uncontrolled risks, so long as all of the following are true:

• No known deaths or serious adverse events associated with the vulnerability
• Customers and the user community notified about the vulnerability as soon as possible, and no later than 30 days after learning of it, with interim compensating controls identified and a remediation plan developed
• A solution for the vulnerability is fixed, validated and distributed to customers and the user community as soon as possible, and no later than 60 days after learning of it, bringing residual risk to an acceptable level
• Active participation in an ISAO that shares vulnerabilities and threats affecting medical devices, with customer communications provided to the ISAO when customers are notified

Participation alone in an ISAO is not enough to qualify for this enforcement discretion. Active participation is the fourth condition above.

Four criteria for active participation

Section IX of the guidance describes four criteria FDA intends to consider when assessing active participation:

• Membership: Documented participation as a member of an ISAO that shares vulnerabilities and threats to medical devices
• Documented ISAO operations: Participant agreements (which may include NDAs with other members), business processes and operating procedures, and descriptions of privacy safeguards implemented
• Information sharing: Evidence of information sharing with the ISAO, including communications to customers about vulnerabilities
• Documented response processes: A documented response plan to show how information from the ISAO is assessed and used to understand the vulnerability and determine actions to address it, traceable to risk assessments, countermeasure solutions and risk mitigations

When assessing information from the ISAO, you can consider its source, reliability, completeness and timeliness.

FDA recommends maintaining objective evidence that you meet all four criteria. For cyber devices specifically, see our guide on what information FDA requires for cyber devices.

Benefits beyond compliance

Participating in an ISAO can provide advantages beyond compliance with FDA guidance. By joining an ISAO, you may have early access to threat information before it’s publicly released, engage with peers on similar vulnerabilities, and participate in a collaborative response to industry-wide challenges. Your engagement in an ISAO can also reduce duplicate effort from manufacturers to investigate or mitigate vulnerabilities.

Documentation to keep

Maintain documentation to demonstrate your interaction with an ISAO including:

• Membership agreements, renewals and supporting documentation
• Information shared with ISAO
• ISAO alert response including actions taken as a result
• Documentation of processes that incorporate information from the ISAO to mitigate vulnerabilities

Practical implementation tips

Tips to help you develop a post-market cybersecurity program:

Staffing considerations

It’s recommended to have dedicated resources available for post-market cybersecurity activities including:

• Security monitoring analyst
• Vulnerability assessment engineer
• Clinical risk assessor
• Regulatory compliance coordinator

Smaller manufacturers may combine roles but make sure you have sufficient coverage.

Monitoring infrastructure

Some recommended resources for monitoring activities:

• SBOM scanning capabilities (including automation) and an approach to compare SBOMs to vulnerability sources
• Customer facing portal for security information
• Incident management tracking system that leverages the quality system
• Secure researcher communication channel

Additionally, you should consider creating data flow diagrams for medical devices and architecture security views for medical devices to help illustrate your monitoring activities. Manufacturers of cloud-connected devices should include threat modeling for cloud-connected medical devices to identify relevant threats and inform monitoring activities.

The following sections will elaborate on your post-market cyber security program in order to help you incorporate it into your existing quality processes.

Tool selection

Consideration should be given to the tools used in your cyber security program. Essential tools include:

• Vulnerability scanners for your tech stack
• Pen test frameworks
• Risk assessment templates
• Communication management system

QMS integration

Your post-market cyber security program must be integrated with applicable QMS processes under the QMSR requirement (including ISO 13485:2016):

• Complaint handling (ISO 13485 Clause 8.2.2)
• CAPA system (Clause 8.5.2 and 8.5.3)
• Design change control (Clause 7.3.9)
• Management review (Clause 5.6)

Understanding how to implement cybersecurity controls within your QMS supports compliance. Additional guidance for software-based medical devices can be found in the discussion regarding the SPDF vs. IEC 62304 framework.

Measuring success

The following are examples of metrics that can be used to demonstrate the effectiveness of your cyber security program:

• Response metrics: % of uncontrolled risks meeting the 30-day communication and 60-day validated-fix conditions; time from discovery to assessment; % of customers who received communications and communication effectiveness
• Quality metrics: % of patches that result in a defect; % successful deployments; % of vulnerabilities that are reoccurring
• Program metrics: % accurate/comprehensive SBOM; % of employees who completed cyber security training; ISAO participation levels

Relevant vulnerability and remediation information should be included in your annual PMA report where required. These metrics can support that information and be used as input for your management review process.

Conclusion: continuous security

Post-market cybersecurity is an increasingly important factor in purchasing decisions for healthcare providers, and is both a competitive advantage and regulatory obligation for medical device manufacturers. While the threats will continue to evolve, manufacturers can prepare for changing threats with a defined and executed vulnerability management process, continuous monitoring and partnerships with external entities. Take steps now to prepare for the future of your device's security: assess your current capabilities, identify gaps, build your team (including external partners) and join an ISAO. Develop a mindset shift from thinking about security "up to launch" to embracing security "throughout the device's lifecycle." For cyber devices, Section 524B requires a post-market vulnerability plan and updates and patches. Your patients count on it. Your customers count on it. Healthcare providers are counting on it. And before you know it, the celebration over your FDA clearance will have long passed, but the work of maintaining post-market cybersecurity will continue. Don't let post-market planning be one of the 5 cybersecurity reasons FDA will refuse your 510(k) for your next submission.

Contact us today at info@cybermed.ai to learn more about post-market cybersecurity management or our cybersecurity documentation.

Sources

• 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
• 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
• 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
• NIST. Cybersecurity Framework. https://www.nist.gov/cyberframework
• Health-ISAC. https://h-isac.org/
• 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. https://webstore.ansi.org/standards/aami/aamitir972019
• ISO/IEC 29147:2018. Information technology, Security techniques, Vulnerability disclosure. https://www.iso.org/standard/72311.html
• CISA. Coordinated Vulnerability Disclosure (CVD) Program. https://www.cisa.gov/resources-tools/programs/coordinated-vulnerability-disclosure-cvd-program
• NEMA/MITA. HN 1-2019, Manufacturer Disclosure Statement for Medical Device Security (MDS2). Available from NEMA.
• MITRE. Rubric for Applying CVSS to Medical Devices. October 2020. https://www.mitre.org/news-insights/publication/rubric-applying-cvss-medical-devices
• FIRST. CVSS Calculator. https://www.first.org/cvss/calculator/3.1