Last updated: April 2026

Cyber Resilience Act: your questions, answered.

A practical FAQ for life science OEMs trying to understand what the EU Cyber Resilience Act actually requires, when, and what to do about it. Written by people who do this work every day.

Scope & applicability

Who and what the CRA covers

Yes. The CRA covers any "product with digital elements" placed on the EU market: hardware running software, standalone software, or both. Research-use and non-medical lab equipment is firmly inside scope. This includes gel imagers, plate readers, mass spectrometers, sequencers, microarray scanners, and almost any modern laboratory instrument that ships with software, drivers, or network connectivity.
Yes. The CRA applies to anyone placing products on the EU market, regardless of where the company is headquartered. If you ship into the EU, you fall under the regulation. Non-EU manufacturers also need an authorised representative inside the EU, which is a new obligation worth planning for.
Products fully covered by the MDR or IVDR are excluded from the CRA's direct application, because those regulations have their own cybersecurity provisions. However, the technical principles increasingly align, and any non-medical components, accessories, or analysis software you ship alongside the regulated device may still fall under the CRA. We recommend a product-by-product gap analysis rather than a blanket assumption either way.
The CRA defines it broadly: any software or hardware product, plus its remote data processing solutions, where the absence of those data processing solutions would prevent the product from performing its function. In plain terms: if your instrument needs software to do its job, the whole thing is in scope. This includes embedded firmware, accompanying analysis software, drivers, mobile apps, and cloud-connected components.
Deadlines & enforcement

When the CRA actually starts to bite

The CRA entered into force on 10 December 2024. Three application milestones follow: 11 June 2026 (member states begin notifying conformity assessment bodies), 11 September 2026 (mandatory vulnerability reporting begins), and 11 December 2027 (full enforcement of all requirements).
Maximum administrative fines for failing to meet the essential cybersecurity requirements reach €15 million or 2.5% of global annual turnover, whichever is higher. Failure to comply with other obligations carries fines up to €10 million or 2% of turnover. Supplying incorrect information to authorities can attract fines of €5 million or 1% of turnover.
Products already placed on the market before 11 December 2027 are not retroactively pulled. However, any product placed on the market after that date (including new units of an existing product line) must comply. Crucially, the vulnerability reporting obligations from 11 September 2026 apply to your fielded fleet regardless of when those units were sold.
Technical requirements

What the regulation actually requires

Annex I of the CRA lists the essential requirements. In practical terms, products must: be designed and developed with cybersecurity in mind from the start, be delivered without known exploitable vulnerabilities, have a secure default configuration, protect data confidentiality and integrity, minimise attack surface, support secure updates, log security-relevant events, and provide users with clear information about how to use the product securely.
The CRA requires a support period that reflects how long the product is reasonably expected to be in use, with a default minimum of five years. For life science instruments that often remain in service for ten or fifteen years, this means committing to a substantial security maintenance horizon. The support period must be communicated clearly to customers at point of sale.
Yes. Security updates that address vulnerabilities must be provided to users without charge for the duration of the support period. This is separate from feature updates, which can still be paid. The update mechanism itself must be secure (signed updates, secure delivery channels) to meet the essential requirements.
SBOMs & reporting

Software Bills of Materials and vulnerability disclosure

An SBOM is a structured, machine-readable list of every software component inside a product, including open-source libraries and third-party dependencies. The CRA requires manufacturers to identify and document the components and vulnerabilities in their products by drawing up an SBOM in a commonly used and machine-readable format. Without one, you cannot know what is inside your product, and you cannot meet the vulnerability reporting obligations.
The CRA specifies "a commonly used and machine-readable format." In practice, the two dominant formats are SPDX (Linux Foundation) and CycloneDX (OWASP). Either is accepted. The European Commission may issue further guidance specifying preferred formats closer to enforcement. We default to CycloneDX for new TotalLab projects given its strong tooling ecosystem.
No. The CRA requires you to produce and maintain the SBOM and to make it available to market surveillance authorities on request. There is no requirement to publish it. However, some customers (particularly in regulated industries and government) may begin requiring SBOM disclosure as part of procurement.
From 11 September 2026, manufacturers must report any actively exploited vulnerability in their products to ENISA via the CSIRT network. The timeline is: an early warning notification within 24 hours of becoming aware of the vulnerability, and a full notification with technical details within 72 hours. A separate obligation exists to notify users without undue delay so they can take protective action.
Conformity assessment

How to prove you comply

Most products can be self-assessed by the manufacturer, who then issues an EU Declaration of Conformity and applies CE marking on a cybersecurity basis. Products classified as "important" (Class I or Class II) may require either application of harmonised standards plus self-assessment, or third-party assessment. Products classified as "critical" require a third-party conformity assessment by a notified body. Most life science laboratory instruments will fall into the standard or important categories rather than critical.
The CRA's Annex VII specifies the technical documentation. This includes a general description of the product, its intended purpose and reasonably foreseeable use, a cybersecurity risk assessment, a description of the design and architecture, the SBOM, evidence of how each essential requirement has been met, the procedures for handling vulnerabilities, and records of all conformity assessment activities. The documentation must be retained for ten years after the product is placed on the market.
CE marking under the CRA is in addition to, not a replacement for, any other CE marking your product already requires (e.g. for safety under the Low Voltage Directive). The CE mark on a CRA-compliant product signifies that the cybersecurity essential requirements have also been met. Manufacturers issue a single EU Declaration of Conformity covering all applicable EU regulations.
Overlap with other regulations

How the CRA fits with what you already do

Significantly. Many controls required by 21 CFR Part 11 and EU Annex 11 (audit trails, user authentication, electronic signatures, data integrity controls) overlap with the CRA's essential cybersecurity requirements. Manufacturers already meeting Part 11 / Annex 11 have a substantial head start on CRA compliance. However, the CRA goes further in areas like SBOM management, vulnerability handling, and secure update infrastructure, which Part 11 does not cover.
Partially. GDPR's principles of data protection by design and by default align with the CRA's secure-by-design principle. However, the two regulations have different scopes: GDPR covers the protection of personal data, while the CRA covers the cybersecurity of products with digital elements regardless of whether they process personal data. Compliance with one does not imply compliance with the other.
NIS2 applies to operators of essential and important services (your customers, in many cases), not directly to manufacturers of products with digital elements. The CRA covers the products themselves. The two regulations are complementary: the CRA ensures products are secure when placed on the market, NIS2 ensures organisations using those products operate them securely.
Working with TotalLab

How we help OEMs get CRA-ready

We modernise your existing analysis and instrument software to meet the CRA's essential cybersecurity requirements, white-labelled under your brand. Engagements typically include: gap analysis, SBOM generation, secure software architecture redesign, redevelopment or remediation of legacy code, technical documentation for conformity assessment, and ongoing vulnerability management. Read our full CRA service overview.
For a single instrument with moderate software complexity, engagements typically run 9 to 18 months from kickoff to a fully compliant, conformity-assessed product. Multi-product portfolios can be sequenced in parallel. The earlier you start, the more flexibility you have on scope and approach.
Yes. The audit consists of a 30-minute discovery call plus a written gap analysis delivered within 5 working days. There is no commitment, no SDR follow-up sequence, and no obligation to engage further. We do this because it is genuinely the best way for both sides to assess fit. Book your free audit here.
Still have questions?

The audit answers them all

A free 30-minute call plus a written gap analysis. No commitment, no follow-up sales sequence, just clarity on where your products stand.