Coordinated Vulnerability Disclosure for Medical Device Cybersecurity
Practical guide to medical device CVD programs, including PSIRT setup, vulnerability intake, CVSS scoring, SBOM linkage, FDA Section 524B, EU expectations, and customer communication.
Why Coordinated Vulnerability Disclosure Is Now Mandatory
Medical device cybersecurity has moved from a voluntary best practice to a regulatory requirement. With the FDA's Quality Management System Regulation (QMSR) effective February 2, 2026 — incorporating ISO 13485:2016 by reference — cybersecurity is now a quality system element, not a standalone technical consideration.
Section 524B of the FD&C Act requires manufacturers of "cyber devices" to submit a plan to "monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures." This is not a recommendation — it is a legal requirement for any device with software that can connect to the internet (including USB, Bluetooth, serial, and Wi-Fi).
This guide provides a practical framework for building and operating a coordinated vulnerability disclosure (CVD) program for medical device manufacturers — from PSIRT establishment through vulnerability intake, triage, remediation, disclosure, and regulatory notification.
Regulatory Framework
FDA Requirements
| Requirement | Source | Effective Date |
|---|---|---|
| Vulnerability monitoring plan | Section 524B(b)(1) of the FD&C Act | March 2023 (enforcement from Oct 2023) |
| Coordinated disclosure procedures | Section 524B(b)(1) | March 2023 |
| SBOM for cyber devices | Section 524B(b)(2) | March 2023 |
| Cybersecurity in QMS | QMSR (21 CFR 820, amended) | February 2, 2026 |
| Premarket cybersecurity documentation | FDA Guidance, February 2026 | February 3, 2026 |
| Post-market cybersecurity management | FDA Postmarket Management Guidance (2016) | Ongoing |
The FDA's February 2026 cybersecurity guidance update aligns with QMSR, making clear that cybersecurity must be traced to ISO 13485 design controls (Clause 7.3), validation (Clause 7.3.7), and improvement processes (Clause 8.5). If your threat model cannot be traced to Clause 7.3 design controls, your cybersecurity framework is structurally outside the quality system.
EU Requirements
| Requirement | Source |
|---|---|
| Post-market surveillance | MDR Article 84–86 |
| Vigilance reporting | MDR Article 87–89 |
| Incident reporting | IVDR Article 82–84 |
| Cyber resilience | NIS2 Directive, Cyber Resilience Act |
| Notified body expectations | MDR Annex I GSPR 12.1 (software verification) |
| MDCG guidance | MDCG 2019-16 (cybersecurity for medical devices) |
The EU Cyber Resilience Act (CRA), adopted in 2024, introduces mandatory vulnerability handling requirements for products with digital elements, including medical devices. While MDR requirements take precedence for medical devices, manufacturers must be aware of overlapping obligations.
Building a PSIRT
A Product Security Incident Response Team (PSIRT) is the organizational structure for receiving, assessing, and resolving product security vulnerabilities.
PSIRT Structure
| Role | Responsibility |
|---|---|
| PSIRT Lead | Overall coordination, escalation decisions, regulatory notification |
| Vulnerability Analyst | Triage, CVSS scoring, SBOM correlation |
| Security Engineer | Reproducibility testing, exploit analysis, fix development |
| Regulatory Affairs | Notification decisions (MDR, 524B), field safety notices |
| Product Manager | Deployment scheduling, customer communication |
| Communications | Advisory drafting, disclosure coordination |
PSIRT Intake Channels
Manufacturers must provide at least one publicly accessible channel for vulnerability reporting:
| Channel | Best Practice |
|---|---|
| Dedicated email | security@company.com or psirt@company.com |
| Web form | Structured intake with required fields |
| PGP key | Encrypt sensitive submissions; publish public key |
| CISA coordinator | Register with CISA for coordinated disclosure |
| Bug bounty platform | Optional; HackerOne, Bugcrowd, or similar |
Safe Harbor Language
A vulnerability disclosure policy must include safe harbor language assuring good-faith researchers that they will not face legal action. Key elements:
Explicit scope (which products and versions are in scope)
What is out of scope (e.g., live patient environments, DoS testing)
Expected researcher behavior (no unauthorized data access, report promptly)
Manufacturer commitment (acknowledgment within defined SLA, no legal action for good-faith research)
Public disclosure timeline (typically 90 days, extendable for safety-critical issues)
Vulnerability Intake and Triage Process
Step 1: Intake and Acknowledgment
| Action | Timeline | Owner |
|---|---|---|
| Acknowledge receipt | Within 48 hours (business days) | PSIRT Analyst |
| Assign incident ID | At intake | PSIRT Analyst |
| Confirm scope | Within 5 business days | PSIRT Analyst |
| Initial classification | Within 5 business days | Vulnerability Analyst |
Step 2: Triage and Scoring
Each vulnerability must be assessed using a structured scoring methodology:
CVSS v4.0 Scoring (preferred for medical devices):
| CVSS Metric | Considerations for Medical Devices |
|---|---|
| Attack vector | Network, adjacent, local, physical |
| Attack complexity | Low/high — does exploit require specialized access? |
| Privileges required | None, low, high |
| User interaction | None, passive, active |
| Safety impact (new in v4) | Direct patient harm potential |
| Confidentiality | PHI/PII exposure risk |
| Integrity | Data modification risk affecting clinical decisions |
| Availability | Device downtime impact on clinical workflow |
Safety Impact Assessment: Beyond CVSS, medical device vulnerabilities require a separate safety impact assessment:
| Factor | Assessment |
|---|---|
| Could the vulnerability cause or contribute to patient harm? | ISO 14971 risk analysis |
| Is clinical function affected? | Impact on diagnostic or therapeutic output |
| Are there compensating controls? | Existing mitigations in the device or clinical environment |
| What is the installed base exposure? | How many devices, in what settings |
Step 3: SBOM Correlation
Cross-reference the vulnerability against your Software Bill of Materials:
| Step | Action |
|---|---|
| 1 | Identify affected component in SBOM |
| 2 | Determine which product versions contain the component |
| 3 | Map to installed base (how many devices, which customers) |
| 4 | Check for known exploits (CISA Known Exploited Vulnerabilities Catalog) |
| 5 | Assess if the component is actively maintained or end-of-support |
Per RunSafe Security's 2026 Medical Device Cybersecurity Index, 28% of healthcare organizations operate devices past end-of-support, and 44% acknowledge running devices with known, unpatched vulnerabilities.
Step 4: Classification and Prioritization
| Priority | Criteria | Expected Response Time |
|---|---|---|
| Critical | Active exploitation + patient safety risk | 24–72 hours |
| High | Exploitable + safety-relevant | 1–2 weeks |
| Medium | Exploitable, no direct safety impact | 30–60 days |
| Low | Theoretical, significant barriers to exploitation | 90 days |
Remediation and Fix Development
Fix Development Workflow
| Step | Action | Quality System Record |
|---|---|---|
| 1 | Root cause analysis | CAPA record |
| 2 | Develop fix | Design change per ISO 13485 Clause 7.3.9 |
| 3 | Verify fix effectiveness | Design verification |
| 4 | Validate no regression | Regression testing |
| 5 | Security testing of fix | Penetration testing, SAST/DAST |
| 6 | Update SBOM | SBOM revision record |
| 7 | Prepare customer communication | Advisory, IFU update |
| 8 | Submit to FDA if required | 30-day notice or PMA supplement |
When FDA Notification Is Required
| Scenario | FDA Reporting | Timeline |
|---|---|---|
| Vulnerability may have caused or contributed to death/serious injury | MDR report (21 CFR Part 803) | Within 30 days (10 days for certain events) |
| Vulnerability creates unreasonable risk of substantial harm | 524B disclosure + field correction | Before or at time of disclosure |
| Software update to address cybersecurity vulnerability | 30-Day Notice (for PMA) or new 510(k) if indications/technology change | Per applicable pathway |
| No patient safety impact, routine patch | Document in vulnerability monitoring plan | Per internal schedule |
Coordinated Disclosure
Disclosure Timeline
| Day | Action |
|---|---|
| 0 | Receive vulnerability report |
| 1–5 | Acknowledge, triage, classify |
| 5–15 | Reproduce vulnerability, develop remediation plan |
| 15–45 | Develop and test fix |
| 45–60 | Prepare advisory, coordinate with reporter |
| 60–75 | Internal review, regulatory notification if needed |
| 75–90 | Publish advisory and deploy fix |
| 90+ | If fix requires longer, communicate timeline to reporter and extend |
The standard coordinated disclosure timeline is 90 days from report to public advisory. For medical devices where patient safety is involved, extensions may be necessary and should be communicated transparently to the reporter.
Advisory Content
A security advisory should include:
| Section | Content |
|---|---|
| Title | Clear identification of the vulnerability |
| Affected products | Product names, model numbers, software versions |
| Vulnerability description | Technical details (CVE number if assigned) |
| Impact assessment | Safety, clinical, and security impact |
| CVSS score | v3.1 and/or v4.0 score with vector string |
| Mitigations | Interim measures customers can take |
| Remediation | Software update version, how to obtain |
| Credit | Acknowledgment of reporter (if agreed) |
| Contact | PSIRT contact information |
Multi-Party Coordination
When a vulnerability affects components shared across multiple manufacturers:
Coordinate through CISA's coordinated vulnerability disclosure process
Use Traffic Light Protocol (TLP) labels for information sharing (TLP:AMBER for limited distribution, TLP:GREEN for community-wide)
Agree on common disclosure date across affected manufacturers
Follow FIRST.org guidelines for multi-party coordination
Integration with Quality Management System
Under QMSR, cybersecurity must be integrated into the quality management system. Key integration points:
| QMS Element | Cybersecurity Integration |
|---|---|
| Design controls (ISO 13485 Clause 7.3) | Threat modeling, security requirements |
| Design validation (Clause 7.3.7) | Security testing as part of validation |
| CAPA (Clause 8.5) | Vulnerability handling in improvement processes |
| Supplier management (Clause 7.4) | SBOM tracking, third-party component monitoring |
| Post-market surveillance (MDR Art. 84) | Vulnerability monitoring as PMS input |
| Risk management (ISO 14971) | Security risks assessed alongside safety risks |
FDA's Compliance Program Manual (#7382.850), effective February 2, 2026, includes a cybersecurity section to support investigators during inspections — signaling that FDA inspectors will assess cybersecurity during routine QMS audits.
Compliance Checklist
Use this checklist to assess your CVD program readiness:
| Element | Status |
|---|---|
| PSIRT charter with defined roles and responsibilities | ☐ |
| Public vulnerability disclosure policy with safe harbor language | ☐ |
| Dedicated intake channel (email, web form) with PGP encryption | ☐ |
| SLA for acknowledgment (48 hours) and triage (5 business days) | ☐ |
| CVSS v4.0 scoring methodology documented | ☐ |
| Patient safety impact assessment procedure | ☐ |
| SBOM maintained for each released product version | ☐ |
| Installed base mapping (customers, product versions, locations) | ☐ |
| Vulnerability-to-SBOM correlation procedure | ☐ |
| Fix development workflow integrated with QMS design controls | ☐ |
| Advisory template with all required sections | ☐ |
| Regulatory notification decision tree (MDR, 524B, 30-day notice) | ☐ |
| Multi-party coordination procedure (CISA, TLP) | ☐ |
| 90-day disclosure timeline with extension criteria | ☐ |
| Annual program review and metrics reporting | ☐ |
| Training records for PSIRT team members | ☐ |
| Evidence retention in quality system for audit readiness | ☐ |
Key Takeaways
Section 524B makes coordinated vulnerability disclosure a legal requirement for cyber devices — not a voluntary best practice.
PSIRT structure must be formalized with defined roles, intake channels, SLAs, and safe harbor language.
CVSS v4.0 scoring includes a safety impact metric particularly relevant for medical devices — use it alongside ISO 14971 risk analysis.
SBOM correlation is essential for understanding installed base exposure — 81% of procurement professionals now rate SBOMs as important or essential.
QMS integration is non-negotiable under QMSR — cybersecurity must trace to ISO 13485 design controls, validation, and improvement processes.
FDA inspectors will assess cybersecurity during routine QMS audits per Compliance Program Manual #7382.850.
Sources
FDA Guidance: Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)
FD&C Act Section 524B — Ensuring Cybersecurity of Medical Devices
FDA Postmarket Management of Cybersecurity in Medical Devices (2016)
FDA Compliance Program Manual #7382.850 (effective February 2, 2026)
RunSafe Security — 2026 Medical Device Cybersecurity Index
MDIC — Medical Device Cybersecurity Report: Advancing Coordinated Vulnerability Disclosure (2018)
FIRST.org — Guidelines for Multi-Party Vulnerability Coordination
MDCG 2019-16 — Cybersecurity for Medical Devices
EU Cyber Resilience Act (2024)