Article
Postmarket Vulnerability Management for Connected Medical Devices
Key takeaways
- Postmarket cybersecurity is reviewed as part of the premarket submission, but it lives or dies on operational discipline after clearance.
- Vulnerability triage for medical devices is not CVSS; it is exploitability in the device's deployed environment times patient-safety impact.
- A coordinated vulnerability disclosure (CVD) program is now table stakes; researchers will find you whether you publish a policy or not.
- Patch timelines must be defensible and tied to safety classification, not to whichever release train is convenient.
- Every triage decision (patch, mitigate, accept, retire) has to be logged against the device, not lost in an engineer's inbox.
Why this matters
The 2023 update to Section 524B of the FD&C Act made postmarket cybersecurity a regulatory deliverable, not an aspiration. FDA reviews the postmarket plan as part of the premarket package and expects the manufacturer to execute it for the life of the product. In parallel, CISA and ICS-CERT have become active participants in medical device vulnerability coordination, and researchers are publishing findings at a pace that did not exist five years ago.
The manufacturers who handle this well treat postmarket cybersecurity as a clinical-quality process: defined inputs, defined timelines, defined evidence. The ones who treat it as IT operations get caught between safety expectations they cannot meet and disclosure timelines they cannot honor. After running this program across hundreds of MedTech clients at Blue Goat Cyber, the difference is almost always organizational, not technical.
What does a postmarket cybersecurity program actually have to do?
At minimum: continuously monitor for vulnerabilities affecting the device or any component in its SBOM, triage findings against device-specific exploitability and patient-safety impact, run a coordinated vulnerability disclosure channel for external researchers, deliver validated patches to fielded devices within committed timeframes, and notify users and regulators when an event affects safety or effectiveness.
FDA's postmarket cybersecurity guidance defines the regulatory floor. The operational reality is that each of those obligations decomposes into ten or twenty subprocesses, owners, and SLAs that someone in the organization has to actually own.
Where do new vulnerability findings come from?
Four sources, all of which need a subscription and a triage owner: (1) automated scans of your SBOM against the NVD and the CISA Known Exploited Vulnerabilities Catalog; (2) supplier advisories from chipset, OS, and third-party SDK vendors; (3) external researcher reports through your CVD channel; (4) internal findings from ongoing security testing, fuzzing, and red-team work.
The pipeline has to deduplicate across these sources, because the same CVE will arrive three different ways and none of them will agree on severity. Build one canonical ticket per finding, with all source references attached.
How do you triage a vulnerability when CVSS is misleading?
CVSS is built for general IT and almost always misrepresents medical device risk. A 9.8 in a library you do not even invoke is a 0; a 5.5 in a wireless authentication path is potentially life-threatening. Triage on two axes: device-specific exploitability (is the vulnerable code path reachable in this product's deployed configuration?) and patient-safety impact (what is the worst plausible clinical outcome if exploited?).
AAMI TIR57 provides the structured language for this. Document the triage rationale in the device's risk file, not in a security tracker that nobody from regulatory will ever read. When FDA or a notified body asks why you classified a finding the way you did, the answer has to be in the file they audit.
How fast do you actually have to patch?
There is no single FDA-defined SLA, which is exactly why your postmarket plan has to commit to one. A defensible structure ties patch timelines to triage severity: critical safety impact ships an emergency update or compensating control within days, high impact within a defined number of weeks, medium within the next planned release, low at the next major release or accepted with rationale.
Whatever numbers you commit to in the postmarket plan, you will be held to. Pick numbers your release engineering can actually hit on a bad week, not numbers that look good in a slide.
What does a coordinated vulnerability disclosure program look like?
A published security.txt on every product domain, a clear intake address, a stated acknowledgment window (24 to 72 hours), a stated initial-response window (typically 7 to 14 days), and a public disclosure policy aligned with ISO/IEC 29147 and 30111. FIRST and the CISA Coordinated Vulnerability Disclosure process are good templates.
Legal teams will want to add language threatening researchers; do not let them. Hostile CVD policies do not stop research, they just guarantee the researcher's first contact will be a tweet instead of an email.
How do you push a patch to a fielded device safely?
Signed firmware, authenticated update channel, staged rollout with telemetry, automatic rollback on failure, and a tested fallback path for devices that lose connectivity mid-update. The update mechanism itself is part of the threat model and part of the verification evidence; an update path that is exploitable is worse than no update path at all.
For clinical devices, the patch process also has to respect clinical workflow. An update that bricks a device mid-procedure is a patient-safety event regardless of the cybersecurity benefit. Communicate timing, give clinicians a defer mechanism inside safety bounds, and design the update to survive partial failure.
How Christian approaches this
At Blue Goat Cyber we treat postmarket cybersecurity as a Total Product Lifecycle discipline that has to be wired in before clearance. The SBOM, the threat model, the postmarket plan, and the CVD program reference each other and share owners. When a new CVE drops, the triage path is already mapped to a clinical risk owner, a regulatory owner, and an engineering owner; nobody has to figure out who handles it on the day it matters.
This is the playbook in my 2026 book, Medical Device Cybersecurity: An In-Depth Guide (see the chapter overview). The postmarket chapter exists because almost every program I have audited in the last decade had a strong premarket package and a postmarket plan that nobody had operated.
Related guides: SBOM hygiene for medical devices, Threat modeling connected medical devices, and What the FDA actually wants in a 2026 premarket submission.