It is 2026 and everyone is talking about the Cyber Resilience Act (CRA). The Cyber Resilience Act is new and it is big. Digital products have to meet strict cyber security obligations: report vulnerabilities, deliver updates, and do so across the entire product lifetime. This affects almost every industry.
So the question arises: Does the CRA also apply to (software) medical devices under the MDR and IVDR?
In this article we give clear, conclusive answers to this and other questions:
- What does the Cyber Resilience Act (CRA) regulate?
- Does the CRA apply to MDR and IVDR products?
- Which cyber security requirements do medical devices have to meet instead?
- When does the CRA affect you anyway?
- Outlook: the MDR revision brings the CRA logic into medical device law
- Our conclusion
1. What does the Cyber Resilience Act regulate?
The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. The first obligations apply as early as 11 September 2026.
➡ Text of the Cyber Resilience Act: Link to the Cyber Resilience Act
The CRA is a horizontal regulation. It sets cyber security requirements for “products with digital elements”, which means it covers software and hardware with a software component across all industries.
But not every software product falls under the CRA. According to Article 2(1), the regulation applies to products whose intended purpose or reasonably foreseeable use “includes a direct or indirect logical or physical data connection to a device or network”. Connectivity is therefore the decisive criterion.
Conformity is demonstrated through the CE marking. What is required are essential cybersecurity requirements, a conformity assessment, technical documentation and the handling of vulnerabilities across the lifecycle.
Three categories, and almost everything lands in the first one
Whether a product is moved up a category depends on two criteria: does it itself perform a function that is critical to the cybersecurity of other products, networks or services, or could a disruption significantly affect many other products or the health and safety of its users?
- Default category: everything that is not listed in Annex III or IV. Here internal control is sufficient, without any involvement of a notified body. Estimates assume that around 90 percent of all products land here.
- Important, class I (Annex III): operating systems, password managers, identity management, browsers, VPN, routers, smart home products with security functionalities, and expressly also wearable products for health monitoring that are not covered by the MDR or IVDR. Self-assessment remains possible, but only if you fully apply harmonised standards, common specifications or a certification scheme. Otherwise a notified body comes into play.
- Important, class II (Annex III): hypervisors and container runtime systems, firewalls, intrusion detection and prevention systems, tamper-resistant microprocessors. Here a third party is always involved, because pure self-assessment is not an option.
- Critical (Annex IV): hardware devices with security boxes, smart meter gateways and smartcards including secure elements. Here a European cybersecurity certification scheme applies, as far as the Commission prescribes one for the category.
In practice this means: a portal, a dashboard or a pure software application usually lands in the default category and is not checked by anyone in advance.
Two dates are particularly relevant
- 11 September 2026: the reporting obligations apply. Actively exploited vulnerabilities and severe incidents have to be reported to the European Union Agency for Cybersecurity (ENISA) and to the national Computer Security Incident Response Teams (CSIRTs).
- 11 December 2027: full application, meaning essential cybersecurity requirements, conformity assessment, CE marking and technical documentation
Key dates and deadlines of the Cyber Resilience Act (CRA)
2. Does the CRA apply to MDR and IVDR products?
This is a question that medical device manufacturers ask us regularly. The answer is very clear: no.
Article 2(2) of the CRA expressly excludes medical devices and in vitro diagnostics from its scope:
“This Regulation does not apply to products with digital elements to which the following Union legal acts apply: (a) Regulation (EU) 2017/745; (b) Regulation (EU) 2017/746; (c) Regulation (EU) 2019/2144.”
Regulation (EU) 2017/745 is the MDR, Regulation (EU) 2017/746 the IVDR. Products that fall under either of these two regulations are therefore not covered by the CRA.
Important for understanding this: the legislator did not want to give medical devices special treatment. The goal was to avoid double regulation. Recital 25 of the CRA says so itself:
“Those Regulations address cybersecurity risks and follow particular approaches that are also addressed in this Regulation. […] Products with digital elements to which either of those Regulations apply should not therefore be subject to this Regulation.”
The reasoning is therefore that medical devices are already subject to comparable cyber security requirements.
In practice this means for you: no second conformity assessment procedure, no second CE marking alongside the one from the MDR or IVDR, no classification of your product into a CRA product class.
Careful: the exclusion attaches to the product, not to the company. It says nothing about the other products in your portfolio and nothing about obligations that apply to you as a company. More on this in chapters 3 and 4.
3. Which cyber security requirements do medical devices have to meet instead?
The exclusion means not less work, only a different legal basis.
Manufacturers of (software) medical devices under the MDR and IVDR already carry extensive obligations in the area of cyber security. These do not come from the Cyber Resilience Act, but from the MDR (or IVDR) and other laws or standards.
Requirements specific to medical devices under the MDR & IVDR
Arguably the most central legal basis in the MDR for information security is Annex I, Chapter II, Section 17 of the MDR on electronic programmable systems. Section 17.1 requires that such devices be designed to ensure repeatability, reliability and performance in line with their intended use. In the event of a single fault condition, appropriate means have to be adopted to eliminate or reduce as far as possible consequent risks or impairment of performance. The section that matters most for cybersecurity is 17.2:
“For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.”
Section 17.4 additionally requires you to set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access. In the IVDR, the corresponding provisions are in Annex I, Chapter II, Section 16, with IT security in Section 16.4.
That also describes the problem: the annex remains very vague and unspecific. It does require development “in accordance with the state of the art” and it does name information security expressly, but it does not say which concrete measure fills that state of the art.
This is exactly the gap that guidance and standard close:
- MDCG 2019-16 Rev.1 (“Guidance on Cybersecurity for medical devices”) is the central EU interpretation aid. It separates pre-market and post-market requirements, meaning what you have to demonstrate before placing the device on the market and what you have to deliver continuously afterwards. It is not legally binding. In audits and reviews it can nevertheless be the basis your auditor assesses you against. It is therefore advisable to work through its content.
- IEC 81001-5-1 (“Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, Activities in the product life cycle”) starts exactly here: it describes what the state of the art required by Section 17.2 concretely means in security, namely the security activities across the product lifecycle. It thereby complements IEC 62304, which covers the software lifecycle and safety but addresses security activities only in general terms. Most notified bodies now treat IEC 81001-5-1 as the de facto state of the art for MDR software. It is therefore not a formal obligation, but it is the benchmark for your development.
Other regulations independent of medical device status
Alongside medical device law, regulations apply to you that span all industries. Here are a few examples:
- GDPR: Article 32 of the General Data Protection Regulation (GDPR) requires technical and organisational measures (TOMs) as soon as you process personal health data, regardless of product status. Implicitly this gives rise to a large number of cyber security measures.
- AI Act: Regulation (EU) 2024/1689 has to be checked as soon as your product contains AI functions, see our article on the AI Act for medical devices.
- BSI TR-03161: the technical guideline of the German Federal Office for Information Security (BSI) is mandatory for German digital health applications (DiGA), details in our article on BSI TR-03161.
- NIS2 Directive: the second EU directive on network and information security (Directive (EU) 2022/2555) applies to you as a company, and it does so purely because of your sector and your size. The manufacture of medical devices and in vitro diagnostics is covered by Annex II of the directive. You count as an “important entity” as soon as you have at least 50 employees or your annual turnover and annual balance sheet total each exceed 10 million euros. In Germany this is implemented through the NIS2 implementation act and the amended BSI Act.
Depending on the product, the field of application and the company context, further obligations may apply to you. This always has to be examined individually for each product.
Overview of cyber security requirements for (software) medical devices
4. When does the CRA affect you anyway?
The exclusion applies on a product basis. The portfolio of a medical device manufacturer sometimes also contains products without any MDR link, and that is exactly where the CRA applies.
As a rule of thumb: as soon as a product or a module does not fall under the MDR, is made available on the market independently and meets the connectivity criterion from chapter 1, the CRA has to be checked.
The critical question is therefore whether all of your products are medical devices (see also our guide “Is your software a medical device?”).
Typical cases of non medical devices are, for example:
- wellness and lifestyle apps without a medical intended purpose
- practice and clinic tools, for instance for appointment management or billing
- analytics dashboards and portals
- separately marketed building blocks such as a software development kit (SDK)
The question is therefore not whether you are a medical device manufacturer, but which of your products falls under which regulation.
A clear intended purpose per product helps with this distinction, and for modules the question of whether the module is made available independently or is part of the medical device.
Our recommendation: draw up a portfolio list once and assign exactly one category to every product and every independently marketed module: MDR, IVDR or CRA (as well as further regulations).
5. Outlook: the MDR revision brings the CRA logic into medical device law
On 16 December 2025 the European Commission presented its proposal for a revision of the MDR and IVDR: Link to the amendment proposal. In it, the Commission expressly identifies the CRA exclusion as a gap.
The line of reasoning in recital 44 of the proposal: the CRA obliges manufacturers to report actively exploited vulnerabilities and severe incidents to the CSIRTs and to ENISA. Medical devices and in vitro diagnostics are exempt from this. Security incidents without an impact on public health or patient safety are therefore not reported in medical device law, because the vigilance rules of the MDR and IVDR only apply to serious incidents. The recital draws the following conclusion:
“This is an important cybersecurity gap. Manufacturers of connected devices should therefore be obliged to report also those incidents to the CSIRTs and ENISA through Eudamed.”
Eudamed is the European database on medical devices under Article 33 of the MDR.
This is to be implemented through a new Article 87a of the MDR, with a counterpart in Article 82a of the IVDR. Its heading reads:
“Reporting of actively exploited vulnerabilities and severe incidents related to devices”
Notably, the definitions are taken directly from the CRA. The CRA mechanism therefore moves into medical device law in substance, without the CRA itself becoming applicable.
In addition, cybersecurity is to be added to Annex I of the MDR. The overview table of the proposal puts the intention as follows:
“In Annex I MDR/IVDR, cybersecurity will be explicitly mentioned in the general safety and performance requirements.”
Concretely, MDR Annex I Section 17.4 is to be extended by the word “cybersecurity”. Section 16.4 of the IVDR is to be amended accordingly.
Please note: this is a proposal by the Commission and not yet applicable law. The European Parliament and the Council have to agree to it, after which a transition period follows.
6. Conclusion
The Cyber Resilience Act is not applicable to MDR and IVDR products. Article 2(2) of the CRA expressly excludes them. Sensibly, the legislator wants to avoid double regulation here.
That does not make the CRA irrelevant for you. What remains to be clarified are the non medical devices in your portfolio: the separately marketed software building blocks described in chapter 4, such as a software development kit.
Software medical devices are nevertheless subject to strict cyber security requirements. However, these do not come from the Cyber Resilience Act and they are not new either. They come from the MDR (or IVDR) and, connected to that, from MDCG 2019-16, IEC 81001-5-1 and further applicable regulations.
Are you planning to build medical software, a DiGA or an embedded project? Get in touch with us. We develop regulated medical software (health apps, DiGA, web platforms and more) and embedded software on a contract basis.
