The Cyber Resilience Act (CRA) is introducing mandatory cybersecurity requirements for software and connected products placed on the EU market.
As part of our Ask Our Experts campaign, we invited companies to submit their biggest concerns and practical questions related to CRA compliance. The topic proved highly relevant among software vendors, laboratory instrument manufacturers, and companies operating in regulated environments.
The response was overwhelming. We received a large number of highly practical and technically detailed questions, which we are answering below. To make the content easier to navigate, we divided the answers into two blog posts. In this first part, our experts address some of the most common questions around CRA scope, applicability, legacy systems, support obligations, software updates, and compliance responsibilities.
Our software is already certified under the Medical Devices Regulation (MDR) and In Vitro Diagnostic Medical Devices Regulation (IVDR). How does the CRA apply to us?
If your software is certified under the MDR or IVDR, those specific products are fully exempt from the CRA, as those regulations already mandate strict cybersecurity risk management.
But be careful with mixed portfolios. In our experience, many IVD companies also sell general laboratory equipment, standalone data analysis software, or Research Use Only (RUO) devices. Because these specific modules are not MDR/IVDR certified, they fall squarely under the CRA. You will need to clearly delineate your quality management systems and software architectures so the RUO modules meet CRA requirements.
We have a web product (SaaS); our customers subscribe and access it through the browser, they don’t install anything. Does the CRA apply to our case?
Standalone SaaS and cloud-only services are handled differently and generally fall outside the direct scope of the CRA. The CRA only regulates cloud services if they qualify as “remote data processing”, meaning the cloud service is designed by the manufacturer to support a specific physical or downloadable product with digital elements, and without the cloud service, that product wouldn’t function. If your platform is purely a standalone SaaS accessed via a web browser without any supporting installable software or hardware, it is not considered a “product with digital elements” under the CRA. However, keep in mind that as a SaaS provider, your platform can fall under requirements of the NIS2 Directive instead!
Our application runs on a computer in a laboratory that is not connected to the internet, a local network, or any other external system. Does the CRA still apply to software like this?
Yes, even if your application runs fully offline, it almost certainly still falls under the CRA. The regulation applies to any digital product whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. An “indirect connection” occurs when your software runs on a host system that initiates connections, such as an offline text editor or calculator running on an operating system. Unless your software is embedded in a completely isolated hardware device with absolutely no physical or logical interfaces to other systems, the CRA’s requirements will apply.
Source: Pixabay
We develop software purely for use inside our own labs (for example, internal LIMS integrations and automation tools) and never commercialize it externally. Are we still considered a manufacturer under the CRA, or is internally developed “captive use” software outside its scope?
You will be happy to hear that your internally developed “captive use” software falls completely outside the scope of the CRA. The regulation explicitly applies only to products with digital elements that are “placed on the market” or “made available on the market”. According to the guidelines, placing on the market does not take place when a product is manufactured exclusively for one’s own use. As long as your lab never commercializes these internal tools or makes them available to external parties, you are not considered a manufacturer under the CRA.
We use internal development tools such as compilers, CI/CD pipelines, automated testing frameworks, and SDKs. Are these types of engineering tools considered “products with digital elements,” and subject to this act?
You will be happy to hear that your internal development tools are not subject to the CRA. The regulation explicitly states that placing on the market is not considered to take place when a product is manufactured exclusively for one’s own use. Therefore, as long as your compilers, CI/CD pipelines, and configuration tools are used purely internally by your engineering team and are not commercialized or made available as separate products to external parties, they fall completely outside the scope of the CRA.
We’ve got plenty of systems already out in the field. Do we need to go back and update all of them, or even pull some of them back if they don’t meet the new requirements?
For the most part, your legacy instruments are “grandfathered” in. The CRA’s requirements only apply to products placed on the market after December 11, 2027, so you do not need to recall them unless they undergo a “substantial modification” after that date, such as a major software update that changes the core intended purpose.
However, there is one important catch we always remind our clients about: The mandatory reporting rules for actively exploited vulnerabilities and severe incidents apply to all products within the CRA’s scope, including legacy ones, starting September 11, 2026.
This is still considered “placing on the market,” meaning the software is not entirely exempt from the CRA. However, because you are building custom software fitted to a particular purpose for a single business user, it likely qualifies as a “tailor-made” product. For genuinely tailor-made products, the CRA gives you some practical flexibility: you can deviate from the strict “secure by default” configuration rules and the obligation to provide security updates for free, provided you and your client explicitly agree to those different contractual terms. You must still comply with the rest of the CRA’s obligations, such as conducting a risk assessment and incident reporting.
We develop custom, tailor-made software platforms for specific biotech clients. Do the ‘secure by default’ configuration rules still apply to these custom projects, or can we agree on different contractual terms?
For genuinely “tailor-made” products built for a specific business user, you have flexibility. The CRA allows you to deviate from the “secure by default” configuration rules if both you and your client explicitly agree to a different set of contractual terms. Just remember that this exception does not apply to standard, off-the-shelf software with minor customizations; the product must be truly bespoke, and you must document this tailor-made status in your technical documentation.
We distribute software exclusively through digital downloads from our website or customer portal. At what exact point is the software considered “placed on the market” under the CRA?
Under the CRA, a software product is considered “placed on the market” the very first time it is made available for distribution or use on the EU market in the course of a commercial activity. For digital downloads, this happens the moment your software is offered for sale (or free commercial distribution) online or through your customer portal to EU users. It is not tied to the moment a customer actually clicks “download” or installs it; simply making it digitally available to be acquired constitutes placing it on the market.
Our software is a data analysis tool, not a safety or infrastructure system. Can we certify it ourselves?
Yes, you can! Since your software does not control critical infrastructure, it likely falls into the CRA’s ‘default category’, which allows you to self-assess your conformity (using Module A) without having to hire an external Notified Body.
However, self-certifying still requires work. You are legally obligated to conduct a cybersecurity risk assessment, implement the necessary security measures, and draw up detailed technical documentation.
Download the Cyber Resilience Act (CRA) Readiness Checklist to turn requirements into actionable steps.
Get a practical overview of what CRA compliance means for your product, including:
✔ Key cybersecurity requirements across the product lifecycle
✔ “Secure by design” and “secure by default” principles
✔ Documentation, conformity, and CE marking essentials
✔ Post-market obligations, including monitoring and incident reporting
What is the minimum time of the support period? Is it really 5 years?
While five years is the general minimum, there is a sensible exception. If your product is genuinely expected to be in use for less than five years, you can define a shorter support period that strictly corresponds to its actual expected use time. This is often the case for products tied to a specific short-term subscription model or built for a very temporary, specific purpose (like a pandemic contact-tracing app).
If a security patch comes out, do we now have to provide it for free, or can it still be covered under a paid maintenance agreement?
The rule for free security updates applies across the board, including to your B2B laboratory clients. The only legal exception is for “tailor-made” products—highly customized solutions fitted specifically for a single business user where both parties explicitly agree to different contractual terms.
For standard, off-the-shelf products, a practical approach we help vendors implement is architecting their software so that general feature enhancements (which you can monetize) are delivered separately from security updates (which must be free).
The CRA pushes for automatic security updates. However, in GxP-regulated laboratories, automatic updates can break validated workflows. Are we forced to force-install updates, or are there exemptions for industrial/critical environments?
You are not forced to disrupt your clients’ validated GxP workflows, but you must formally justify your approach. The CRA mandates automatic security updates “where applicable”. The regulation does not grant a blanket exemption based solely on the industry; rather, it acknowledges that automatic updates are not always appropriate.
Regulators explicitly note that users in critical or industrial environments (such as a GxP lab) would not reasonably expect automatic updates if they could interfere with operations. Therefore, you can choose not to force automatic updates, but you must clearly document this decision and provide a justification in your cybersecurity risk assessment and technical documentation, explaining why they are not applicable to your product’s intended use.
Furthermore, even when automatic updates are enabled, you must always provide users with a clear, easy-to-use opt-out mechanism and the option to temporarily postpone them. Your lab clients retain full control.
The CRA is much more than another regulatory checkbox. It introduces a significant shift in how software and connected products must be designed, maintained, and supported throughout their lifecycle. For many companies, the challenge is no longer understanding the regulation itself, but translating its requirements into practical engineering, operational, and quality management processes.
In Part 2, we will continue with additional expert answers covering SaaS, offline systems, vulnerability disclosure processes, technical documentation, audits, CE marking obligations, and ongoing compliance expectations.
