Cyber Resilience Act: what open source and SMEs need to know from September 2026
Since 11 September 2026, manufacturers must report actively exploited vulnerabilities within 24 hours. Who is concerned, where open source stands, and what it changes even if you are not a manufacturer.
The EU Cyber Resilience Act (CRA) sets security requirements for "products with digital elements" placed on the Union market: connected devices, software, firmware. Its first part began applying on 11 September 2026, and it directly concerns the open source ecosystem — including the SMEs that consume it.
What has applied since 11 September 2026
According to the European Commission’s page, manufacturers must now notify actively exploited vulnerabilities and severe incidents affecting the security of their products: an early warning within 24 hours, a full notification within 72 hours, then a final report no later than 14 days after a fix is available (one month after the notification for a severe incident). Everything goes through a single reporting platform run by ENISA, operational from the same date.
The substantive obligations (secure design, documentation, vulnerability handling over the product’s lifetime) come later, in December 2027. Reporting is therefore the first step — and the one that forces you to have a process before you need one.
What about open source?
The regulation distinguishes free software developed outside commercial activity, which stays out of scope, from open source "stewards" — organizations that systematically support a project intended for commercial use. Stewards fall under a lighter regime, with their reporting obligations starting later (December 2027). By contrast, a company that integrates an open source component into a product it sells becomes responsible for it: it is the manufacturer, and it must exercise due diligence on its components, open or not.
Are you concerned?
Three situations, from most to least direct:
- You sell a digital product (connected device, embedded software, distributed application): you are a manufacturer, and the calendar above targets you.
- You use open source internally (ERP, email, collaboration tools) without selling it: the regulation imposes nothing on you directly.
- You integrate or resell solutions to clients: your clients will ask for guarantees about your components, since they answer for them themselves.
If in doubt, have your case reviewed by legal counsel: qualifying as a "product" and as a "manufacturer" is the delicate point.
What applies to everyone: controlling your dependencies
Even outside its scope, the CRA sets a good practice that will become a commercial expectation:
- A component inventory (a software bill of materials, or SBOM): knowing what runs, in which version, from where.
- An update process: who watches security advisories, how fast a patch is applied, how it is tested.
- Lifecycle monitoring: a component abandoned by its maintainers is security debt piling up.
- A contact point and a procedure for handling a vulnerability report, inbound or outbound.
It is also what we find in the basics of a secure SME infrastructure. Open source has a real advantage here — code is inspectable and fixes are public — but only if someone actively watches those fixes.
Sources
A question about your situation?
Take the self-audit — 93 questions, no sign-up — or ask for a free audit straight away: we’ll look at your specific case.