The CRA does not apply to products with digital elements that fall under the IVDR, but cybersecurity remains a substantive IVDR requirement. Annex I section 16 requires state-of-the-art software development and information security and requires manufacturers to define minimum hardware, network and IT-security conditions, including protection against unauthorised access. The product qualification and intended purpose should be documented carefully because general laboratory or general-purpose software is not automatically an IVD and may require a separate CRA analysis.
CRA Article 2 Expressly Excludes Products Covered by the IVDR
CRA Article 2(2)(b) states that the CRA does not apply to products with digital elements to which Regulation (EU) 2017/746 applies. For an in-scope IVD, the cybersecurity conformity framework is therefore the IVDR and its supporting guidance rather than a duplicate CRA product-compliance route.
CRA Recital 25 Treats the IVDR as an Existing Cybersecurity Framework
Recital 25 explains that the IVDR already addresses cybersecurity risks for electronic and software devices through risk-management principles, IT-security requirements, lifecycle coverage and conformity assessment. That existing sectoral framework is the reason IVD products covered by the IVDR are excluded from CRA scope.
Software Can Itself Be an In Vitro Diagnostic Medical Device
Software specifically intended by its manufacturer for one or more purposes within the IVDR definition can qualify as an IVD in its own right. General-purpose software, including software used in laboratories, does not automatically become an IVD. Intended purpose and regulatory qualification therefore determine whether CRA Article 2(2)(b) applies.
IVDR Annex I Section 16.2 Requires Information Security in the Software Lifecycle
Section 16.2 requires software incorporated in devices, and software that is itself a device, to be developed and manufactured according to the state of the art, taking account of software lifecycle principles, risk management including information security, verification and validation. Cybersecurity is therefore integrated into IVD software development even without CRA applicability.
Manufacturers Must Define IT Security and Network Conditions
Section 16.4 requires manufacturers to set out minimum requirements for hardware, IT-network characteristics and IT-security measures, including protection against unauthorised access, necessary to run the software as intended. Deployment assumptions should therefore be explicit in technical documentation and user information.
IVD Cybersecurity Risk Must Be Connected to Safety and Performance
The IVDR requires a documented risk-management system and conformity with applicable general safety and performance requirements. Cybersecurity threats should be analysed where they can affect diagnostic performance, data integrity, availability, intended use or the safety of patients, users or other persons.
Data Integrity Is Especially Important for Diagnostic Software
IVD software can interpret, transmit or manage diagnostic data. Unauthorised alteration, corrupted configuration, compromised algorithms or manipulated interfaces can therefore affect performance. Cybersecurity controls should be tied to the specific diagnostic workflow and validated use environment rather than copied from a generic IT baseline.
Technical Documentation Should Preserve Software and Security Evidence
IVDR technical documentation includes design information, software descriptions, system overviews and evidence demonstrating conformity with applicable safety and performance requirements. Security architecture, validation, network assumptions, vulnerability decisions and software-change records should be preserved as part of the controlled evidence set.
CRA Article 14 Is Not the Default Reporting Route for an IVDR Product
An IVD product excluded from CRA scope does not become subject to CRA Article 14 merely because it experiences a cybersecurity event. Manufacturers should assess IVDR vigilance and other sectoral reporting obligations based on whether the cybersecurity issue meets the relevant medical-device reporting criteria.
General Laboratory Software Still Needs Its Own CRA Scope Analysis
Software used in an IVD environment may fall outside the IVDR if it is not specifically intended as an in vitro diagnostic medical device or accessory. Such software does not inherit the IVDR exclusion automatically. Its CRA status should be assessed separately based on the product, intended purpose and connection criteria.
Record the Product Qualification and CRA Exclusion Together
A robust scope file should identify the product's IVDR qualification, intended purpose, software boundaries and applicable configuration and then cite CRA Article 2(2)(b) as the exclusion basis. This keeps the CRA decision traceable if the software or intended purpose later changes.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.