A connected medical device today rarely consists of just the device itself. Companion app, cloud portal, service tool, supplier components — a different legal framework can apply to each of these parts.
We'll go into this in more depth on 22 September at the Health Electronics Summit in Stuttgart. If you're attending, we'd be glad to see you there.
Two Laws for One Product
The Medical Device Regulation (MDR, Regulation (EU) 2017/745) asks whether a device or a software function serves a medical purpose. Diagnosis, monitoring, treatment. What's assessed is clinical safety and performance, not IT security.
The Cyber Resilience Act (CRA), by contrast, requires a minimum level of cybersecurity across the entire lifecycle for all "products with digital elements" that can connect to a network. We've already summarised the specific deadlines, obligations and fines elsewhere CRA: Obligations, Deadlines and Fines. Here, we want to answer the question that piece leaves open: what happens when a product has to satisfy both frameworks at once?
Art. 2(2) CRA exempts products "to which the MDR applies." That sounds like a clean dividing line, but it isn't an exemption for the whole product — only for the part that is actually certified as a medical device. For a connected device, that's usually just the device itself, including its embedded software. The companion app (if it has its own medical purpose), the cloud portal, the service tool, and components from suppliers all remain subject to the CRA. Anyone relying on the MDR exemption has often covered only a small part of their overall system landscape.
Where the Two Frameworks Overlap
Despite their different legal basis, MDR and CRA demand largely the same thing at several points:
| Topic | MDR | CRA |
| Secure delivery | Annex I, Section 17 | Annex I, Part I |
| Risk across the lifecycle | Risk management under MDCG 2019-16 | Art. 13 |
| Monitoring and reporting | reporting Vigilance system, reporting to authorities such as BfArM | Art. 14, reporting obligation since 11 September 2026 |
| Proving what's inside | Technical documentation | Software Bill of Materials, from December 2027 |
A word on a distinction that's often confused: Art. 14 CRA governs the 24- and 72-hour reporting of actively exploited vulnerabilities. Art. 64 governs fines — up to 15 million euros or 2.5 percent of global annual turnover. Both are covered in detail in the linked fundamentals article; here, the focus stays on the MDR connection.
What the MDR Already Requires on Cybersecurity
Even without any CRA connection, the MDR itself already demands IT security measures. Annex I, Section 17.4 requires manufacturers to define minimum requirements for hardware, IT network characteristics, and protection against unauthorised access. Section 18.8 adds requirements for embedded systems.
The MDCG 2019-16 guidance from the European Commission makes this more concrete: secure design, risk management across the product lifecycle, documentation of cybersecurity features, and post-market surveillance. And there is now a standard that translates these fairly general requirements into a verifiable process: IEC 81001-5-1, long established in the industry as the de facto benchmark for MDR cybersecurity evidence.
Cybersecurity in medical technology, in other words, isn't a topic that starts with the CRA in 2027. It has been part of MDR approval for far longer.
Baxter Life2000: the debug port that should never have been open
The Life2000 is a ventilator for patients who cannot breathe on their own — a device whose failure is life-threatening. During internal security testing, Baxter found several vulnerabilities at once: a debug port on the serial interface that was active by default and received unencrypted messages; hard-coded credentials in the code; and no check to confirm that uploaded firmware actually came from Baxter before it was executed. CISA rated the vulnerability, CVE-2024-48973, with a CVSS v4 score of 10.0 — the highest possible value.
Anyone with physical access to an unattended device could alter therapy settings or access device data. For a ventilator, in the worst case, that means life-sustaining airflow no longer works as intended. Baxter reported no known incidents of patient harm at the time of the recall notice. What matters is the response: Baxter didn't opt for a firmware update, but for permanently removing the entire product line from the market. More than 4,800 devices worldwide had to be removed. FDA Class I, the highest risk category, November 2025.
The reason for this drastic decision lay precisely in the combination of vulnerabilities. An open debug port alone would be a configuration error. Combined with hard-coded credentials and a missing integrity check for firmware updates, the result was an attack path that couldn't be closed with a single patch without rebuilding the entire trust chain for firmware distribution.
Medtronic MiniMed/Paradigm: the insulin pump that trusted every command
MiniMed and Paradigm insulin pumps communicate wirelessly with blood glucose meters, sensor transmitters, and a USB receiver. Security researchers found in 2019 that this wireless protocol did not verify who a command actually came from. Any device with matching equipment within radio range could theoretically inject, alter, or intercept commands — and thereby influence insulin delivery. CISA assigned CVE-2019-10964, with a CVSS score of 7.1.
An attacker needed more than just radio range, though: the specific pump's serial number, matching radio equipment, and technical expertise. The FDA confirmed that it was not aware of any actual cases of misuse at the time of the warning. The theoretical risk was nonetheless serious, because manipulated insulin delivery is dangerous in both directions — too much insulin can trigger hypoglycemia, too little can lead to hyperglycemia and diabetic ketoacidosis.
The actual reason for the recall wasn't the attack scenario itself, but the lack of a way to fix it. Because the pumps had no individual device identity that communication partners could use to authenticate each other, a software update alone wasn't a solution — the vulnerability was in the protocol, not in a single faulty line of code. Around 4,000 patients in the US had to be switched to a different, unaffected pump model (MiniMed 670G). FDA Class I, June 2019.
Medtronic CareLink 2090: the radio link whose range nobody knew
The CareLink 2090 is the programmer physicians use to configure and read pacemakers and defibrillators. It communicates with the implanted device via radio, using the Conexus telemetry protocol. Security researchers found that this radio link transmitted data unencrypted and without adequate access control. CISA rated the associated vulnerability, CVE-2019-6538, with a CVSS score of 9.3 — just below the maximum, because the flaw could be exploited from nearby without special expertise.
The problem wasn't in the programmer itself, but in the implanted device it communicated with. And that's exactly what made the fix so drawn out: Medtronic didn't need to patch one central device, but had to develop a firmware update for each affected pacemaker and defibrillator model individually and roll it out to thousands of patients through routine physician visits — an implanted device can't simply be updated remotely overnight. The CISA advisory was still being updated in 2021, because patches weren't yet available for all affected models at that point. (An earlier, smaller wave of vulnerabilities in the programmer itself — insecurely stored credentials, a path traversal flaw — had already been reported by the FDA in 2018, and should be considered separately from the telemetry vulnerability described here.)
The real bottleneck was the missing overview: at the start of the patch campaign, Medtronic couldn't say with certainty which implant model, running which firmware version, was actually in which patient. That version overview was missing — not because nobody wanted it, but because it wasn't systematically maintained within the existing process chain.
All three cases converge on the same point: the moment firmware is first loaded onto the chip. And in each case, one of three decisions was missed there — a secure delivery state, an individual device identity, or a version overview that still holds up years later.
All three cases also point to the same distinction that turns out to matter legally: it's not just about what happened, but about whether the programming process itself could have been tampered with without anyone noticing.
The Burden of Proof Is Shifting
The new Product Liability Directive (EU) 2024/2853 must be transposed into German law by December 2026, and it shifts the burden of proof against manufacturers. Under Art. 10(2), a product's defectiveness is presumed if the defendant fails to disclose relevant evidence, if the claimant demonstrates that binding safety requirements were not met, or if there was an obvious malfunction during normal use.
Manufacturing a component can be outsourced. What happened to that component before it left the factory still has to be proven by the manufacturer — in court, if necessary. Documentation alone isn't enough here: a complete record of a programming process that was technically vulnerable only answers half the question in a dispute. The other half is: how was the process itself protected against unauthorised changes — both in transit and during processing?
What btv SEEL® Delivers Here
At exactly the interface where something was missed in all three cases, btv SEEL® steps in — regardless of whether the affected component later falls under MDR, CRA, or both frameworks. The full functionality of CORE, INTERCONNECT and UNLIMITED is described on the btv SEEL® services page; here, just the points that matter most for medical devices.
Firmware and keys are transferred through controlled, protected data spaces using standardised encryption protocols, and decrypted exclusively in volatile memory during programming. No unencrypted temporary files ever exist on storage media — neither in transit nor during processing.
Root certificates stay entirely with the manufacturer, because the customer's own PKI infrastructure is integrated rather than key material being handed over. For firmware with a medical function, that's not a detail — it's a question of intellectual property.
And every component receives an individual, automatically documented, cryptographically signed identity in series production — down to the level of the individual packaging unit, and where the application requires it, down to the level of the individual device. That goes beyond the legal minimum: Art. 13(15) CRA only requires a type, batch, or serial number. But that's precisely the difference that, in the MiniMed case, separated a software update from the physical replacement of 4,000 devices — and that, in the CareLink case, would have determined whether Medtronic knew from the start which implant needed which patch, instead of having to find out over several years.
One point worth stating clearly: btv SEEL® doesn't make a medical device "MDR-compliant" or "CRA-compliant." These regulations address the manufacturer's end product, not the service provided by btv technologies. What btv SEEL® delivers is two things that belong together: a programming procedure that makes unauthorised changes harder along the entire path — from transfer through protected data spaces to processing exclusively in volatile memory — and the resulting, verifiable evidence at the component level. Evidence covering a vulnerable process would be of limited value in a dispute; a protected process without evidence can't be proven in an audit or recall. Together, they form the foundation manufacturers need for their own conformity assessment and in the event of a liability claim. And that evidence goes back a long way: btv documents components for at least 20 years, traceable back to 2006. For medical devices with long market cycles, that's not a footnote.
Why This Matters Right Now
Since 11 September 2026, the 24-hour reporting obligation for actively exploited vulnerabilities under Art. 14 CRA has been in force. A security incident in the connectivity, cloud, or service component of a connected medical device now has to be contained just as quickly as an incident reported through the MDR vigilance system. From December 2026, the tightened burden of proof under the Product Liability Directive adds to that.
Meeting three deadlines at once, without having to reconstruct firmware, batch, and certificate after the fact — that's the real difference between manufacturers who are prepared and those who only find out the hard way.
Frequently Asked Questions About MDR and CRA for Medical Devices
Yes, partly. Art. 2(2) CRA only exempts the part of a product that is actually certified as a medical device — for example, an ECG function with its own intended purpose. Companion apps without their own medical purpose, cloud portals, service tools, and supplier components remain subject to the CRA, even if the overall device carries MDR approval.
No. MDR and CRA address the manufacturer's end product, not a supplier's service. btv SEEL® delivers two things that belong together: a programming procedure that makes unauthorised changes harder during both transfer and processing, and the resulting evidence at the component level — for example on firmware version, programming timestamp, and device identity — the foundation manufacturers need for their own conformity assessment.
Art. 13(15) CRA legally requires only a type, batch, or serial number for identification. For safety-critical medical devices, that can be too coarse in practice: the MiniMed case shows how a missing individual device identity can turn what could have been a targeted software update into the physical replacement of thousands of devices.
