The CRA Exemption for Medical Devices Is Narrower Than You Think
TL;DR: Your MDR- or IVDR-regulated medical device is exempt from the Cyber Resilience Act. The companion app, cloud backend, and OTA update infrastructure around it probably are not. Classify every software component in your ecosystem separately - and get a supplier vulnerability-reporting process in place before 11 September 2026.
If you manufacture connected medical devices, you've likely heard the reassuring headline: medical devices are exempt from the CRA. That's true, as far as it goes. Article 2 of Regulation (EU) 2024/2847 excludes products already covered by sector-specific EU rules with equivalent cybersecurity requirements, and MDR/IVDR qualifies.
The problem is what manufacturers do next: they assume the exemption covers everything they ship. It doesn't.
The CRA exemption applies to the regulated medical device itself - not to companion apps, cloud dashboards, or OTA update servers that sit around it. As L4B Software puts it plainly: your device may be exempt; your ecosystem is not.
This post gives you a practical framework for classifying each component in your connected-health product stack - and tells you what to do about the ones that are in scope.
Why the exemption is narrower than it looks
The MDR/IVDR exemption is product-specific, not manufacturer-specific. It covers the product that bears the CE mark under those regulations. Anything you place on the market as a separate product - even if it only makes sense alongside the device - gets evaluated on its own terms.
Software that accompanies a medical device but is not itself a medical device - such as hospital IT integration platforms, data analytics dashboards, or device configuration tools - falls under the CRA. The exemption applies only to products that are medical devices or IVDs; companion apps, wellness products, standalone software tools, and components sold separately may still fall under the CRA.
General-purpose software or hardware that is also used in medical settings but is not a certified medical device still falls under the CRA. The exemption only applies to products bearing the CE mark under MDR/IVDR.
One more thing worth noting: even under the current CRA exemption, medical device wearables (body-worn devices) must fulfil CRA requirements. If your device is worn on the body, check this carefully - the exemption may not apply at all.
A component-by-component classification framework
Work through your product ecosystem one layer at a time. The question for each component is the same: Is this itself a regulated medical device, or a separate product with digital elements?
The regulated device itself
If it carries a CE mark under MDR (Regulation (EU) 2017/745) or IVDR (Regulation (EU) 2017/746), it is out of CRA scope for product requirements. This is the straightforward case. Your MDR technical file, post-market surveillance plan, and Annex I general safety and performance requirements (GSPRs) remain your primary cybersecurity framework for the device.
The companion app
This is where most manufacturers make their first mistake. The key questions are:
- Is the app itself classified as a medical device or SaMD under MDR? If yes, and it's covered by the same CE mark or a linked CE mark, it may share the exemption. If it's a general wellness or patient-engagement app that doesn't meet the MDR definition of a medical device, it doesn't.
- Is it placed on the market separately? If users download it from an app store as a distinct product, it is almost certainly a separate "product with digital elements" for CRA purposes.
If your company sells medical devices and consumer health apps, wellness trackers, fitness products, or other non-medical digital products, those non-medical products fall fully under the CRA. A company that sells both a Class II medical device (MDR) and a companion wellness app (CRA) must comply with both regulatory frameworks.
The cloud backend / dashboard
Pure SaaS - a browser-only portal with no installable component - is generally outside CRA scope. We've explained this boundary in detail in our guide to remote data processing solutions and SaaS scope.
The analysis changes when the cloud component is a remote data processing solution (RDPS): software designed by the same manufacturer where the device cannot perform one of its intended functions without it. In that case, the backend is treated as part of the product for CRA purposes - even if it runs entirely in the cloud.
Ask yourself: if you switched off the cloud backend, would the device stop doing something it's supposed to do? If yes, that backend is likely in scope alongside the device - and since the device itself is MDR-exempt, you need to assess whether the backend is separately in scope as its own product with digital elements.
OTA update infrastructure
Over-the-air update servers and infrastructure are not themselves regulated as medical devices and can fall squarely into CRA scope as products with digital elements. The CRA regulates products with digital elements - including companion apps, cloud services, and update infrastructure that aren't classified as medical devices. If your update server is a distinct, separately operated component, classify it separately.
One product boundary, one classification. Don't classify your whole ecosystem at once. List every software component you place on the market or operate on behalf of customers. Classify each one individually against the three questions: (1) Is it MDR/IVDR CE-marked? (2) Is it placed on the market as a distinct product? (3) Is it an RDPS integral to a product's function? Only then decide whether CRA applies.
The supply-chain interaction point you can't ignore
Even if your finished device is fully MDR-exempt, the CRA reaches you through your software supply chain.
Components within medical devices - operating systems, microcontrollers, communication modules, software libraries - may be sold as standalone products with digital elements. If a component supplier sells the same component both to medical device manufacturers and to non-medical device makers, the standalone component falls under the CRA. This means medical device manufacturers may need to request CRA-compliant SBOMs and vulnerability information from their suppliers.
Here's the practical consequence: from 11 September 2026, any in-scope supplier in your software supply chain must report actively exploited vulnerabilities to ENISA within 24 hours (early warning), 72 hours (detailed notification), and submit a final report within 14 days. Article 14 of the CRA requires manufacturers to report actively exploited vulnerabilities to ENISA within 24 hours (early warning), 72 hours (notification), and 14 days (final report). This applies from 11 September 2026 - 18 months before the full regulation.
When a supplier reports an actively exploited vulnerability in a component you use, you need a process to receive that report, evaluate its impact on your device, and act on it - to satisfy your own MDR post-market surveillance obligations. That process needs to be operational before September 2026.
The regulatory horizon: an evolving picture
The current MDR/IVDR exemption from the CRA may not be permanent. Watch this space carefully - but don't treat any of the following as settled law.
In December 2025, the European Commission published a proposal to amend MDR and IVDR that would remove the CRA exemption for medical devices entirely. Under this proposal, cybersecurity would be explicitly added to the general safety and performance requirements (GSPR) in Annex I of the MDR and IVDR, and medical devices would no longer be excluded from the CRA. The proposal also introduces new obligations for medical device manufacturers to report actively exploited vulnerabilities and severe cyber incidents to national CSIRTs and ENISA - mirroring CRA Article 14 requirements. This is a Commission proposal, not yet adopted. It requires European Parliament and Council approval, which typically takes 12-24 months.
The European Commission officially presented the proposal on 16 December 2025, and it is currently moving through the EU legislative process. The proposal was presented to the European Parliament's Public Health (SANT) Committee in April 2026, where it received broad political support. The proposal must still be formally adopted by both the European Parliament and the Council before the new measures become applicable. Adoption is currently expected in 2027.
Separately, the AI Act interface with MDR/IVDR is also in flux. The Council of the EU and the European Parliament agreed in the so-called AI Omnibus on 7 May 2026 that the MDR and IVDR shall not be moved from Section A to Section B of Annex I - the proposed broad inapplicability of the AI Act to medical devices and IVDs will therefore not be implemented. AI-enabled medical devices and IVDs thus continue to be subject to the full set of high-risk obligations. The formal adoption of the AI Omnibus is still pending.
The direction of travel is clear: cybersecurity obligations for medical device manufacturers are increasing, not decreasing - whether through CRA, MDR amendment, or both. Building robust processes now is the right call regardless of how the legislative picture settles.
Your next steps
Work through these four actions before 11 September 2026:
List every piece of software your organisation places on the market or operates on behalf of customers — companion apps, cloud portals, configuration tools, update servers, SDKs. Do not assume the MDR CE mark covers them.
If a component is downloadable, installable, or distributed independently — even if it only makes sense alongside the device — it is likely a separate product with digital elements for CRA purposes.
For each cloud or backend component: is it designed by your organisation, and would the device fail to perform an intended function without it? If yes, apply the RDPS analysis. Our plain-English guide to products with digital elements walks through this in detail.
Identify which software component and library suppliers are themselves CRA in-scope. Establish a process to receive their Article 14 reports, triage impact on your device, and feed findings into your MDR post-market surveillance system. This process must be operational by 11 September 2026.
CRA Facts is an independent plain-English guide to Regulation (EU) 2024/2847, operated by Nukipa Labs GmbH. We are not affiliated with the European Union, the European Commission, or ENISA. Nothing here is legal advice.
Related reading
ENISA Now Governs 20 CNAs as a CVE Root: What It Means for CRA-Scope Manufacturers
On 6 August 2026, ENISA announced NCIA and AISLE as new CNAs under its CVE Root, bringing its total to 20. Here's what that means - and doesn't mean - for your CRA obligations.
ETSI Opens Public Enquiry on 17 Vertical CRA Standards: What "Important" Product Makers Should Do Now
On 13 August 2026, ETSI opened the formal approval process for 17 vertical EN 304 standards covering Annex III product categories. Here's what manufacturers of VPNs, browsers, password managers, and more should do right now.
How to Generate Your First CRA-Ready SBOM: A Practical Tool Guide
Pick a format, run a generator, store the file. A hands-on guide to generating a CRA-compliant SBOM this week using cdxgen, Syft, Trivy, and Tern.