Over the past few years, one trend has become impossible to ignore: every device is becoming connected, and every connected device is becoming a potential attack surface.
The EU’s response to this reality is the Cyber Resilience Act (CRA), a regulation that will fundamentally change how digital products are built, delivered, and maintained.
If you are developing laboratory instruments, scientific software, or any kind of connected system, this is not something happening “on the regulatory side.” It directly affects your product, your architecture, and your development process.
So what is the CRA, really?
The Cyber Resilience Act (CRA) is a comprehensive European Union regulation that ensures digital products on the EU market are secure against cyber threats. At its core, the CRA introduces a simple yet far-reaching requirement: If you place a product with digital elements on the EU market, you are responsible for its cybersecurity throughout its entire lifecycle.
That responsibility doesn’t end with product design and release. It includes how vulnerabilities are handled and how updates are delivered years after deployment.
For many teams, this is a shift. Traditionally, security has often been treated as a feature added late in development, something handled by the customer’s IT environment, or a compliance checkbox before release. The CRA makes it clear that this is no longer sufficient.
Source: Pixabay
The timeline is closer than it seems
The regulation is already in force, here are key milestones:
- December 10, 2024: The CRA officially entered into force.
- September 11, 2026: Mandatory reporting obligations apply for actively exploited vulnerabilities and severe incidents.
- December 11, 2027: The CRA becomes fully applicable. All new products with digital elements placed on the EU market must comply with the requirements.
On paper, that may look like a comfortable timeline. In reality, adapting development processes, architectures, and support models takes time, especially for complex products.
What counts as a “product with digital elements”?
In practice, almost everything we build today. The definition is intentionally broad. If your product includes software or connects to a network (directly or indirectly), it is in scope.
In a laboratory or scientific environment, that typically includes:
- instruments with embedded software or firmware,
- standalone data analysis applications,
- systems connected to LIMS, ELN, or cloud platforms.
A useful rule of thumb: If your product processes or exchanges data, assume the CRA applies.
There are exceptions. Products already regulated under MDR or IVDR are excluded, since they are covered by their own cybersecurity requirements. But outside of that, most research-use devices and software fall squarely under the CRA.
Why are most manufacturers affected, even if they don’t realize it yet?
In practice, we often see teams underestimate how interconnected their products really are. A device may seem “standalone,” but it exports data, integrates with another system, or relies on external components. From a CRA perspective, that’s enough.
This is why, for most manufacturers, the real question is no longer whether the CRA applies, but how deeply it affects their current way of working.
The biggest shift: responsibility moves to the manufacturer
The most important change the CRA introduces is not a specific requirement; it’s a shift in responsibility. Cybersecurity is no longer something that can be delegated to the customer or the IT environment. It sits firmly with the manufacturer.
This becomes very concrete in areas like vulnerability handling. If a vulnerability is discovered in your software (even in a third-party library), you are responsible for: identifying it, assessing the risk, and delivering a fix. And doing so in a structured, documented way.
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
From shipping a product to owning it over time
Another major change is the move from delivery to lifecycle ownership. In many organizations, the implicit model has been:
build → validate → release → move on
The CRA replaces this with something closer to:
build → release → monitor → update → repeat
You are expected to:
- define a support period (often five years or more),
- monitor vulnerabilities continuously,
- deliver security updates without delay.
Importantly, under the CRA, manufacturers are legally required to provide these security updates free of charge to users. Where possible, updates must also be installed automatically and enabled by default, reducing reliance on user action and ensuring vulnerabilities are addressed in practice, not just in theory.
In software terms, this starts to look much more like maintaining a live system than delivering a finished product. And that has implications.
It requires:
- Processes for vulnerability tracking
- Clear ownership (who reacts when something is found)
- Infrastructure for distributing updates
Without these in place, compliance becomes very difficult.
What this means for how software is built
From a development perspective, the CRA forces a shift left. Security decisions now happen at the design stage, not just before the release. It has to be part of architecture decisions, technology selection, and development practices.
Take something as simple as using an open-source library. Today, that might be a quick decision based on functionality. Under the CRA, it also becomes a security decision:
- Do we know what’s inside it?
- Can we track vulnerabilities?
- Can we update it quickly if needed?
This is where concepts like software bill of materials (SBOM) and supply chain control become relevant. Not as theory, but as practical requirements.
When something goes wrong, you need to react fast
The CRA also introduces strict reporting obligations. If an actively exploited vulnerability is identified, manufacturers must report it to authorities within a very short timeframe (starting with 24 hours). That means you need: visibility (how do you even know something is happening?), escalation paths, and defined responsibilities. This is not something that can be improvised when an incident occurs.
Ultimately, CRA compliance becomes part of CE marking, meaning non-compliant products cannot be placed on the EU market.
Source: Pixabay
Where to start
For most teams, the first step is not implementation; it’s understanding the gap.
What we typically see is that companies already have parts of the puzzle: some security practices, some update mechanisms, and some documentation. But rarely do they have a complete, end-to-end approach aligned with CRA expectations.
That’s why the most effective starting point is a structured assessment:
- What do we already have?
- Where are the gaps?
- What needs to change in our product and processes?
The key takeaway
The Cyber Resilience Act is not just another compliance requirement. It reflects a broader shift in how digital products are expected to behave: not as static deliverables, but as systems that must remain secure over time.
For manufacturers, this means one thing: You don’t just build the product. You own its security for as long as it exists on the market.
If you are navigating how these requirements apply to your product, feel free to contact us.
BioSistemika can implement and manage CRA compliance across your software, processes, and product lifecycle, so that you have time to put your focus elsewhere.
