Article
Card image cap for article

New Proposal in the EU for Reporting of Cyber Incidents Concerning Medical Devices

Cybersecurity

3/13/2026

Introduction

The European Commission’s proposal COM(2025)1023 fundamentally changes how cybersecurity incidents for medical devices and IVDs must be reported [1].

Today, under Regulations (EU) 2017/745 (“MDR”) and IVDR 2017/746 (“IVDR”), a cyber incident becomes reportable only when it meets the definition of a “serious incident” – meaning actual or likely death, serious deterioration of health, or serious public health threat for patients, users, or other persons.

That leaves a huge blind spot: actively exploited vulnerabilities, ransomware incidents, or credential theft that compromise device security but never quite “tip over” into clinical harm.

The new Article 87a MDR / 82a IVDR [1] is designed to close this gap. Serious incidents that are also actively exploited vulnerabilities or severe security incidents – as defined in the Cyber Resilience Act (CRA) Regulation (EU) 2024/2847 – will now be made available to national Computer Security Incident Response Teams (CSIRTs) and to the European Union Agency for Cybersecurity (ENISA), via Eudamed.

In addition, medical device manufacturers must report actively exploited vulnerabilities and severe incidents that do not qualify as serious incidents under MDR/IVDR to CSIRTs and ENISA through Eudamed as well.

If passed, cybersecurity will be explicitly written into Annex I of the MDR/IVDR as part of the General Safety and Performance Requirements (GSPR), making security a first‑class regulatory objective alongside clinical safety.

What the CRA Brings to the Table

The Cyber Resilience Act (Regulation (EU) 2024/2847) is the EU’s horizontal framework for products with digital elements. It introduces lifecycle security requirements, vulnerability handling obligations, and incident reporting rules for a wide range of connected products.

Importantly, the CRA defines key concepts such as “actively exploited vulnerability” and “severe incident”, and ties them to strict reporting timelines towards CSIRT and ENISA.

Medical devices and IVDs are largely carved out from direct CRA product requirements because MDR/IVDR is special. But they are not carved out from the broader EU cybersecurity ecosystem: healthcare operators fall under Network and Information Systems NIS-2 [2], suppliers are part of critical chains, and CRA’s incident terminology has now been imported into MDR/IVDR via the new Article 87a / 82a.

In other words, even if the device is formally outside the CRA product scope, the vulnerability handling and incident reporting processes must “speak CRA” to remain interoperable with CSIRTs, ENISA and the company's NIS-2 obligations.

Why start with the CRA question in the decision tree?

The decision tree in the Title image begins with the CRA perspective and only then moves to MDR/IVDR seriousness. Conceptually, the order of questions is:

  • Is the event cybersecurity‑related at all?
  • If yes, does it meet CRA criteria as an actively exploited vulnerability or severe incident?
  • Only if yes, does it additionally qualify as a serious incident under MDR/IVDR?

There are three reasons why this top‑down CRA‑first logic is powerful:

  • It matches the new legal trigger for additional reporting. The new Article 87a/82a is not about “all serious incidents”, but specifically about those that are also actively exploited vulnerabilities or severe incidents in CRA terms. The second stream is explicitly for cyber events that never become serious incidents clinically, but still meet CRA severity thresholds. Starting with the CRA question ensures to reliably catch both buckets.
  • It decouples cyber severity from clinical harm. Under the current MDR/IVDR, a ransomware attack that was contained before it delayed treatment, or a privilege‑escalation vulnerability exploited in a test system, may never trigger vigilance because there is no “serious incident” in the classical sense. From a cyber‑operations standpoint, ignoring such events is dangerous: they can be early indicators of systemic weaknesses. CRA’s “severe incident” definition focuses on impact to availability, integrity, authenticity and confidentiality, not just clinical outcome. Asking the CRA question first forces the organisation to assess technical severity on its own merits.
  • It aligns with how SOC and IT already think. Security operations centres triage incidents by indicators of compromise, exploitation status, and impact on systems and data – not by MDR Article 2(65) vocabulary. If we lead with CRA’s “actively exploited” and “severe” notions, we can plug regulatory reporting into the existing incident classification scheme instead of bolting a medical‑device‑only layer on top. MDR/IVDR seriousness then becomes a second‑stage overlay focusing on clinical risk and public health.

Practically, this means the cyber incident handling starts with “Is this CRA‑relevant?” and only then asks “Is this also an MDR serious incident?” – not the other way round.

What MDR/IVDR were Missing in Terms of Cyber Reporting

The original MDR and IVDR contain security‑relevant obligations: Annex I requires protection against unauthorised access and safety under reasonably foreseeable misuse; there are references to software lifecycle, IT security, and state of the art. But three things were clearly missing:

  • Modern cyber terminology and roles. MDR/IVDR did not mention CSIRTs, ENISA, actively exploited vulnerabilities, or severe security incidents. As a result, most manufacturers limited formal reporting to Competent Authorities and treated cyber as an internal IT matter unless patients were affected.
  • A channel for “cyber‑only” incidents. Under the current rules, a vulnerability or intrusion without proven or likely serious clinical harm is usually not reportable as a “serious incident”. This creates a gap for systemic weaknesses, near‑misses, and campaign‑like attacks in healthcare environments. The proposed Articles 87a/82a explicitly create a reporting stream for these cyber‑only events via Eudamed to CSIRTs and ENISA.
  • Explicit integration of cybersecurity in GSPRs. While manufacturers could (and should) interpret several Annex I requirements as imposing cybersecurity controls, “cybersecurity” itself was not named as such. The proposal corrects this by explicitly referencing cybersecurity in Annex I MDR/IVDR, which regulators and Notified Bodies have welcomed as clarifying a previously fuzzy area. This is documented by the Team‑NB's Letter [3].

Until now, cyber incidents without direct patient harm often went unreported, even though they are highly relevant from a resilience and public‑health perspective.

The Decision Tree: Two Streams, One Logic

The proposed Article 87a/82a effectively creates two streams of cyber reporting for medical devices and IVDs.

Step 1 – Is the event cyber‑related?

The first filter on scope: does the event concern confidentiality, integrity, availability or authenticity of device functions or associated data? If not, it stays in classical MDR/IVDR vigilance and quality processes.

Step 2 – CRA lens: actively exploited vulnerability or severe incident?

For cyber‑related events, we apply CRA‑style criteria: is there an actively exploited vulnerability, or a severe incident that seriously impacts system availability, integrity, authenticity or confidentiality? If the answer is no, we handle it in the Information Security Management System (ISMS) and QMS and consider non‑serious MDR/IVDR reporting where clinically relevant, but there is no CSIRT/ENISA obligation.

Step 3 – MDR lens: serious incident or not?

If the answer is yes – we are dealing with an actively exploited vulnerability or a severe incident – we then ask whether it meets MDR/IVDR’s definition of a serious incident (death, serious deterioration of health, or serious public health threat).

From there, the tree splits:

  • Path A – Serious incident + cyber dimension
  • Path B – Cyber‑only event (no serious incident)

In both streams, Eudamed becomes the single reporting channel, with Competent Authorities receiving the vigilance side and CSIRTs/ENISA receiving the cyber side.

How Manufacturers Can Operationalize This

For manufacturers, the decision tree should drive tangible changes in the QMS and security operations:

  • Integrate MDR and CRA criteria in one triage workflow. The incident intake form should include fields for “cyber‑related?”, “CRA: actively exploited?”, “CRA: severe incident?”, and “MDR/IVDR serious incident?” This ensures consistent classification across vigilance and security.
  • Align timelines with the stricter clock. CRA‑style severe incidents and actively exploited vulnerabilities are typically reportable within 24–72 hours, whereas the MDR/IVDR amendment proposes a 30‑day reporting window for certain device cybersecurity events. We should design the process so that we meet the stricter of the applicable timelines.
  • Use Annex I cybersecurity as the design backbone. With cybersecurity explicitly embedded in the GSPRs, standards like IEC 81001‑5‑1, IEC 62304 and IEC 62443 become natural tools to demonstrate compliance across the lifecycle. The decision tree then becomes the post‑market “front‑end” of a much broader security‑by‑design strategy.
  • Leverage shared knowledge, not just compliance. As highlighted in various CRA‑related analyses and whitepapers [4], sharing vulnerability and incident information increases collective resilience across the healthcare ecosystem. By routing cyber‑only events to CSIRTs and ENISA, medical device manufacturers contribute to a richer threat picture that ultimately protects patients, even when no single device incident reaches the threshold of a serious incident.

Closing thoughts

The real innovation in the proposed Article 87a MDR / 82a IVDR is not another report form; it is the mindset that cybersecurity events matter even without immediate clinical harm. A CRA‑first, MDR‑second decision tree makes that mindset actionable: events are treated like a cybersecurity professional, and then layer medical‑device vigilance after that.

For leadership and regulators alike, this is what convergence between MDR/IVDR and the EU’s broader cyber strategy looks like in practice: one incident, one decision tree, two complementary views – cyber severity and clinical severity – and a single channel in Eudamed that makes sure the right authorities get the right information at the right time.

References

Go back