Vulnerability Disclosure Programs for Medical Devices (VDP & CVD)

VDP & CVD GUIDE · UPDATED 2026

A practical, ungated guide to standing up a Vulnerability Disclosure Program (VDP) and a Coordinated Vulnerability Disclosure (CVD) workflow that satisfies the FDA's February 2026 premarket cybersecurity guidance, aligns to ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling), and actually works for a small MedTech security team.

VDP vs. CVD - they are not the same thing

These two terms get used interchangeably. They should not be.

• VDP (Vulnerability Disclosure Program) is the external-facing policy: how researchers and customers report a vulnerability to you, what they can expect in return, what is in scope, what is out of scope, and what safe-harbor protections you offer. It lives on a public URL.
• CVD (Coordinated Vulnerability Disclosure) is the internal workflow: triage, ownership, risk assessment, fix development, validated patching, customer communication, and (when appropriate) public disclosure - coordinated with the reporter and any affected third parties.

A VDP without a CVD workflow is a 404-in-waiting. A CVD workflow without a VDP gives no one a way in.

The FDA expects both. Section 524B and the February 2026 guidance treat them as a single integrated submission element under "Coordinated Vulnerability Disclosure."

What FDA actually requires

The cybersecurity labeling and CVD requirements are explicit:

01 - A published CVD policy at a stable URL, referenced from device labeling. 02 - An intake mechanism (email, web form, or both) that does not require an account to submit. 03 - Acknowledgment of reports within a defined window. 04 - A triage and response workflow that ties vulnerabilities back to your SBOM, security risk file, and postmarket cybersecurity plan. 05 - Validated patch deployment with signature, integrity, and rollback - the same mechanism evaluated in the premarket submission. 06 - Customer communication for vulnerabilities that meaningfully affect safety, performance, or security posture.

If any of those are missing, the submission gets a deficiency. See our FDA Cybersecurity Deficiency Letter Examples for the exact phrasing reviewers use.

The reference VDP policy (use this as a starting point)

The published policy should cover, at minimum:

• Scope - which products, firmware versions, mobile apps, cloud endpoints, and APIs are in scope.
• Out of scope - corporate IT systems, marketing sites, physical security, social engineering, denial-of-service against production patient-facing endpoints.
• Submission channel - email alias (e.g. cvd@yourcompany.com) and/or a web form that does not require account creation.
• Information requested - device model, firmware version, reproduction steps, impact, evidence (logs, screenshots, PoC), reporter contact.
• Safe harbor - commitment not to pursue legal action against good-faith research that stays within scope and avoids patient harm.
• Coordination model - your default disclosure timeline (e.g. 90 days), willingness to credit reporters, and how you handle disagreements.
• Reference standards - ISO/IEC 29147 and 30111, plus CISA's Coordinated Vulnerability Disclosure Process.

The CVD workflow (eight stages)

01 - Intake. Report arrives via email or form. Auto-acknowledge within 1 business day with a tracking ID.

02 - Triage. Security on-call assigns severity using CVSS v4.0 and patient-safety impact. Open a tracking record linked to the affected SKU, firmware version, and SBOM entries.

03 - Validation. Reproduce in a controlled environment. If non-reproducible, request additional information from the reporter. Document the negative result if validation fails.

04 - Risk assessment. Map the vulnerability to your ISO 14971 risk file and your security risk assessment. Update exploitability-to-harm. If the vulnerability changes residual risk, the change goes through QMS change control.

05 - Fix development. Engineering owns the patch. Security pairs on the threat model update. Verification includes regression testing and, for safety-critical fixes, a targeted re-test from your penetration testing partner.

06 - Validated patching. Patch deploys through the same validated update mechanism evaluated in the premarket submission - signature, integrity, atomic install, rollback. Document the deployment in the postmarket cybersecurity plan.

07 - Customer communication. For vulnerabilities affecting safety, performance, or security posture: a security bulletin / advisory goes out to affected customers. Use VEX to communicate the status to downstream SBOM consumers.

08 - Disclosure & closure. Coordinate public disclosure timing with the reporter (if applicable). Close the tracking record with: root cause, fix description, affected versions, and any standards (NVD CVE, CISA KEV) referenced. Update the SBOM and security risk file.

A reference SLA model

Most MedTech teams cannot run a 24-hour SOC. They do not need to. They need predictable SLAs scaled to severity.

| Severity | Acknowledge | Validate | Patch / Mitigate | Customer Comms | | Critical (active patient harm path) | 1 business day | 5 business days | 30 days | Concurrent with patch | | High | 1 business day | 10 business days | 90 days | With patch release | | Medium | 3 business days | 20 business days | Next scheduled release | Release notes | | Low | 5 business days | 30 business days | Next scheduled release | Release notes |

Publish the SLAs in the CVD policy. Reviewers look for them; reporters trust you more when they exist.

How VDP / CVD ties into the rest of the SPDF

A working CVD workflow is downstream of the rest of the Secure Product Development Framework:

• SBOM tells you which component a CVE affects.
• Threat model tells you whether the affected component is exposed at a trust boundary that matters.
• Security risk file tells you whether the new vulnerability changes residual risk.
• Validated update mechanism is how the fix actually reaches devices in the field.
• Postmarket cybersecurity plan is the operational umbrella that all of the above lives under.

Teams that try to bolt a CVD program onto a device that lacks one or more of those pieces end up with a policy URL and no workflow behind it. That is the failure mode FDA flags hardest.

The most common deficiencies (and how to avoid them)

01 - Policy URL 404s or redirects. Use a stable URL. Test it monthly.

02 - No safe harbor language. Security researchers will not engage with you if a good-faith report could expose them to legal risk.

03 - No defined SLAs. "We will respond as quickly as possible" is not an SLA. Use the table above.

04 - CVD policy decoupled from SBOM. If a reporter cites CVE-2025-XXXX in OpenSSL, you should be able to identify every affected device, firmware version, and patch path within hours - not weeks.

05 - No customer communication channel. Even a simple security advisory mailing list (opt-in at device registration) is enough. Silence is the worst option.

06 - Patch path not validated. If your update mechanism cannot ship a signed, rollback-safe patch in 30 days, your Critical SLA is fiction.

Where this fits in the cluster

This page sits inside our postmarket and SPDF clusters:

• The SPDF Playbook for FDA-Ready Medical Devices
• Postmarket Cybersecurity Readiness Plan
• SBOM Vulnerability Management for Medical Devices
• VEX Documents for Medical Devices
• eSTAR Cybersecurity Readiness Checklist

Related from Blue Goat Cyber

• FDA Postmarket Cybersecurity Services
• Postmarket SBOM & VEX Monitoring
• Medical Device Penetration Testing
• Submit a vulnerability via our CVD intake

FAQ

Is a VDP required for FDA cybersecurity submissions?

A CVD process is required under Section 524B and the February 2026 final guidance. A public-facing VDP is the standard way to operationalize the intake side of CVD. In practice: yes, you need both, and reviewers expect to find the policy URL referenced in your cybersecurity labeling.

What is the difference between ISO/IEC 29147 and ISO/IEC 30111?

29147 covers disclosure - how an organization receives information about vulnerabilities and publishes resolutions. 30111 covers handling - the internal processes for investigating, triaging, and resolving them. Together they describe the full VDP + CVD picture.

Do I need a bug bounty for a VDP?

No. A VDP and a bug bounty are different things. A VDP is the disclosure channel and policy. A bug bounty adds monetary rewards. FDA does not require a bug bounty; many MedTech companies run a VDP without one.

How do I scope a VDP for medical devices safely?

Out-of-scope clauses matter. Exclude any testing that could degrade patient-facing production endpoints, attempts to access PHI, physical attacks on installed devices, and social engineering of clinical staff. Define a non-production / lab-device path for high-value testing.

What if a vulnerability requires a recall instead of a patch?

The CVD workflow escalates to the QMS recall process. Cybersecurity does not bypass quality - the postmarket cybersecurity plan and the recall procedure are linked. See our FDA Postmarket Cybersecurity Services for the full operational model.

Sources & primary references

• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (FDA, February 2026 final guidance)
• ISO/IEC 29147:2018 - Vulnerability Disclosure
• ISO/IEC 30111:2019 - Vulnerability Handling Processes
• CISA Coordinated Vulnerability Disclosure Process
• CVSS v4.0 Specification (FIRST.org)
• FDA Postmarket Management of Cybersecurity in Medical Devices