--- title: "Postmarket Vulnerability Management for Connected Medical…" description: "A workable postmarket cybersecurity program for connected medical devices: monitoring, triage, coordinated disclosure, patching, and the regulator-facing…" lang: en json-ld: | [ { "@context": "https://schema.org", "@type": "Person", "@id": "https://christianespinosa.com/#person", "name": "Christian Espinosa", "url": "https://christianespinosa.com/", "image": "https://christianespinosa.com/__l5e/assets-v1/de07e44b-a8e0-4bcc-bcb0-13aec15421f1/headshot-front.jpg", "sameAs": [ "https://www.facebook.com/christian.espinosa.official", "https://x.com/Ironracer", "https://www.instagram.com/christian.espinosa.official/", "https://www.youtube.com/@ChristianEspinosaOfficial", "https://www.linkedin.com/in/christianespinosa/" ], "jobTitle": "Bestselling Author, Keynote Speaker, Entrepreneur", "worksFor": { "@type": "Organization", "name": "Blue Goat Cyber", "url": "https://bluegoatcyber.com/" } }, { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://christianespinosa.com/#website", "name": "Christian Espinosa", "url": "https://christianespinosa.com/", "publisher": { "@id": "https://christianespinosa.com/#organization" }, "inLanguage": "en-US" }, { "@context": "https://schema.org", "@type": "Organization", "@id": "https://christianespinosa.com/#organization", "name": "Christian Espinosa", "url": "https://christianespinosa.com/", "logo": { "@type": "ImageObject", "url": "https://christianespinosa.com/logo.svg" }, "founder": { "@id": "https://christianespinosa.com/#person" }, "sameAs": [ "https://www.facebook.com/christian.espinosa.official", "https://x.com/Ironracer", "https://www.instagram.com/christian.espinosa.official/", "https://www.youtube.com/@ChristianEspinosaOfficial", "https://www.linkedin.com/in/christianespinosa/" ] }, { "@context": "https://schema.org", "@type": "Article", "headline": "Postmarket Vulnerability Management for Connected Medical Devices | Christian Espinosa", "description": "A workable postmarket cybersecurity program for connected medical devices: monitoring, triage, coordinated disclosure, patching, and the regulator-facing paper trail that proves it.", "image": "https://christianespinosa.com/assets/og-default-vx4o85jG.jpg", "datePublished": "2026-06-21T13:05:00Z", "dateModified": "2026-06-21T13:05:00Z", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://christianespinosa.com/guides/postmarket-vulnerability-management-for-connected-medical-devices" }, "author": { "@type": "Person", "name": "Christian Espinosa", "url": "https://christianespinosa.com/about" }, "publisher": { "@type": "Organization", "name": "Christian Espinosa", "logo": { "@type": "ImageObject", "url": "https://christianespinosa.com/logo.svg" } } }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Do I need a CVD program if my device is not internet-connected?", "acceptedAnswer": { "@type": "Answer", "text": "Yes. Researchers find vulnerabilities in airgapped devices, supply-chain components, and companion software regardless of network exposure. A CVD channel is how those findings reach you legitimately instead of through a conference talk." } }, { "@type": "Question", "name": "What is the minimum monitoring cadence for postmarket vulnerability scanning?", "acceptedAnswer": { "@type": "Answer", "text": "Daily for high-risk surface (network and wireless), weekly for medium, monthly for everything else. The cadence is part of your postmarket plan and reviewers will hold you to it." } }, { "@type": "Question", "name": "Do I have to notify FDA every time I find a vulnerability?", "acceptedAnswer": { "@type": "Answer", "text": "No. Notify when a vulnerability meets the threshold defined in your postmarket plan, generally findings that materially affect safety or effectiveness, or that require a field action. Document the threshold; apply it consistently." } }, { "@type": "Question", "name": "How do I handle a vulnerability in a supplier component I cannot patch?", "acceptedAnswer": { "@type": "Answer", "text": "Apply compensating controls (network isolation, restricted privileges, monitoring), document the residual risk in the device risk file, escalate to the supplier with a timeline, and disclose the limitation to users if it affects their operational risk." } }, { "@type": "Question", "name": "What about end-of-support devices still in clinical use?", "acceptedAnswer": { "@type": "Answer", "text": "End-of-support is a regulatory event, not a marketing one. Publish the support lifecycle, communicate it to customers ahead of time, and define the residual security posture (what you will and will not address) so clinicians can make informed continuity decisions." } } ] } ] --- [Skip to content](#main) [](/) [About](/about)[Speaking](/speaking)[Cybersecurity](/cybersecurity)[Programs](/programs)[Books](/books)[Media](/media) Writing Search Ctrl K[Connect](/connect) Article # Postmarket Vulnerability Management for Connected Medical Devices Direct answer Postmarket vulnerability management for a connected medical device is a continuous loop: monitor your SBOM against authoritative vulnerability feeds, triage findings against device-specific exploitability and patient-safety impact, coordinate disclosure with researchers and regulators, push validated patches to fielded devices within committed timelines, and document every step. The plan is reviewed at premarket and audited postmarket; both halves have to work. ## 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. On this page 1. [What does a postmarket cybersecurity program actually have to do?](#what-does-a-postmarket-cybersecurity-program-actually-have-to-do) 2. [Where do new vulnerability findings come from?](#where-do-new-vulnerability-findings-come-from) 3. [How do you triage a vulnerability when CVSS is misleading?](#how-do-you-triage-a-vulnerability-when-cvss-is-misleading) 4. [How fast do you actually have to patch?](#how-fast-do-you-actually-have-to-patch) 5. [What does a coordinated vulnerability disclosure program look like?](#what-does-a-coordinated-vulnerability-disclosure-program-look-like) 6. [How do you push a patch to a fielded device safely?](#how-do-you-push-a-patch-to-a-fielded-device-safely) ## 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](https://www.cisa.gov/) 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](https://bluegoatcyber.com/), 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](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/postmarket-management-cybersecurity-medical-devices) 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](https://nvd.nist.gov/) and the [CISA Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/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](https://www.iso.org/standard/72311.html) and [30111](https://www.iso.org/standard/69725.html). FIRST and the [CISA Coordinated Vulnerability Disclosure process](https://www.cisa.gov/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. KEY MISTAKE Treating postmarket cybersecurity as IT vulnerability management with a medical-device label slapped on. The triage axes, the documentation home, and the disclosure obligations are all different. Reuse the team, not the process. REVIEWER LANGUAGE When a postmarket plan reads 'we will issue patches as needed,' regulators see an unenforceable commitment. Pick timelines tied to severity, write them down, and live with them. ## How Christian approaches this At [Blue Goat Cyber](https://bluegoatcyber.com/) 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](https://medicaldevicecybersecuritybook.com)_ (see the [chapter overview](/books/medical-device-cybersecurity)). 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](/guides/sbom-hygiene-for-medical-devices-a-practical-2026-playbook), [Threat modeling connected medical devices](/guides/threat-modeling-connected-medical-devices-a-practitioner-guide), and [What the FDA actually wants in a 2026 premarket submission](/guides/what-the-fda-actually-wants-in-a-2026-premarket-cybersecurity-submission). ### Get the full playbook in book form This guide is one slice of \*Medical Device Cybersecurity: An In-Depth Guide\*, shipping in 2026. Get launch notification, the full chapter list, and a sample on the book site. [Visit the book site](https://medicaldevicecybersecuritybook.com) Prefer the on-site overview? See the chapter list at /books/medical-device-cybersecurity. ## Frequently asked questions ### Do I need a CVD program if my device is not internet-connected? Yes. Researchers find vulnerabilities in airgapped devices, supply-chain components, and companion software regardless of network exposure. A CVD channel is how those findings reach you legitimately instead of through a conference talk. ### What is the minimum monitoring cadence for postmarket vulnerability scanning? ### Do I have to notify FDA every time I find a vulnerability? ### How do I handle a vulnerability in a supplier component I cannot patch? ### What about end-of-support devices still in clinical use? ### Get the full playbook in book form This guide is one slice of \*Medical Device Cybersecurity: An In-Depth Guide\*, shipping in 2026. Get launch notification, the full chapter list, and a sample on the book site. [Visit the book site](https://medicaldevicecybersecuritybook.com) Prefer the on-site overview? See the chapter list at /books/medical-device-cybersecurity. About the author [Christian Espinosa](/about), MBA, CISSP, PMP · Founder, Blue Goat Cyber · Author, Medical Device Cybersecurity: An In-Depth Guide (2026) I'm the founder and CEO of Blue Goat Cyber, a medical device cybersecurity firm where my team has supported 250+ FDA submissions with zero failing to clear on cybersecurity. I previously founded and sold Alpine Security. I host The Med Device Cyber Podcast and wrote The Smartest Person in the Room and The In-Between: Life in the Micro, with Medical Device Cybersecurity: An In-Depth Guide out in 2026. Air Force Academy grad, 24x Ironman, climber of two of the Seven Summits. Christian Espinosa Bestselling author, keynote speaker, and Founding CEO of [Blue Goat Cyber](https://bluegoatcyber.com/). Helping technical leaders develop the soft skills that turn brilliance into impact. [](https://www.linkedin.com/in/christianespinosa/)[](https://x.com/Ironracer)[](https://www.instagram.com/christian.espinosa.official/)[](https://www.youtube.com/@ChristianEspinosaOfficial)[](https://www.facebook.com/christian.espinosa.official) Explore - [About](/about) - [Timeline](/timeline) - [Speaking](/speaking) - [Cybersecurity](/cybersecurity) - [Programs](/programs) Read - [Books](/books) - [Guides](/guides) - [Blog](/blog) - [Media](/media) - [Podcast Interviews](/podcasts) - [Success Stories](/success-stories) Connect - [Contact Christian](/connect) - [LinkedIn ↗](https://www.linkedin.com/in/christianespinosa/) - [Blue Goat Cyber ↗](https://bluegoatcyber.com/) - [Resources](/resources) © 2026 Christian Espinosa. All rights reserved. [Privacy](/privacy-policy)[Terms](/terms-of-use)