VDP and CVD Workflows for Medical Devices

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:

1. A published CVD policy at a stable URL, referenced from device labeling.
2. An intake mechanism (email, web form, or both) that does not require an account to submit.
3. Acknowledgment of reports within a defined window.
4. A triage and response workflow that ties vulnerabilities back to your SBOM, security risk file, and postmarket cybersecurity plan.
5. Validated patch deployment with signature, integrity, and rollback, the same mechanism evaluated in the premarket submission.
6. 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)

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

2. 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.

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

4. 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.

5. 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.

6. 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.

7. 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.

8. 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)

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

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

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

4. 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.

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

6. 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 Management 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