CRA vs MDR for health software: what to ask your engineering partner
Hospital CIOs, CISOs, compliance reviewers, and medtech owners are asking whether a piece of health software sits under the EU Medical Devices Regulation or the Cyber Resilience Act, and what evidence an engineering partner should be able to show.
This page answers those buyer questions. It is not legal advice and it is not a conformity assessment.
Areusdev builds and integrates software for regulated work. We are not a black-box AI vendor and we are not a law firm. We do not classify your product.
The Cyber Resilience Act complements NIS2. Supplier evidence for hospital cyber procurement is a separate question and is not covered here.
Areusdev builds and integrates the software and can sit with your reviewers on architecture, vulnerability management, and what you receive at release. That is delivery support. It is not a notified-body outcome and it is not a company certification.
Talk to an architect. For a conversation:
CRA vs MDR health software partner FAQ
What is the difference between the CRA and the MDR for health software?
The Medical Devices Regulation, Regulation (EU) 2017/745, and the In Vitro Diagnostic Regulation, Regulation (EU) 2017/746, cover products that qualify as medical devices or in vitro diagnostics, including software that meets those definitions. Those laws already include cybersecurity expectations for devices that are electronic or that are software.
The Cyber Resilience Act, Regulation (EU) 2024/2847, is a separate cybersecurity rule for products with digital elements made available on the EU market. Recital 25 says products to which the MDR or the IVDR apply should not also be subject to the CRA, because those regulations already address cybersecurity risks and conformity assessment. The CRA text, as indexed on EUR-Lex, excludes products to which the MDR, the IVDR, or Regulation (EU) 2019/2144 apply. Confirm the operative sentence in the Official Journal before anyone quotes it.
The same product is not in both regimes. A company can still have one product under the MDR and another under the CRA. Coverage is product by product. One MDR device does not take a vendor out of the CRA.
Official starting points: the Commission CRA page and Regulation (EU) 2024/2847 on EUR-Lex.
Does the CRA apply if our module is not a medical device?
It may. Non-device health software, a connected module that is not itself a device, and support software that is not a device or an accessory are the gap buyers should examine with counsel.
Whether a module is a device, an accessory, or neither is a qualification the manufacturer and their counsel make. Commission guidance MDCG 2019-11 is useful context for MDR and IVDR software qualification. It is not a CRA guide, and it is not a list of products that are always in CRA scope. Software intended only for non-medical purposes, such as invoicing or staff planning, does not qualify as medical device software under that guidance. That fact alone does not decide CRA scope.
Areusdev records the assumption you and your counsel give us and builds to it. We do not issue the qualification. This page also does not draw a line between software components inside one device and a separate product placed on the market. That split stays with counsel.
What should we ask a health software partner about SBOM, vulnerabilities, and updates?
Ask for engineering evidence, not a compliance certificate.
Ask for a scope map: which products or modules in this engagement you believe are MDR or IVDR devices, and which are separate products with digital elements that may be in CRA scope. The partner documents the assumption. Counsel owns the decision.
Ask for a maintained component inventory, often delivered as an SBOM, including what changes when a dependency changes. This page does not cite a CRA annex for that request. It is a buyer question.
Ask how vulnerabilities are found, triaged, fixed, and retested before release, and how that sits in discovery, build, test, release, and support.
Ask how long security updates are provided, who ships them, and what you receive when a fix goes out.
That package does not mean the partner has made you CRA compliant. For how Areusdev approaches security work, see Cybersecurity solutions. For the wider partner questionnaire, see questions to ask an AI or software partner.
What changed for the CRA on 11 September 2026?
Manufacturer reporting started for in-scope products. The main CRA obligations did not.
The CRA entered into force on 10 December 2024. From 11 September 2026, manufacturers must notify actively exploited vulnerabilities and severe incidents that affect the security of their product with digital elements. The Commission timeline is an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report no later than 14 days after a corrective measure is available for an actively exploited vulnerability, or within one month of the 72-hour notification for a severe incident. The report is filed once, through the ENISA CRA Single Reporting Platform. The Commission ties that platform to Article 16 of the CRA.
The main obligations apply from 11 December 2027. Do not read the September 2026 date as CRA CE marking already being in force.
Areusdev does not file that manufacturer report. Who places the product on the market is a legal fact for you and your counsel. The partner question is whether vulnerability handling, customer notice, and engineering evidence are in the delivery.
Source: the Commission page on CRA reporting.
Can the MDR and the CRA both matter on one program?
Yes, across different products or modules. No, as two regimes on the same product that is already fully covered by the MDR or the IVDR.
A hospital program or a medtech program can include a device and a separate non-device product. Each one needs its own qualification. An engineering partner should be able to show which assumption each module was built under. The partner should not collapse the program into one badge.
Will Areusdev make us CRA compliant?
No. Areusdev is an engineering partner. We can design, build, and integrate software with component transparency, vulnerability handling, and update support under your governance. We can work with your security and compliance reviewers on architecture and release evidence.
We do not give legal advice, we do not classify your product, and we do not certify CRA or MDR conformity. A contract with Areusdev does not make a product CRA compliant.
Start with the due diligence questions, or contact us. Sector context for healthcare delivery is on Healthcare technology. That page is not proof of CRA or MDR status.