Post-market cybersecurity is now graded as rigorously as premarket. An 'inadequate post-market cybersecurity plan' deficiency is written when the plan does not commit to specific monitoring activities, does not describe how patches will be delivered and verified at customer sites, does not describe how customers and the FDA will be informed of cybersecurity issues, or does not address what happens to fielded devices when the product reaches end-of-support.
Paraphrased patterns from real deficiency letters. Not verbatim FDA quotes.
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.
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.
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.
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.
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.
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.
Already responding to this deficiency?
Our deficiency response engagement rebuilds the underlying artifact and produces a reviewer-ready response narrative.
FDA Cybersecurity Deficiency Response serviceBring us the letter. We will map a clean response and rebuild the underlying artifact to FDA 2026 expectations.
