The Cyber Resilience Act (CRA) is a European Union regulation, already in force since 10 December 2024. It applies to anyone who places a product on the EU market, including vendors based outside Europe: if your software reaches a European customer, the CRA can reach you, wherever you develop it. Yet in many teams it is still seen as a distant regulation, reserved for makers of connected devices or for compliance departments. That is a mistake.
The CRA changes the target: it does not only look at an organization's cybersecurity, it looks at the cybersecurity of the products with digital elements made available on the market. Installed software, mobile apps, firmwares, appliances, agents, extensions, SDKs, connected equipment, and sometimes the remote services required for them to work.
The first real operational deadline arrives on 11 September 2026 with the obligations to report actively exploited vulnerabilities and severe incidents (article 14). The main obligations then apply from 11 December 2027. September 2026 is not the date to start thinking about it: it is the date by which your notification process must already work. This post answers the only question that matters today: are you affected?
This blog is written in French, and the linked guides are in French. I kept them because they are the underlying references, but be aware of the language before you follow them.
The CRA in one minute
The CRA is a European regulation: therefore directly applicable in every member state without national transposition. It imposes cybersecurity requirements on products with digital elements made available on the European Union market in the course of a commercial activity.
Three key ideas to keep in mind:
- It is a product logic, not an organization logic. The CRA does not look at you as a company, it looks at each product you place on the market.
- It is a life cycle logic, not a checklist at launch time. You must document, maintain, fix and report vulnerabilities throughout the product's support period.
- It is a proof logic. Without a usable inventory of components, without an SBOM, without build traceability and without a documented support policy, you will struggle to demonstrate your grip on the software supply chain, and it is that demonstrable grip that is expected.
Are you affected? The decision table
The CRA distinguishes several economic operators. You can hold one, several or none of them for a given product.
| Role | You match if… | Typical case |
|---|---|---|
| Manufacturer / vendor | You develop, or have developed, a product with digital elements and place it on the market under your name or brand | Software vendor, appliance supplier, EDR agent maker, browser extension vendor, SDK vendor |
| Importer | You place a product bearing the name or brand of an actor established outside the EU on the EU market | European distributor of an Asian connected camera, integrator reselling an American appliance |
| Distributor | You make a product available in the EU without modifying it | Network equipment reseller, integrator, specialized marketplace |
| Authorized representative | You are mandated in the EU to carry out certain obligations on behalf of a manufacturer established outside the EU | Regulatory representative, compliance structure |
| Open-source software steward | You are a legal entity that durably supports the development of open source projects intended for commercial uses, without being the manufacturer of the final product | Foundation, governance entity, structure supporting a commercial OSS project |
If you hold one of these roles for a product with digital elements made available on the European market in the course of a commercial activity, you must analyze your exposure to the CRA. The level of obligation then depends on your exact role, the type of product and its criticality level.
A few concrete cases to fix ideas
- You are a French SaaS vendor with a browser extension for your customers. The SaaS itself is not covered, but the extension is a product with digital elements placed on the market, so CRA.
- You are a cloud platform that provides an official CLI to your users to drive their account or deploy their resources (open source or proprietary, it does not matter). The CLI is installed and run on your customers' machines, so CRA, as the CLI vendor. The remote service behind it may additionally fall under remote data processing solutions if the CLI is useless without it.
- You are a DevOps startup that distributes an agent to install on your customers' machines to collect metrics. The agent is a product with digital elements installed at a customer's, so CRA, as the vendor.
- You are an IT services company that integrates a network appliance from a non-EU supplier and resells it to European customers. CRA, as the importer.
- You are an internal team that builds a tool for your own operations, never sold, never distributed. Out of scope (no commercial activity, no placing on the market).
The three confusions that cost dearly
Confusion no. 1, the CRA is not NIS2
NIS2 targets organizations considered essential (hospitals, energy, transport, critical cloud). The CRA targets products with digital elements. You may be affected by both, by one, by the other, or by neither. For a DevOps team, the impact is radically different: NIS2 asks you for governance and continuity, the CRA asks you for technical documentation, vulnerability management, component traceability, proof of compliance and a notification process with an early warning within 24 h then a full notification within 72 h in case of an actively exploited vulnerability.
Confusion no. 2, "we do SaaS, so we are safe"
That is only true in the simplest cases. A purely cloud SaaS, with no software, agent, extension, app or appliance made available to the customer, may be out of CRA scope and fall instead under other frameworks such as NIS2.
But as soon as there is a client component: browser extension, companion mobile app, on-premise agent, distributed SDK, official CLI, virtual appliance, that component must be analyzed as a product with digital elements. And if a remote service is indispensable to that product's operation, it too can enter the scope as a remote data processing solution. The majority of modern B2B SaaS have at least one client component, if only a CLI.
Confusion no. 3, "the CRA will kill open source"
No, but it changes the responsibility of companies that consume and commercialize open source. The individual maintainer who publishes a library on GitHub with no commercial activity is not the CRA's target.
On the other hand, when a vendor integrates that library into a commercial product, it is the final product that must be under control: it is the vendor who answers for that library's vulnerabilities, not the upstream maintainer. The CRA also introduces a specific regime for open-source software stewards: legal entities that durably support open source projects intended for commercial uses, without necessarily being the manufacturers of the final product.
The message is therefore simple: the CRA does not ask volunteer maintainers to shoulder the security of the whole industry alone. It asks the economic actors that place products on the market to own their supply chain: hence the importance of the SBOM.
The 10 questions to ask now
If you answer "yes" to at least one question in each block, you are affected and the preparation work starts today.
Block 1, Scope
- Does my product contain software (code I write or embed)?
- Is it sold, distributed or made available in the European Union, even for free?
- Is it installed at a customer's in one form or another (agent, SDK, extension, appliance, mobile app)?
- Is it connected, directly or indirectly, to a network?
Block 2, Proof capability
- Do I have a reliable inventory of each product's dependencies?
- Can I generate an SBOM at every release?
- Can I know, in under an hour, whether a CVE published today affects me?
- Do I have a documented and executable remediation procedure?
- Do I have a clear support policy (duration, patch frequency, end of life)?
- Do I have a notification procedure for exploited vulnerabilities to the competent authorities?
The best test of the CRA is not an Excel sheet. It is a real exercise: a critical CVE lands on a dependency used by three of your products. How long does it take you to know whether you are affected, to fix, rebuild, publish and inform? If the answer exceeds 24 to 48 hours, your process is not ready.
Conclusion: the CRA is a product subject, not a compliance one
The CRA should not be treated as one more legal constraint delegated to the CISO. For DevOps and DevSecOps teams, it is the opportunity to put the software production chain back in order: controlled dependencies, traceable builds, signed artifacts, industrialized vulnerability handling, documented support.
The real question is therefore not only "are we affected?" but "if we are, can we demonstrate it and react fast?". The answer to the first question is in the table above. The answer to the second depends entirely on the work you begin today.