Medical Device Cyberattack: Healthcare’s 24-Hour NIS2 Clock and the Manufacturer’s 15-Day MDR Vigilance Report

When ransomware locks a hospital’s imaging archive, most incident response plans open at the same page: notify the national CSIRT within 24 hours. That is correct, and it is roughly half of what the law actually sets in motion.

The other half runs at a different company. Under Regulation (EU) 2017/745 (the MDR), a cyberattack that degrades a medical device’s performance can qualify as a serious incident, and the duty to report it to a competent authority sits with the device’s manufacturer — on a clock measured in days, not hours, and one that only starts when the manufacturer finds out [2]. ENISA’s health-sector threat landscape found that 22% of analysed incidents disrupted healthcare services directly, against 43% that resulted in breaches or theft of data [7] — two outcome categories that engage these regimes very differently.

Does This Apply to You? Hospital, Clinic, or Device Manufacturer

In plain terms: NIS2 covers organisations, not products. Which annex you land in decides your penalty ceiling and your supervisory regime, and medical device manufacturers are split across two of them.

NIS2 Annex I, point 5 ("Health") lists healthcare providers as defined in Article 3, point (g) of Directive 2011/24/EU, EU reference laboratories, entities carrying out research and development of medicinal products, entities manufacturing basic pharmaceutical products, and — the fifth indent — entities manufacturing medical devices considered to be critical during a public health emergency within the meaning of Article 22 of Regulation (EU) 2022/123 [1].

Every other MDR or IVDR manufacturer sits in Annex II, sector 5(a), which explicitly carves out "entities manufacturing medical devices referred to in Annex I, point 5, fifth indent" [1]. The practical effect is a two-tier split among manufacturers of the same class of product.

Entity	NIS2 position	Fine ceiling under Article 34
Hospital, clinic, other healthcare provider	Annex I, point 5 — essential entity (subject to size thresholds)	At least EUR 10 million or 2% of worldwide turnover, whichever is higher [1]
Manufacturer of a public-health-emergency critical device	Annex I, point 5, fifth indent — essential entity	At least EUR 10 million or 2%, whichever is higher [1]
All other MDR / IVDR manufacturers	Annex II, sector 5(a) — important entity	At least EUR 7 million or 1.4% of worldwide turnover, whichever is higher [1]

A hospital and its device vendor can therefore both be in scope for the same incident while sitting in different annexes, under different supervisory regimes, with different fine ceilings — and with entirely different filing duties. That last difference is where most incident plans come apart. Our NIS2 healthcare compliance guide covers the Article 21 measure set behind these obligations.

The Two Clocks, and Who Runs Each One

In plain terms: your NIS2 clock starts when your staff become aware. The manufacturer’s MDR clock starts when the manufacturer becomes aware — which may be days later, and only if someone tells them.

NIS2 Article 23(4) requires Member States to ensure that in-scope entities submit an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report not later than one month after that 72-hour notification [1]. Germany’s BSI reads "becoming aware" strictly: the moment an employee of the entity, during working hours, learns of a significant incident [6].

MDR Article 87 runs on a completely different structure — tiered by severity rather than by report stage, and binding on manufacturers only [2].

Filing	Who files	Deadline	Legal basis
Early warning	The healthcare entity (or manufacturer, as a NIS2 entity in its own right)	24 hours from becoming aware	NIS2 Art. 23(4)(a) [1]
Incident notification	Same entity	72 hours from becoming aware	NIS2 Art. 23(4)(b) [1]
Final report	Same entity	1 month after the 72-hour notification	NIS2 Art. 23(4)(d) [1]
Vigilance report — serious public health threat	The device manufacturer	Immediately, and not later than 2 days	MDR Art. 87(4) [2]
Vigilance report — death or unanticipated serious deterioration in health	The device manufacturer	Not later than 10 days	MDR Art. 87(5) [2]
Vigilance report — all other serious incidents	The device manufacturer	Not later than 15 days	MDR Art. 87(3) [2]

The dependency runs one way and it is fragile. MDR Article 87(3) starts the manufacturer’s 15-day clock "after they become aware of the incident" — so if your hospital never tells the vendor, the vendor’s clock never starts. The MDR routes around this only indirectly: Annex I, section 23.4(z) requires the instructions for use to carry a notice that serious incidents should be reported to the manufacturer and the national competent authority, and Article 87(11) requires an authority receiving such a report to inform the manufacturer without delay [2]. None of that is a self-executing deadline on the hospital — which is why vendor notification belongs in your runbook as an explicit step, not an assumed courtesy.

Is a Device Cyberattack an MDR "Serious Incident"?

In plain terms: yes, more often than teams expect — and the Commission’s own guidance already answers this for named attack scenarios.

MDR Article 2(64) defines an incident as "any malfunction or deterioration in the characteristics or performance of a device made available on the market" [2]. Ransomware that renders a device unusable is a deterioration in performance. Article 2(65) then defines a serious incident as any incident that "directly or indirectly led, might have led or might lead to" death, temporary or permanent serious deterioration of health, or a serious public health threat [2]. The phrase "might have led" does substantial work: actual patient harm is not required.

MDCG 2019-16 Rev.1, endorsed by the Medical Device Coordination Group, works through named scenarios in an annex. It is guidance rather than binding law and its own disclaimer calls the table illustrative — but it is the clearest official signal available [3].

Scenario	Serious incident?	Stated reason
Ransomware or scareware deployed against a PACS	Yes	"Health damage caused by unavailability" [3]
Network-spread worm encrypts a Windows-based device’s hard drive	Yes	No direct safety harm; indirect — device not available [3]
Malware installed on a ventilator via USB	Yes	Respiration functionality does not work as intended [3]
Attacker manipulates a ventilator’s alarm messages to the central monitor	Yes	Emergency measures are not carried out in time [3]
Attacker eavesdrops on patient-monitor traffic and obtains health information	No	"Security risk only" — safety harm recorded as none [3]
Unauthorised USB export of therapy and patient data from a warming therapy device	No	"Security risk only" — safety harm recorded as none [3]

Where genuine uncertainty remains, MDR Article 87(7) resolves it in one direction: if the manufacturer is unsure whether an incident is reportable, "it shall nevertheless submit a report" within the applicable timeframe [2].

The Confidentiality Inversion Nobody Plans For

In plain terms: the attack that triggers your biggest data-protection filing may trigger no MDR filing at all — and the attack that steals nothing may trigger the largest one.

Read the two "No" rows above again. Both are pure confidentiality compromises: patient data read, copied, exfiltrated. Both are recorded as not serious incidents, because MDR severity is measured in health outcomes, not in records lost [3]. Yet both are textbook personal data breaches under the GDPR, and both may satisfy NIS2 Article 23(3)(b), which turns on affecting "other natural or legal persons by causing considerable material or non-material damage" [1]. Invert it and the same asymmetry runs the other way: ransomware that encrypts a PACS and exfiltrates nothing is a serious incident under the MDCG determinations [3], engages Article 23(3)(a) on operational disruption [1], and — because the EDPB classifies "an accidental or unauthorised loss of access to, or destruction of, personal data" as an availability breach [8] — is a GDPR breach too.

So "how much data was taken?" is the wrong first triage question for MDR purposes. The right one is "did any device stop doing what a clinician relied on it to do?" Teams running a data-first triage systematically under-report to device manufacturers. Our guide on NIS2 and GDPR dual notification works through the two-regime trigger matrix in detail, and the ransomware reporting obligations guide covers the availability side.

Your Significance Threshold Is Not the EUR 500,000 Test

In plain terms: if you are a hospital, the euro threshold you have read about was never yours. There is nothing to escape.

A persistent misconception in healthcare compliance briefings is that patient-safety impact provides a special route around a financial reporting threshold. Checked against the primary text, the premise itself is wrong. The EUR 500,000 figure comes from Commission Implementing Regulation (EU) 2024/2690, Article 3(1)(a). But Article 1 of that Regulation names the entities it binds, in full: DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online market places, of online search engines and of social networking services platforms, and trust service providers [5]. Healthcare providers are not on that list. Neither the euro test nor the Regulation’s patient-harm criteria in Article 3(1)(c) and (d) bind a hospital directly.

What governs a healthcare entity is NIS2 Article 23(3) itself, which contains no monetary figure anywhere — only the two limbs of severe operational disruption or considerable damage to other persons [1]. Patient-safety impact is not an override; it is simply what limb (b) is about.

National authorities do fill the gap. Germany’s BSI states that for entities in sectors the Implementing Regulation does not cover, a significant incident may be presumed where at least one of the Article 3(1) criteria is met, and adds a national rule with no duration or user element at all: a significant incident is always to be assumed where the provision of critical services has failed or been impaired [6]. That is national guidance rather than Directive text, and it applies in Germany.

What a Cybersecurity Vigilance Report Has to Contain

In plain terms: an MDR vigilance report is not a free-text incident summary. It is a coded filing, and the codes are already specified.

MDCG 2019-16 requires a manufacturer investigating a cyber-related serious incident to describe both the incident itself — including whether information was compromised or threatened — and the health effects, covering clinical signs, symptoms and overall health impact [3]. The filing is then indexed using IMDRF codes: A1105 "Computer System Security Problem", subdivided into A110501 "Application Security Problem" and A110502 "Unauthorized Access to Computer System", with root cause coded C1007 "Software Security Vulnerability" [3].

There is also a third channel almost nobody operates. Cyber-related incidents falling short of "serious" are subject to trend reporting under MDR Article 88 — the manufacturer reports any statistically significant increase in the frequency or severity of non-serious incidents [2], [3]. For a hospital this reframes the low-grade noise in the estate: a run of unexplained device reboots that individually justify no filing may be exactly what the manufacturer needs to detect a trend it is separately obliged to report.

Who Files What — and Why the CRA Is Not on Your List

In plain terms: three regimes may fire, not four. The Cyber Resilience Act is carved out for MDR devices.

A common claim in vendor content is that a connected medical device incident triggers NIS2, MDR and the Cyber Resilience Act together. For the device itself, it does not. CRA Article 2(2) is unambiguous: "This Regulation does not apply to products with digital elements to which the following Union legal acts apply: (a) Regulation (EU) 2017/745; (b) Regulation (EU) 2017/746" [4]. An MDR-regulated device is outside the CRA’s product scope. The manufacturer as a company remains fully in scope for NIS2, and any non-device software it ships can still fall under the CRA — see our NIS2 vs CRA guide for manufacturers.

One caution before relying on official guidance here: MDCG 2019-16 Rev.1 still lists the relevant parallel EU legislation as the NIS Directive 2016/1148 and the GDPR [3] — and NIS2 Article 44 repealed that Directive with effect from 18 October 2024 [1]. The Commission’s own device cybersecurity guidance has not been updated for the regime that now applies, so the MDR-to-NIS2 interaction has to be assembled from the primary texts.

Role	Owns	First action after a device cyberattack
CISO / IT security manager	Detection, containment, evidence, indicators of compromise	Establish which devices lost function, not just which data moved — that determination drives the MDR question
Compliance officer / legal	The 24h / 72h / 1-month NIS2 filings and the GDPR assessment	Start the 24-hour clock at first employee awareness, not at confirmation
Clinical engineering / biomedical	The device estate and the vendor relationship	Notify each affected manufacturer in writing, with a timestamp — their MDR clock cannot start until you do
Device manufacturer (as supplier)	MDR Art. 87 vigilance, FSCA, Art. 88 trend reporting	Assess against Art. 2(65); file within 15 / 10 / 2 days as severity dictates
Board / management body	Approval and oversight of risk-management measures	Confirm the vendor-notification step exists in the runbook before it is needed

Your First 30 Days: A Filing Checklist

Deadlines below run from the moment of awareness unless stated otherwise.

• Hour 0: Log the exact time and the identity of the first employee who became aware. This timestamp is the anchor for every subsequent deadline [6].
• Hour 0–24: Determine which devices lost or degraded function. File the NIS2 early warning, indicating whether the incident is suspected of being caused by unlawful or malicious acts and whether it could have cross-border impact [1]. See our guide to CSIRT notification forms.
• Hour 0–24 (parallel): Notify every affected device manufacturer in writing. Keep the timestamp — it is the only evidence that you started their clock.
• Hour 24–72: File the NIS2 incident notification with an initial severity and impact assessment and, where available, indicators of compromise [1]. Run the GDPR assessment separately; a NIS2 filing does not discharge it.
• Day 2–15 (manufacturer side): The vendor assesses against MDR Article 2(65) and files a vigilance report — 2 days for a serious public health threat, 10 days where there is death or unanticipated serious deterioration, otherwise 15 days [2].
• By day 30 after the 72-hour notification: File the NIS2 final report with root cause, applied and ongoing mitigations, and cross-border impact [1].
• Ongoing: Record the manufacturer’s IT-security minimum requirements from the instructions for use, mandated by MDR Annex I, section 23.4(ab) [2]. That document is supplier-supplied evidence for your Article 21(2)(d) and (e) files — see our supply chain incident response guide.

For the wider control set behind these obligations, the healthcare compliance checklist and the OT and SCADA security guide cover the segmentation and monitoring measures that keep a device incident from becoming an estate-wide one.

Frequently Asked Questions

Does a hospital have to file an MDR vigilance report?
No. MDR Article 87 places the reporting duty on manufacturers [2]. A health institution’s role is to report the suspected serious incident to the manufacturer and, per the notice required in the instructions for use under Annex I, section 23.4(z), to its national competent authority [2] — but that is not a deadline-bearing duty in the way NIS2 Article 23 is.

If the manufacturer files under MDR, does that cover our NIS2 obligation?
No. They are separate filings, by different legal persons, to potentially different authorities, on different clocks. Neither substitutes for the other, and neither substitutes for a GDPR notification.

Our device was attacked but no patient was harmed. Is it still reportable?
Potentially, on both counts. MDR Article 2(65) covers incidents that "might have led or might lead to" harm [2], and NIS2 Article 23(3) covers incidents "capable of causing" disruption or damage [1]. Both tests are forward-looking.

What if we are uncertain whether it qualifies?
On the manufacturer side, MDR Article 87(7) requires a report to be submitted anyway where reportability is uncertain [2]. On the NIS2 side, Article 23(1) provides that "the mere act of notification shall not subject the notifying entity to increased liability" [1].

Do these obligations differ between EU member states?
Yes for NIS2 — it is a directive transposed into national law, so significance guidance, portals and forms vary. The MDR is a regulation and applies directly, though the competent authority receiving a vigilance report is still national.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Directive (EU) 2022/2555 (NIS2) — EUR-Lex. Articles 23, 34; Annex I point 5; Annex II sector 5(a).
2. Regulation (EU) 2017/745 on medical devices (MDR) — EUR-Lex. Articles 2(64), 2(65), 87, 88; Annex I sections 17.2, 17.4, 23.4(z), 23.4(ab).
3. MDCG 2019-16 Rev.1, "Guidance on Cybersecurity for medical devices" — Medical Device Coordination Group, European Commission. Section 5.2 and Annex II.
4. Regulation (EU) 2024/2847 (Cyber Resilience Act) — EUR-Lex. Article 2(2).
5. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex. Articles 1 and 3.
6. "#nis2know: NIS-2-Meldepflicht" — Bundesamt für Sicherheit in der Informationstechnik (BSI), bsi.bund.de.
7. "Checking-up on Health: Ransomware Accounts for 54% of Cybersecurity Threats" — ENISA.
8. Guidelines 9/2022 on personal data breach notification under GDPR, Version 2.0 — European Data Protection Board.