Does the CRA apply to medical devices?

Medical devices regulated under the EU Medical Device Regulation (MDR) or In Vitro Diagnostic Medical Device Regulation (IVDR) are addressed by those sector-specific regulations and may be partially or wholly exempt from the CRA. However, the exact scope of exemptions depends on the specific device classification and whether the MDR/IVDR fully covers the cybersecurity obligations. Consult legal counsel and MDCG guidance. Many manufacturers choose to comply with both frameworks to avoid gaps.

What is a 'serious incident' under MDR and how does it relate to a security vulnerability?

Under MDR Article 87, a serious incident includes any malfunction or deterioration in the characteristics or performance of a device that has led to or could lead to the death or serious deterioration of health of a patient. A successfully exploited security vulnerability that alters device function, prevents correct diagnosis, or modifies therapy delivery would likely constitute a serious incident requiring notification to the national competent authority within 15 days - or immediately for serious public health threats.

How do we balance coordinated disclosure timelines with patient safety?

Patient safety always takes priority. If a vulnerability poses immediate patient risk, you may need to notify healthcare customers and issue interim mitigations before a full patch is available - even before coordinated disclosure concludes. Work with your notified body and national competent authority on the appropriate communication strategy. Researchers who discover patient safety issues should be informed that the 90-day coordination window may be compressed in these cases.

Should we offer a bug bounty for medical device vulnerabilities?

Bug bounty programmes for medical devices are increasingly common (e.g. several major medtech companies run them) but require careful scoping to prevent testing on clinical systems. If you offer a bounty, require researchers to agree to specific terms prohibiting clinical environment testing and to use only lab environments or provided test hardware.

How do we handle vulnerabilities in legacy medical devices that are no longer supported?

For legacy devices, you have an obligation to at minimum communicate the vulnerability to customers so they can make risk management decisions (e.g. network segmentation, discontinuing use, seeking replacement). MDR post-market surveillance obligations may still apply. Issue a public advisory and coordinate with the national competent authority on appropriate customer communication.

← All templates

Free Template

CVD Policy Template for Medical Device Manufacturers

A CVD policy template for manufacturers of medical devices with digital elements. Navigates the intersection of the EU Cyber Resilience Act, the Medical Device Regulation (MDR), and international medical device cybersecurity guidance. Emphasises patient safety as the primary escalation trigger.

Article 13 · Article 14 · Annex I

ForMedical device manufacturers, health IT vendors, and connected diagnostics companies operating in the EU and seeking to align with CRA, MDR, and IEC 80001-1 requirements

CRA Articles

Article 13Article 14Annex I

Policy Statement

Article 13(1)

[COMPANY NAME] develops medical devices that incorporate software and digital connectivity. Patient safety is our primary obligation, and the security of our devices is inseparable from that obligation. This Coordinated Vulnerability Disclosure (CVD) policy governs how we receive, assess, and respond to security vulnerability reports for [COMPANY NAME] medical devices and software.

This policy applies alongside our obligations under the EU Medical Device Regulation (MDR, Regulation (EU) 2017/745), the EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847 - where applicable), IEC 80001-1 (risk management for IT networks incorporating medical devices), and international medical device cybersecurity guidance.

Note

Medical device CVD policies must place patient safety first, before commercial considerations. Regulators (EMA, national competent authorities, FDA for US exports) expect this framing. Mentioning MDR alongside CRA signals that you understand the layered regulatory context.

Regulatory Context

Article 13

[COMPANY NAME] products are regulated as medical devices under MDR class [I / IIa / IIb / III]. Our notified body is [NOTIFIED BODY NAME AND NUMBER].

Security vulnerabilities in medical devices may trigger obligations under multiple regulatory frameworks:

EU Cyber Resilience Act (CRA): Article 13 and 14 obligations for products with digital elements (where applicable; medical devices covered exclusively by MDR may be partially or wholly exempt - consult legal counsel)
EU MDR Article 87: Serious incident reporting to competent authorities where a vulnerability leads or could lead to patient harm
MDCG 2019-16 and MDCG 2021-25: EU guidance on cybersecurity for medical devices
IEC 81001-5-1: Security for health software and health IT systems

This policy addresses all these obligations in a unified process.

Note

The CRA/MDR interaction is complex - medical devices primarily regulated under MDR may be exempt from parts of the CRA. However, the safest approach is to treat CRA obligations as additive unless you have clear legal analysis. Document your regulatory classification in the policy.

Scope

Article 13(4)

This policy covers:

[DEVICE NAME 1] (UDI: [UDI], software version [X.X] and later)
[DEVICE NAME 2] (UDI: [UDI], software version [X.X] and later)
Associated Software as a Medical Device (SaMD): [APP NAME] (iOS [VERSION]+, Android [VERSION]+)
Cloud services and APIs that process patient data or device data: [DOMAIN]
Remote monitoring and telemedicine infrastructure

Out of scope:

Vulnerabilities requiring physical destruction of the device
Vulnerabilities in hospital IT networks not operated by [COMPANY NAME]
Devices at end-of-support (see lifecycle page at [EOL URL])

Note

Medical device scope must include UDI references where possible - regulators use UDIs to track device-level incidents. Including SaMD (Software as a Medical Device) explicitly is important as these are separately regulated in some jurisdictions.

Patient Safety Escalation

Article 14

Patient safety is the overriding priority in our vulnerability response process.

Immediate escalation triggers - Any vulnerability that meets the following criteria requires immediate escalation to our Chief Medical Officer (or equivalent) and legal counsel, regardless of CVSS score:

Could cause or contribute to patient injury or death
Could cause incorrect diagnosis, treatment, or medication dosing
Could allow unauthorised modification of device settings or therapy delivery
Is actively being exploited in a clinical environment
Has been reported as causing or nearly causing patient harm

Escalation contacts:

Chief Medical Officer: [NAME], [CONTACT]
VP Engineering / Device Safety: [NAME], [CONTACT]
Regulatory Affairs: [NAME], [CONTACT]
Legal Counsel: [NAME], [CONTACT]

In the event of a patient safety escalation, remediation timeline obligations and disclosure coordination are secondary to patient protection.

Note

A patient safety escalation clause is non-negotiable for medical device CVD policies. This section must have named owners with backup contacts and must be rehearsed in tabletop exercises. The trigger is clinical impact potential - not CVSS score.

How to Report a Vulnerability

Article 13(1)

To report a security vulnerability in a [COMPANY NAME] medical device or software:

Portal (preferred): [VULNERABILITY DISCLOSURE PORTAL URL] Email: [[email protected]] PGP key: Fingerprint [FINGERPRINT], available at [PGP KEY URL] Phone (urgent patient safety issues): [PHONE NUMBER] (24/7)

Please include:

Device name, UDI, and software/firmware version
Description of the vulnerability and potential clinical impact
Whether the vulnerability has been observed in a clinical environment
Whether you are aware of any patient harm or near-miss associated with this vulnerability
Reproduction steps and proof of concept

All reports are treated as strictly confidential. If you have reason to believe a patient has been harmed, please contact us by phone immediately.

Note

Medical device programmes must include a phone number for urgent patient safety reports. A researcher who discovers an actively exploited vulnerability causing patient harm should not be limited to a web form. The 24/7 contact demonstrates operational readiness.

Response Commitments and Regulatory Notification

Article 13, Article 14

[COMPANY NAME] commits to the following response timeline:

| Milestone | Target | |---|---| | Acknowledgment | Within 24 hours (48 hours for non-urgent) | | Patient safety assessment | Within 24 hours of receipt | | Initial severity assessment | Within 3 business days | | Status updates to reporter | At least every 14 days for Critical/High | | Patch or mitigation | Per severity SLA (see below) |

Regulatory notification timelines:

MDR Article 87 serious incident: Notify national competent authority within 15 days (immediately for serious public health threats)
CRA Article 14 (where applicable): ENISA early warning within 24 hours of becoming aware of active exploitation; full notification within 72 hours
MDCG guidance: Coordinate with EUDAMED for device-level incident records

Severity SLAs:

Patient safety risk (any CVSS): 24–72 hours for interim mitigation; patch as soon as practicable
Critical (CVSS 9.0–10.0, no patient safety risk): 14 days
High (CVSS 7.0–8.9): 30 days
Medium/Low: 90 days / next release

Note

Medical device response timelines are more compressed than general software because patient harm can occur in hours. Acknowledge within 24 hours, triage patient safety within 24 hours. Separate the CVSS-based SLAs from the patient safety SLAs - the latter override all others.

Safe Harbour

[COMPANY NAME] authorises security research conducted in good faith on our products in accordance with this policy. We will not pursue legal action against researchers who:

Use only devices they own or have explicit permission to test
Do not test on devices connected to real patients or in clinical use
Do not interfere with clinical operations, patient data, or live hospital networks
Report findings to us before any public disclosure
Comply with applicable law and medical device regulations in their jurisdiction

Testing environments: We strongly recommend that vulnerability research on [COMPANY NAME] medical devices be conducted in isolated lab environments, not on devices in clinical use. We can provide test firmware or sandbox environments upon request - contact [[email protected]].

Researchers who believe they have discovered a patient safety issue should contact us immediately by phone at [PHONE NUMBER].

Note

Medical device safe harbour must explicitly prohibit testing on devices in clinical use - this is both a patient safety and a legal liability issue. Offering test firmware or sandbox environments is a significant differentiator and encourages higher-quality research.

Use this template automatically in CVD Portal

CVD Portal generates your CVD policy, tracks acknowledgments, and creates an audit trail — free for Article 14 compliance.

Set up your free portal

Frequently asked questions

Ready to go beyond the template?

CVD Portal automates acknowledgments, tracks deadlines, and generates CSAF advisories — free.

Set up your free portal

Related templates

CRA-Compliant CVD Policy Template

A comprehensive CVD policy structured specifically for the EU Cyber Resilience Act. Addresses Articles 13 and 14 obligations including 24-hour early warning, 72-hour full notification, and coordinated disclosure timelines.

Vulnerability Reporting Process Template

An internal-facing vulnerability reporting process that documents how your security team handles incoming reports from intake through resolution. Complements your public CVD policy with operational procedures aligned to CRA Article 13 and 14.

PSIRT Charter Template

A formal charter for establishing or formalising a Product Security Incident Response Team (PSIRT). Defines the team's mandate, authority, scope, membership, and operating procedures under the EU Cyber Resilience Act and ISO/IEC 30111.

Article 14 Early Warning Notification Template

A structured notification template for the CRA Article 14 24-hour early warning obligation. Designed to be submitted to ENISA (or the relevant national CSIRT) when a manufacturer discovers an actively exploited vulnerability or severe security incident.