FDA Deficiency: Inadequate Post-Market Cybersecurity Plan

What FDA reviewer language looks like

Paraphrased patterns from real deficiency letters. Not verbatim FDA quotes.

• Pattern 1

  The post-market cybersecurity plan does not describe the activities by which the manufacturer will monitor for new vulnerabilities affecting the device after release. Provide a description of monitoring sources and frequencies.

• Pattern 2

  The plan does not describe the manufacturer's process for communicating cybersecurity vulnerabilities and patches to customers and to the FDA. Provide a documented communications process, including triggers and timelines.

• Pattern 3

  The plan does not address end-of-support. Provide a description of how customers will be notified of end-of-support and what cybersecurity considerations will be communicated regarding continued use of the device.

Why this happens

• Post-market plans reuse boilerplate from prior submissions without device-specific monitoring sources or SLAs.
• Communications processes are described in marketing terms ('we will notify customers') without trigger conditions or timelines.
• End-of-support is treated as a commercial decision and never enters the cybersecurity package.
• The post-market plan does not reference the SBOM, so reviewers cannot tell what is actually being monitored.

How to fix it

• List monitoring sources: NVD, vendor advisories, CISA ICS-CERT, MDCC, internal pen tests, customer reports. Specify frequency.
• Tie monitoring to the SBOM: changes in component CVE status trigger triage; cite the timeline.
• Define communication triggers (severity threshold, exploitability threshold) and channels (customer portal, field safety notice, FDA reporting per CFR 806).
• Address end-of-support: notification lead time, residual risk communication, options for unsupported devices, and what happens to cloud back-end services.

Monitoring without sources is not monitoring

Reviewers will accept a short post-market plan, but they will not accept one that asserts monitoring without naming sources. A defensible plan lists the specific intelligence feeds — NVD for SBOM components, vendor advisory mailing lists for the third-party libraries you use, CISA ICS-CERT for ICS/medical advisories, MDCC and ISAOs for sector-specific intelligence, the company's own coordinated vulnerability disclosure inbox — and pairs each with a review cadence. This level of specificity is rarely volunteered, but it converts an 'inadequate' verdict into 'acceptable' faster than any other change.

End-of-support is the new frontier

Historically, end-of-support was a commercial topic. Under the current guidance, it is a cybersecurity topic, and the absence of an end-of-support plan is increasingly being called out as a deficiency on its own. The plan should describe how customers will be notified, how far in advance, what the residual cybersecurity risk picture looks like for unsupported devices, what mitigations are recommended for customers who continue to use the device past end-of-support, and what happens to any cloud-side services the device depends on. Even a short, honest section on end-of-support closes a door that reviewers are now actively probing.

Patch deployment is where the plan most often fails verification

Reviewers increasingly probe the mechanism by which security patches actually reach fielded devices. A plan that says 'patches will be delivered through software updates' without describing the chain — how a fix is built, signed, staged, distributed (over-the-air, via service technician, via customer-initiated install), verified on-device, rolled back if it fails, and confirmed installed across the fleet — invites the same deficiency every time. The post-market plan should reference the updateability architecture view, name the update channel, name the integrity and authenticity controls, and commit to a fleet-visibility mechanism so the manufacturer can answer the question 'what percentage of fielded devices are running a patched version?' Without that mechanism, the manufacturer cannot meet its post-market reporting obligations regardless of how good the plan reads.

Standards involved

• FDA 2026FDA Premarket Cybersecurity Guidance (Feb 3, 2026)
• SPDFSecure Product Development Framework
• IEC 81001-5-1IEC 81001-5-1:2021 - Health Software and Health IT Systems Safety, Effectiveness and Security
• Section 524BSection 524B of the FD&C Act

Already responding to this deficiency?

Our deficiency response engagement rebuilds the underlying artifact and produces a reviewer-ready response narrative.