Blackfort Technology
CRA Insights

Cyber Resilience Act

Cyber Resilience Act and Medical Technology: the Scope Boundary

Check affectednessRequest consultation
Cyber Resilience Act and Medical Technology: the Scope Boundary

Last updated: 2026-07-18

For manufacturers in the health space, one of the first and most consequential questions about the Cyber Resilience Act (Regulation (EU) 2024/2847) is: does my product fall under it at all? The CRA explicitly excludes medical devices – but the exclusion is narrower than many assume. This page frames the boundary in technical-organizational terms. It is orientation, not a legally binding classification of your specific product.

The costliest misconception first: "My product is health-related, so it is outside the CRA" is wrong. Only products that qualify as a medical device under the MDR (Regulation (EU) 2017/745) or as an in-vitro diagnostic under the IVDR (Regulation (EU) 2017/746) are excluded. Wellness and fitness software, general health apps without a medical intended purpose, and clinic-administration and hospital IT are generally not medical devices – and therefore remain within the scope of the CRA. Never rely on gut feeling here; rely on a formal determination.

Why medical devices are excluded

The CRA is a horizontal cybersecurity regulation for "products with digital elements" (PDE). It excludes medical devices via Art. 2(2)(a) (MDR) and in-vitro diagnostics via Art. 2(2)(b) (IVDR). The rationale is to avoid double regulation: the MDR and IVDR already impose essential requirements on programmable systems, including cybersecurity – for the MDR, for example, in Annex I §17. The EU legislator therefore does not move these products into a "rule-free zone" but leaves them in a different, equally demanding regime.

Excluded does not mean duty-free. Anything under the MDR/IVDR is exempt from the CRA – but remains fully bound by the cybersecurity requirements of the MDR/IVDR. The question is not "CRA or nothing" but "CRA or MDR/IVDR".

Excluded vs. in scope

What matters is the product's intended purpose, not the market segment. The following comparison is illustrative and does not replace a regulatory classification:

Excluded from the CRA (under MDR/IVDR)Within CRA scope (not a medical device)
Software with a medical intended purpose under the MDR (e.g. diagnostic, therapy, findings software)Wellness, fitness and lifestyle software without a medical intended purpose
In-vitro diagnostics and their associated software under the IVDRGeneral health apps that are not a medical device
Programmable medical devices placed on the market as a medical deviceHospital and practice administration IT (billing, scheduling, resources)
Accessories that are themselves classified as a medical device / IVDGeneral IT infrastructure, network components, wearables without a medical intended purpose

The right-hand column is the heart of the misunderstanding: these products are "health-adjacent" but precisely not medical devices – and thus ordinary PDEs under the CRA. Whether a specific product sits left or right is a classification question that must be examined individually.

A decision structure for your product

1. Examine the intended purpose

Does the product, by its intended purpose, meet the definition of a medical device (MDR) or an in-vitro diagnostic (IVDR)? Only if yes does the exclusion under Art. 2(2)(a)/(b) apply. This classification is the actual pivot of the whole question.

2. Separate components and accessories

The PDE assessment is product-based (Art. 3(1)) and covers components placed on the market separately. An accessory or standalone component not itself classified as a medical device can be a PDE in its own right within CRA scope – even if the main product falls under the MDR.

3. Weigh integral cloud/backends

Integral remote data processing (Art. 3(2)) – a backend without which a product function would not run – is treated as part of the PDE under the CRA. For MDR/IVDR products, the respective regime governs accordingly. The allocation must be documented cleanly for each component.

4. Resolve mixed portfolios

Many providers have a portfolio of medical devices and non-medical devices. Both must be considered separately: one product may fall under the MDR, the next under the CRA. A blanket "we are medtech, so we are out" assumption does not hold.

Why the boundary is so easily misdrawn

The misjudgement usually stems from two shortcuts. First, "health-related" is equated with "medical device" – legally these are separate categories. Second, it is assumed that proximity to the MDR exempts the entire company; in reality, each product is classified on its own. Getting this wrong carries a double risk: either unnecessary CRA effort for a genuine medical device – or, more seriously, placing a product that is actually subject to the CRA on the market without CRA conformity assessment and CE marking.

The general application of the CRA – Annex I requirements, conformity assessment and CE marking – applies from 11 December 2027. Anyone operating at the medtech/IT boundary should establish the allocation on a reliable footing well before then, because conformity obligations, documentation and processes differ fundamentally depending on the regime. Whether there is any exposure at all can be structured via our scope check; for classifying CRA-relevant products, the CRA product classes provide further orientation.

Our clear recommendation: Treat the question "MDR/IVDR or CRA?" as a formal classification decision, not a gut feeling. Have the intended purpose, components, accessories and integrated backends cleanly classified and documented per product. The orientation given here does not replace such a case-by-case determination.

Frequently asked questions

Are all health apps excluded from the Cyber Resilience Act?+
No. Only products qualifying as a medical device under the MDR (Regulation (EU) 2017/745) or as an in-vitro diagnostic under the IVDR (Regulation (EU) 2017/746) are excluded – via Art. 2(2)(a) and (b). Wellness, fitness and general health apps without a medical intended purpose are usually not medical devices and therefore remain within CRA scope. Whether your specific product falls within it is a case-by-case classification. This is technical-organizational orientation, not legal advice.
What determines whether a product falls under the MDR/IVDR or the CRA?+
The decisive factor is the intended purpose, not the market segment. If the product meets the definition of a medical device or in-vitro diagnostic, the CRA exclusion under Art. 2(2)(a)/(b) applies. Otherwise it is an ordinary PDE within CRA scope. Because the classification is consequential, we expressly recommend a formal per-product determination rather than a blanket assumption.
Does the CRA exclusion mean medical devices have no cybersecurity duties?+
No. The exclusion exempts from the CRA, not from cybersecurity. The MDR and IVDR already impose cybersecurity requirements on programmable systems – for the MDR, for example, in Annex I §17. This existing regulation is precisely the reason for the CRA exclusion (avoiding double regulation). A different regime applies, not no regime.
Can part of my portfolio fall under the CRA and another part under the MDR?+
Yes, and this is common. Each product is classified on its own. A product placed on the market as a medical device may be excluded, while an accessory, a standalone component or a non-medical-device module from the same house is a PDE in its own right within CRA scope. A blanket portfolio assumption does not hold; the allocation must be handled per product and component.
By when must the boundary be clarified?+
The general application of the CRA, with Annex I requirements, conformity assessment and CE marking, applies from 11 December 2027. Because conformity obligations, documentation and processes differ fundamentally depending on the regime, the MDR/IVDR-vs-CRA allocation should be reliably clarified well before then. We recommend not waiting until shortly before the deadline – and having the classification formally documented.

Sources

This content provides general technical and organizational information on the Cyber Resilience Act (Regulation (EU) 2024/2847) and does not constitute legal advice (no legal services within the meaning of the German RDG).