CRA or MDR? Which cybersecurity regime applies to your health software

The answer depends on the individual product and its intended purpose - not on whether the company calls itself healthtech. Medical device software follows the MDR or IVDR route. Non-medical connected software may fall under the CRA, but only after it passes the CRA's own product and market-supply tests.

The Cyber Resilience Act does not automatically apply to every healthtech product containing software. It also does not exempt an entire company merely because one of its products is a medical device.

If the EU Medical Device Regulation (MDR) or In Vitro Diagnostic Medical Device Regulation (IVDR) applies to a product, that product is excluded from the Cyber Resilience Act (CRA). If neither medical-device regulation applies, the product may fall under the CRA - but only if it is a product with digital elements made available on the EU market in the course of a commercial activity.

A single European healthtech company can therefore operate medical device software, a connected wellness product and an administrative platform under different regulatory routes. The correct classification follows the product or module, not the company name, code repository or sales team.

The short answer

The key distinction is simple but often missed: not being a medical device does not automatically place software inside the CRA. The CRA has its own scope conditions.

Why the boundary is difficult in modern healthtech

A healthtech platform rarely consists of one neatly bounded application. It may include a patient app, clinician portal, clinical algorithm, workflow module, cloud backend, APIs and analytics dashboard. One function may have a medical purpose while another handles communication, storage, administration or general wellness.

The June 2025 revision of the European Commission's software qualification guidance addresses this directly. For modular medical device software, each module needs a clear intended purpose and its dependencies should be communicated and justified. That makes product architecture part of the regulatory analysis, not merely an engineering detail.

What the Cyber Resilience Act covers

The CRA is a horizontal EU product-security regulation. It applies to hardware and software products made available on the EU market where the intended purpose or reasonably foreseeable use includes a direct or indirect connection to a device or network. It can cover finished products and components supplied separately, whether supplied for payment or free of charge as part of a commercial activity.

In healthtech, CRA scope may include connected wellness applications, patient-engagement products without a medical intended purpose, healthcare workflow software, consumer wearables, commercially supplied software components and connected hardware that is not regulated as a medical device.

The CRA does not turn every cloud or professional service into a regulated product. A manufacturer-operated backend can, however, form part of a CRA-covered product when it is a remote data processing solution: processing or storage without which the product could not perform one of its functions. The Regulation gives the example of a mobile app that requires access to a manufacturer-provided API or database.

What the MDR and IVDR cover

Software falls under the MDR or IVDR when it meets the definition of a medical device or in vitro diagnostic medical device. The decisive factor is its intended purpose, as shown by the label, instructions for use, promotional materials, sales statements and clinical or performance evaluation.

Software may qualify when it analyses or interprets information for diagnosis, prevention, prediction, prognosis, monitoring or treatment of an individual patient. Software that only stores, transfers or displays data, manages schedules, supports administration or provides general wellness advice does not become a medical device merely because it is used in healthcare or processes sensitive data.

Where the MDR or IVDR applies, Article 2(2) of the CRA excludes that product from CRA scope. The manufacturer still has substantial cybersecurity obligations, but they are handled through medical-device quality management, risk management, software lifecycle controls, verification and validation, post-market surveillance and vigilance. IEC 81001-5-1 is often used to structure the secure software lifecycle for MDR- and IVDR-regulated products.

A practical product-level decision framework

1. Define what is actually supplied

Start with the product the customer or user receives, rather than an internal platform name. Record the legal manufacturer, product version, users, deployment model, enabled modules, hardware, mobile and web apps, APIs, cloud dependencies and separately supplied components.

Do not treat a platform as indivisible unless that matches how it is marketed, contracted, deployed and technically operated.

2. Write the intended purpose in operational language

For each product or potentially independent module, state who uses it, what data it receives, what it does with that data, what output it produces and how that output affects a clinical or non-clinical decision. Review the website, demonstrations, tenders and sales decks as well as formal regulatory documents. A claim that software "detects deterioration" can create a different regulatory position from a claim that it merely displays trends.

3. Test MDR or IVDR qualification first

Ask whether the software has a medical purpose of its own, provides information for decisions concerning an individual patient, processes medical information beyond simple storage or communication, is driven by IVD data, or drives or directly assists a medical device. If the answer supports qualification, continue with the relevant MDR or IVDR classification and conformity assessment.

The resulting risk class does not change the CRA exclusion. The exclusion follows the application of the MDR or IVDR, not whether the device is Class I, IIa, IIb, III, A, B, C or D.

4. Apply the CRA test to what remains

For software outside the MDR and IVDR, determine whether it is a product with digital elements, supplied for distribution or use on the EU market in a commercial activity, and connected directly or indirectly to a device or network. Also identify the company's role as manufacturer, importer, distributor or another regulated economic operator.

A free product can still be commercial. Open-source software requires a separate analysis because non-monetised open-source development and open-source stewards follow specific CRA rules.

5. Map shared components and remote services

If a patient app cannot perform a core function without a manufacturer-operated API or database, assess the app and that remote processing together. If an MDR-regulated algorithm shares authentication, hosting or messaging components with a non-medical product, document which services support each product. A shared codebase does not create one shared regulatory status.

CRA and MDR/IVDR compared

Five healthtech examples

Clinical decision-support software

A platform analyses individual patient data and recommends whether a clinician should escalate treatment. If that output is intended to support diagnosis, monitoring, prediction, prognosis or treatment, the software is likely to require MDR qualification and classification. Once the MDR applies, the product is excluded from the CRA.

IVD interpretation software

Software analyses laboratory results and produces patient-specific diagnostic information. Where the intended purpose is substantially driven by data obtained from in vitro diagnostic devices, the IVDR may apply. Merely receiving laboratory data is not enough; the purpose of the analysis and the role of the output remain decisive.

Connected wellness application

A consumer app tracks sleep, exercise and nutrition and provides general lifestyle recommendations without medical claims. It will not normally qualify as medical device software for that reason alone. If commercially supplied in the EU and connected to a phone, wearable, API or network, it may fall under the CRA. GDPR may also apply, but it does not replace CRA product-security obligations.

Hospital workflow platform

A platform schedules appointments, manages administrative workflows and transfers documents without interpreting medical information or influencing patient-specific clinical decisions. Hospital use does not make it a medical device. Depending on how it is supplied and connected, it may be within CRA scope.

A platform with regulated and non-regulated modules

A company supplies a clinical risk-scoring module, an appointment module, patient messaging and shared authentication. The risk-scoring module may be governed by the MDR, while the administrative and messaging products require separate CRA assessments. Authentication may be part of several products or a separately supplied component. The defensible answer comes from a documented product map, not from labelling the entire platform "MDR" or "CRA".

What changes under the CRA

For CRA-covered products, manufacturers need a product-security lifecycle capable of meeting the essential cybersecurity and vulnerability-handling requirements. These include risk assessment, secure-by-default design where applicable, access control, protection of confidentiality, integrity and availability, security testing, vulnerability handling, security updates, technical documentation and a coordinated vulnerability disclosure process.

The CRA explicitly requires manufacturers to identify and document product components and vulnerabilities, including an SBOM in a commonly used, machine-readable format covering at least top-level dependencies. The support period must normally be at least five years unless the expected use period is shorter, and the basis for that period must be documented.

The applicable conformity-assessment route depends on the product category. Products that are not categorised as important or critical can generally use internal control, while specified important or critical products can require stricter procedures.

The transition rule that product teams should not miss

The general CRA requirements apply from 11 December 2027, but Article 69 creates an important distinction for existing products. A product with digital elements placed on the market before that date becomes subject to the full CRA requirements only if it undergoes a substantial modification from 11 December 2027 onward.

Article 14 reporting is different. Its obligations apply to all CRA-covered products, including products placed on the market before 11 December 2027. Manufacturers therefore cannot postpone reporting readiness on the assumption that an older product is outside the transition.

CRA reporting from 11 September 2026

From 11 September 2026, manufacturers of CRA-covered products must report actively exploited vulnerabilities and severe incidents affecting product security. The early warning is due within 24 hours of awareness, followed by a fuller notification within 72 hours.

For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, it is due within one month. Reporting takes place through the CRA Single Reporting Platform and is addressed to the relevant CSIRT, with ENISA also receiving the information unless exceptional circumstances apply.

This is not a requirement to report every vulnerability. The statutory triggers are actively exploited vulnerabilities and severe product-security incidents. Other vulnerabilities still need to be received, triaged, remediated and documented through the wider vulnerability-management process.

How medical-device reporting differs

A medical device excluded from the CRA does not use Article 14 reporting for that product. The manufacturer applies MDR or IVDR post-market surveillance and vigilance instead.

Under the MDR, serious incidents must generally be reported no later than 15 days after awareness. A serious public-health threat must be reported no later than two days; death or an unanticipated serious deterioration in health must be reported no later than ten days. A cybersecurity event enters vigilance when it meets the serious-incident criteria or leads to a field safety corrective action. Other vulnerabilities may still require investigation, remediation, trend monitoring and customer communication.

One event can create several assessments. A compromise involving patient data and a shared software component may require separate consideration under CRA or medical-device vigilance, GDPR, NIS2 or national law, and customer contracts. The triggers and deadlines should not be collapsed into one generic incident form.

A practical operating model for mixed portfolios

The most reliable model is one shared product-security capability with regime-specific decision branches. Engineering and security teams can operate common processes for vulnerability intake, dependency monitoring, secure development, security testing, incident investigation and remediation. Regulatory owners then determine which product is affected and which reporting or conformity route applies.

1. Maintain a product-regime register. For every product and material module, record the intended purpose, MDR or IVDR status, CRA status, legal manufacturer, markets, responsible owners, reporting route and the reasoning supporting the conclusion. Review it when claims, architecture, distribution or functionality change.
2. Create one triage entry point. Support tickets, researcher reports and engineering alerts should reach a shared triage process quickly. The process then distinguishes actively exploited vulnerabilities, severe CRA incidents, medical-device serious incidents, personal data breaches and contractual notifications.
3. Make the reporting clock operational. Define what "becoming aware" means in practice, who can confirm it and who can authorise a report. Prepare templates for the 24-hour warning, 72-hour notification, final reports and documented non-reporting decisions.
4. Reuse technical evidence without confusing the regimes. Architecture, data flows, SBOMs, threat models, security tests, patch procedures and release records can support several obligations. Their regulatory interpretation still differs. Medical-device evidence must connect security with safety, intended purpose and device risk management; CRA evidence must demonstrate conformity with the CRA product-security and vulnerability-handling requirements.

The Netherlands and Germany: the product-law boundary stays European

The CRA, MDR and IVDR are EU product rules, so the core classification test is the same when a product is supplied in the Netherlands or Germany. National and customer requirements add another layer but do not turn non-medical software into a medical device or remove a CRA obligation.

For example, a Dutch hospital may require NEN 7510-aligned evidence during procurement. A German hospital or market-access route may impose its own security and documentation expectations. Those requirements matter commercially and operationally, but they should be recorded separately from the CRA-versus-MDR classification decision.

Common classification mistakes

"We are a medical-device company, so the CRA does not apply." The exclusion follows the individual MDR- or IVDR-regulated product, not the company.

"The product processes patient data, so it is a medical device." Health data can trigger privacy duties, but medical intended purpose and functionality decide device status.

"It is not a medical device, so the CRA definitely applies." The software must still pass the CRA product, connectivity and market-supply tests.

"Our formal intended-purpose statement avoids medical claims." Websites, sales materials, demonstrations and tenders also form part of the intended-purpose evidence.

"ISO 27001 is enough for either route." ISO 27001 can support organisational security, but it does not determine product scope or replace product-specific conformity evidence.

Conclusion

The CRA-MDR boundary is not a choice between two convenient compliance programmes. It is a product-level classification exercise that begins with intended purpose and continues through architecture, distribution and regulatory role.

For European healthtech companies, the defensible outcome may be a mixed portfolio. That is normal. The real risk is applying one label to the entire company and leaving individual products, modules, remote services or reporting duties unexamined. The European Healthtech Compliance Calendar tracks the CRA, MDR, IVDR and related deadlines relevant to this analysis.

Editorial note. This article provides general information and is not a substitute for a product-specific legal or regulatory assessment. Recheck current CRA implementation guidance and reporting infrastructure immediately before relying on the dates and reporting mechanics described above.