VDP and CVD Workflows for Medical Devices

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.

The workflow and SLA examples below are recommendations, not mandatory conformance to ISO standards. A 30-day target is illustrative, not a safe waiting period: address critical vulnerabilities with uncontrolled risk as soon as possible out of cycle, and communicate urgent mitigation advice before a patch when needed. Publish security.txt at /.well-known/security.txt in accordance with RFC 9116.

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.

Section 524B requires the postmarket plan, including coordinated vulnerability disclosure. The FDA’s February 3, 2026 guidance provides nonbinding implementation recommendations; it does not make every VDP design choice a statutory obligation.

Statutory CVD duty and implementation choices

Section 524B(b)(1) requires a plan including CVD and related procedures for covered cyber-device submissions. The following are recommended implementation choices, not individually prescribed statutory requirements:

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.

Gaps may prompt questions; adequacy depends on the device, evidence, and applicable requirements. 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.

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
• HHS HPH CPGs for Medical Device Manufacturers - disclosure obligations in the HPH performance goals.

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?

Section 524B requires a postmarket plan that includes CVD. A public VDP is a recommended way to support intake, but a public URL and safe harbor are not separately prescribed by that statute.

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

Free tools for this

• CVD Policy Generator - generate a coordinated vulnerability disclosure policy and intake workflow.