The correct first question is whether Regulation (EU) 2017/745 applies to the product. If it does, CRA Article 2 excludes that product from CRA scope. Recital 25 explains the policy reason: the MDR already addresses cybersecurity risks, lifecycle risk management, IT security measures and conformity assessment for electronic and software medical devices. Product teams should keep strong cybersecurity evidence, but map it to MDR requirements and medical-device guidance rather than treating the excluded device as a CRA product.
CRA Article 2 Expressly Excludes Products Covered by the MDR
CRA Article 2(2)(a) states that the Regulation does not apply to products with digital elements to which Regulation (EU) 2017/745 applies. This is an express product-scope exclusion, not merely an overlap-management rule. Once the product falls under the MDR, the CRA product requirements and conformity route do not apply to that product on top of the MDR.
The Exclusion Exists Because the MDR Already Addresses Cybersecurity
CRA Recital 25 explains that the MDR addresses cybersecurity risks through essential requirements for medical devices that function through electronic systems or are software themselves. It also points to lifecycle risk management, IT-security measures and corresponding conformity-assessment procedures as reasons those products should not be subject to the CRA.
Medical Device Software Can Be a Regulated Device in Its Own Right
Under the MDR, software specifically intended by the manufacturer for one or more medical purposes can itself qualify as a medical device. General-purpose software, even when used in healthcare, does not automatically become a medical device. The product's intended purpose therefore remains central to deciding whether the MDR exclusion from the CRA applies.
MDR Annex I Section 17.2 Requires State-of-the-Art Software Development
For devices incorporating software, or software that is itself a device, Annex I section 17.2 requires development and manufacture in accordance with the state of the art, taking into account development lifecycle principles, risk management including information security, verification and validation. Cybersecurity must therefore be built into the software lifecycle even though the device is outside CRA scope.
Manufacturers Must Define Minimum IT Security Measures
Annex I section 17.4 requires manufacturers to set out minimum requirements for hardware, IT-network characteristics and IT-security measures, including protection against unauthorised access, that are necessary for the software to run as intended. These requirements belong to the MDR technical and user environment rather than to CRA Annex I.
Risk Management Remains a Lifecycle Obligation
MDR Annex I requires manufacturers to establish, implement, document and maintain a risk-management system. Cybersecurity threats that can affect safety, performance or intended use should therefore feed the medical-device risk process throughout the device lifecycle rather than being treated as a one-time pre-market checklist.
Security Patches Are Recognised in MDR Software Identification Rules
The MDR UDI provisions recognise minor software revisions such as security patches as a distinct category of software change. That does not make every security patch legally minor in every context, but it confirms that cybersecurity maintenance is expected to be managed within the medical-device software lifecycle and change-control system.
Technical Documentation Should Preserve Cybersecurity Evidence
MDR technical documentation includes software verification and validation evidence and information needed to demonstrate conformity with applicable general safety and performance requirements. Manufacturers should preserve architecture, risk, test, update and vulnerability evidence in a form that supports the MDR conformity case and post-market obligations.
CRA Article 14 Does Not Become the Reporting Route for an MDR Product
Because a product to which the MDR applies is outside CRA scope, CRA Article 14 reporting is not the product's regulatory reporting route merely because a cybersecurity event occurs. Medical-device vigilance and other applicable sectoral reporting rules remain the relevant legal framework, subject to the facts of the incident.
Do Not Extend the MDR Exclusion to Unrelated Products
The exclusion follows the product to which the MDR applies. A manufacturer may also sell general-purpose software, gateways, infrastructure or accessories that require their own scope analysis. Do not assume the whole corporate product portfolio is excluded from the CRA because one medical-device product line falls under Regulation (EU) 2017/745.
Document the Exclusion as a Positive Scope Conclusion
The regulatory file should record why the product qualifies under the MDR, which product configuration and software are covered, and why CRA Article 2(2)(a) therefore excludes it. This creates a clearer audit trail than simply marking the CRA as not applicable without the legal basis.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.