Postmarket Cybersecurity Monitoring Guide for MedTech

Premarket cybersecurity work gets a submission cleared. Postmarket cybersecurity monitoring is what keeps the device legally marketable for the rest of its life. The FDA treats the two as a single continuum under the Secure Product Development Framework (SPDF), and the February 3, 2026 premarket cybersecurity guidance is explicit that the postmarket plan submitted at clearance has to actually run, not just exist as a document. This guide covers what that program needs to contain and how to operate it day to day.

The statutory obligation: Section 524B(b)(1)

Section 524B of the Food, Drug, and Cosmetic Act, added by the Consolidated Appropriations Act of 2023, requires that a sponsor of a "cyber device" (any device that includes software, connects to the internet, and has the technical characteristics that could make it vulnerable to cybersecurity threats):

• Submit a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures, in a reasonably justified time.
• Design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure, and make available postmarket updates and patches on a reasonably justified regular cycle, and out of cycle in the case of a critical vulnerability that could cause uncontrolled risk.
• Provide the FDA with a software bill of materials, including commercial, open source, and off-the-shelf components.

This is not guidance language subject to interpretation debate; it is statute. The FDA can refuse to accept a submission that lacks this plan (Refuse to Accept, or RTA), and postmarket, the agency treats a program that exists on paper but does not run as a quality system failure, not merely a documentation gap. If you have not yet built the premarket submission around this, see Section 524B Cybersecurity Requirements Explained.

What a program actually needs to contain

A postmarket monitoring program that will survive an FDA inspection or a for-cause audit needs five working components, each with owned procedures and objective evidence:

1. Continuous vulnerability surveillance against your SBOM.
2. Coordinated vulnerability disclosure (CVD) intake for externally reported issues.
3. Vulnerability triage that weights patient safety, not just technical severity.
4. A patch and update cadence, both routine and emergency.
5. A Part 806 reporting decision process that documents whether each fix is a correction requiring notification.

Each is detailed below.

Monitoring cadence and sources

"Monitor" under 524B(b)(1) means an active, scheduled process, not an annual literature review. A defensible cadence looks like this:

The SBOM is the backbone of automated surveillance. If your component identifiers are ambiguous or missing, as covered in SBOM Vulnerability Management for Medical Devices, the daily CVE match will silently miss hits. Manufacturers we work with typically run automated matching daily and route anything above an internal severity floor to a human triage review within one business day.

Coordinated vulnerability disclosure (CVD) intake

The FDA expects a CVD process modeled on ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling), and a published, working intake channel. Minimum elements:

• A published security.txt file or dedicated reporting page, with a named or role-based contact.
• An acknowledgment SLA to the reporter, commonly 24 to 72 hours.
• A defined handling workflow from intake through validation, triage, remediation, and reporter notification of disposition.
• A safe-harbor or good-faith research statement, so external researchers are not deterred from reporting.
• A record of every report received, including ones triaged as non-issues, so the FDA can see the intake channel is actually active if questioned.

Manufacturers that lack a functioning CVD channel are increasingly a point of scrutiny in deficiency letters, because the FDA views a "planned but not implemented" disclosure process as a 524B(b)(1) gap. For the full workflow, see Coordinated Vulnerability Disclosure for Medical Devices and Medical Device VDP/CVD Workflows.

Vulnerability triage with safety weighting

A CVSS base score alone is the wrong triage input for a medical device, because CVSS does not know that the affected component controls an infusion rate or a diagnostic reading. A safety-weighted triage model layers clinical impact on top of technical severity:

The output should be a single documented risk rating per vulnerability, tied to a remediation timeline, and traceable back to the device's existing ISO 14971 risk management file and, where applicable, its IEC 81001-5-1 security risk assessment. See Security Risk Assessment and IEC 81001-5-1 for how that mapping should look, and ISO 14971 vs. AAMI TIR57 for how safety and security risk methodologies intersect.

A common failure mode: teams triage purely on CVSS and end up either patching low-relevance library CVEs on an emergency timeline while a genuinely reachable, high-harm finding sits in a routine backlog, or the reverse, deprioritizing a high-CVSS finding because it is unreachable without documenting why. Document the reachability determination every time; an undocumented "not exploitable in our configuration" claim does not hold up under review.

Patch and update cadence

Section 524B(b)(1) requires updates "on a reasonably justified regular cycle," and out-of-cycle releases for critical vulnerabilities presenting uncontrolled risk. In practice, manufacturers should define and document, in advance, at least two tracks:

• Routine cadence. A stated interval, commonly quarterly for firmware/software updates bundling lower-severity fixes, aligned to your verification and validation capacity. The cadence should be justified against device risk class and field update mechanism (over-the-air versus depot service).
• Emergency/out-of-cycle cadence. A defined trigger (e.g., a critical, actively exploited, or high safety-severity finding) and a target time to patch, frequently 30 to 90 days depending on severity and the availability of compensating controls, with interim mitigations (advisories, configuration guidance) issued immediately while the fix is developed.

Both tracks need documented verification and regression testing proportional to risk before release, consistent with your existing IEC 62304 change control process, and a field deployment mechanism that can confirm patch uptake, since a patch that is published but not installed on fielded devices does not close the risk.

Part 806 reporting decision points

21 CFR Part 806 requires manufacturers to report certain device corrections and removals to the FDA within 10 working days. The question every patch raises is whether it is a reportable correction. The decision generally turns on:

• Does the fix address a risk to health? If the vulnerability being patched could cause or contribute to a death or serious injury, or if the device previously distributed could cause such harm, correction reporting is likely required.
• Is the correction being made to reduce a risk to health, or a violation that could present a risk to health? This is the Part 806 trigger, distinct from routine quality improvements.
• Exemption for routine servicing and stock recoveries. Cybersecurity patches distributed as part of a documented, previously disclosed routine update cycle, that do not themselves indicate a previously unknown risk to health, can sometimes fall under the routine update exemption, but this determination has to be made and documented for each release, not assumed.
• Cadence with recall procedures. If a correction is reportable, it typically also triggers your recall/correction procedures under 21 CFR Part 7 and 806 concurrently, including customer notification content.

The safest practice is to run every patch through a documented Part 806 assessment, even when the answer is "not reportable," so there is a contemporaneous record of the analysis rather than a retrospective justification built after an inspection asks for it.

Metrics reviewers and auditors expect

A monitoring program is judged on whether it demonstrably operates, and metrics are the evidence of that. Track, at minimum:

These metrics should be reviewed at a defined interval (commonly monthly for engineering, quarterly for management review) and feed your CAPA and management review processes under your quality system, since postmarket cybersecurity is not a security-team-only activity; it is a QMS process with security-specific inputs.

How Blue Goat Cyber approaches postmarket cybersecurity monitoring

We build postmarket monitoring programs to run, not to read well in a submission. That starts with wiring SBOM generation and CVE matching into your actual release pipeline so surveillance does not depend on someone remembering to check a feed, and it extends through a CVD intake process your security and regulatory teams can actually staff. We calibrate triage against your existing ISO 14971 harm severity scale so a security finding and a safety finding speak the same language, and we help set patch cadences that your verification capacity can sustain rather than ones that look good on paper and slip in year two. Every program we build includes a documented Part 806 decision workflow and a metrics dashboard your quality team can produce on request during an inspection. Ongoing execution is available through FDA Postmarket Cybersecurity Services and Postmarket SBOM & VEX Monitoring; if you are building the program from scratch alongside a submission, see FDA Premarket Cybersecurity Services.

Where this fits in the cluster

• Coordinated Vulnerability Disclosure for Medical Devices
• Medical Device VDP/CVD Workflows
• SBOM Vulnerability Management for Medical Devices
• Postmarket Cybersecurity Readiness Plan
• Section 524B Cybersecurity Requirements Explained
• HHS HPH CPGs for Medical Device Manufacturers - hospital procurement expectations your program must answer.
• Legacy Medical Device Cybersecurity - managing fielded devices you can no longer patch quickly.

FAQ

What does the FDA require in a postmarket cybersecurity monitoring plan?

Section 524B(b)(1) requires a plan to monitor, identify, and address postmarket vulnerabilities, including a coordinated vulnerability disclosure process, and a commitment to make patches and updates available on a reasonably justified regular cycle, with out-of-cycle updates for critical vulnerabilities presenting uncontrolled risk. The plan has to be operable after clearance, not just described at submission.

How often should we scan for new vulnerabilities against our SBOM?

Daily automated matching against CVE feeds is the practical standard for actively marketed cyber devices, with vendor bulletins reviewed at least weekly. Less frequent scanning creates a gap between public disclosure and your triage response that a reviewer or auditor can reasonably characterize as inadequate monitoring under 524B(b)(1).

Does every patch need a Part 806 correction report?

No. Patches distributed under a documented, previously disclosed routine update cycle that do not address a risk to health can often qualify for the routine servicing exemption. But every patch should go through a documented Part 806 assessment so the "not reportable" determination is contemporaneous and defensible, not reconstructed after the fact.

How should we weight CVSS score against patient safety in triage?

CVSS captures technical exploitability; it does not know what the affected component does clinically. Layer reachability, exposure, and a harm-severity rating consistent with your ISO 14971 risk file on top of the CVSS score to produce a single device-specific risk rating, and document the reachability and clinical-impact rationale for every finding, especially when it changes the outcome from what CVSS alone would suggest.

What metrics should we be ready to show an FDA inspector?

Mean time to triage, mean time to patch by severity tier, CVD acknowledgment and resolution time, SBOM staleness, the percentage of fielded devices on current patch level, and the count and disposition of Part 806 assessments performed. These metrics demonstrate the program described in your submission is the program actually running.

Sources & primary references

• Section 524B of the Federal Food, Drug, and Cosmetic Act
• Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (FDA, February 3, 2026 final guidance)
• 21 CFR Part 806, Medical Devices; Reports of Corrections and Removals
• ISO/IEC 29147:2018, Vulnerability Disclosure
• ISO/IEC 30111:2019, Vulnerability Handling Processes
• ANSI/AAMI SW96:2023, Medical Device Security Risk Management
• ISO 14971:2019, Application of Risk Management to Medical Devices