Sell software in the EU? You now have to prove you can patch it.
The Cyber Resilience Act sets security requirements for products with digital elements sold on the EU market. NIS2 governs how you run your own company. The CRA governs what you ship to customers — and it applies whether or not you consider yourself a security company.
The practical test: if your product contains software or connects to a network and you place it on the European market, you are almost certainly in scope.
Applies in stages, reporting duties first. Check the consolidated text in the Official Journal for the dates applying to your product category before you plan around them. This page describes the mechanism and is not legal advice.
What you have to be able to do
- Ship without known exploitable vulnerabilities, with secure defaults.
- Produce an SBOM — a complete list of every library and version inside your product.
- Handle vulnerabilities — find them, fix them, and get the fix to customers for the whole declared support period.
- Report actively exploited vulnerabilities and severe incidents, on short deadlines.
- Accept outside reports through a coordinated disclosure channel that actually responds.
- Declare a support period to the customer at the point of sale.
The question that decides whether you pass
A vulnerability drops in a library you use. How long does it take you to answer "are we affected, which customers, and how fast can we patch them"?
If the answer is "a few days of someone digging through repositories", you do not have a CRA process. Almost nobody fails on the requirements themselves — they fail because there is no system underneath:
- An SBOM generated by hand once for an audit, useless the next day
- Nobody assigned to watch for vulnerabilities in the components you ship
- No record of which customer has which version installed
- No mechanism to push a security update to everyone quickly
- Reporting deadlines that cannot be met because nobody knows who decides
What we build
Automated
- SBOM generated in your build pipeline, every release
- Continuous monitoring of published vulnerabilities against it
- Alerts only when a shipped product is genuinely affected
- A register of installed versions per customer
- A working security update distribution path
Documented
- Vulnerability handling and coordinated disclosure procedure
- Reporting workflow with named decision-makers
- Product technical documentation
- Support and update policy
- Developer training
This wins you deals, not just compliance
If you sell to companies under NIS2, they are legally obliged to assess you as a supplier. A working CRA process hands you exactly what their security questionnaires demand: SBOM, vulnerability policy, declared support period, reporting channel.
You answer in a day. Competitors without it stall for three weeks, then get dropped from the shortlist. The regulation becomes your sales advantage.
If your product includes AI
Requirements stack rather than replace. A connected product with an AI component can fall under both the CRA and the EU AI Act, with separate documentation for each. Models and inference libraries go into the SBOM like any other dependency, and the model version becomes part of the product 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 is usually a sobering conversation with your dev team.
Book a free 30-minute call and we will walk through what your current release process would and would not survive.
Find out what this would cost you — in 30 minutes, free
Tell us one process that eats your team's time. We will tell you on the call whether an AI agent can take it over, roughly what it costs, and what it would save. If it is not a good fit, we say so — we would rather lose the sale than sell you the wrong thing.