- Home
- Compliance
- Cyber Resilience Act for software manufacturers
Cyber Resilience Act for software manufacturers
Sell software in the EU? Now you have to prove you can patch it.
The Cyber Resilience Act sets security rules for products with digital elements sold in the EU. NIS2 covers how you run your company. The CRA covers what you ship to customers, whether or not you think of yourself as a security company.
The quick test: if your product contains software or connects to a network, and you sell it in Europe, you're almost certainly in scope.
Trusted since 2004 by the public sector, energy and heavy industry: buyers who audit their suppliers before they sign. See the case studies.
It applies in stages, reporting duties first. Check the consolidated text in the Official Journal for the dates that apply to your product category before you plan around them. This page explains how the rules work and isn't legal advice.
What you need to be able to do
- Ship without known exploitable vulnerabilities, with secure defaults.
- Produce an SBOM: a full list of every library and version in your product.
- Handle vulnerabilities: find them, fix them and get the fix to customers for the whole support period.
- Report actively exploited vulnerabilities and severe incidents, on short deadlines.
- Take outside reports through a disclosure channel that actually replies.
- Declare a support period to the customer at the point of sale.
The question that decides it
A vulnerability turns up in a library you use. How long until you can say whether you're affected, which customers are, and how fast you can patch them?
If the answer is "a few days of someone digging through repositories", you don't have a CRA process. Companies rarely fail on the requirements. They fail because nothing sits underneath them.
Where it usually breaks
- An SBOM made by hand once for an audit, out of date the next day
- Nobody watching for vulnerabilities in the parts you ship
- No record of which customer runs which version
- No quick way to push a security update to everyone
- Reporting deadlines missed because nobody knows who decides
What we build
Automated
- An SBOM generated in your build pipeline, every release
- Continuous checks of published vulnerabilities against it
- Alerts only when a shipped product is really affected
- A register of installed versions per customer
- A working path for security updates
Documented
- Vulnerability handling and coordinated disclosure procedure
- Reporting workflow with named decision-makers
- Product technical documentation
- Support and update policy
- Developer training
It wins deals, too
Customers under NIS2 must assess you as a supplier. A working CRA process gives you what their questionnaires ask for: SBOM, vulnerability policy, support period, reporting channel.
You answer in a day. Competitors without one stall for three weeks and drop off the shortlist.
If your product includes AI
The rules stack. A connected product with an AI component can fall under both the CRA and the EU AI Act, each with its own documentation. Models and inference libraries go in the SBOM like any other dependency. The model version becomes part of the configuration you have to control.
Find out where you stand in a day
Generate an SBOM for your main product and count the known vulnerabilities in it today. It takes about a day, and it's usually a sobering talk with your developers. Then book a call and we'll go through what your release process would and wouldn't survive.
Common questions
What is an SBOM and why do I need one?
Software Bill of Materials: the complete list of components and libraries in your product, with versions. Without it you cannot quickly answer the question that matters during an incident: am I affected by this vulnerability?
Does it apply to internal software?
The regulation targets products with digital elements made available on the market. Software used strictly internally falls under a different regime, but vulnerability management practices remain relevant for NIS2.
Find out in 30 minutes if it's worth doing.
Tell us about one process that eats your team's week. We'll tell you on the call whether an agent can take it over, roughly what it costs and what it saves. If it's not a fit, we'll say so.