What actually started on 11 September 2026
The CRA has been in force since December 2024, but its obligations switch on in stages, and September’s stage is reporting. A manufacturer who learns of an actively exploited vulnerability in their product, or of a severe incident affecting it, now owes an early warning within 24 hours to ENISA and their national CSIRT, a fuller notification within 72 hours, and a final report on a timescale of two weeks to a month. The 24-hour clock is deliberately faster than the 72 hours GDPR allows for breach notifications, and it starts at awareness, not at understanding.
The rest of the regulation, secure-by-design requirements, the technical documentation, CE marking for software, support periods with security updates, applies from 11 December 2027. September was the starting gun, not the race. The Commission’s CRA reporting page is the primary source for the mechanics, including the single reporting platform being built for it.
What the CRA covers
The scope phrase is “products with digital elements”, and it is broad on purpose: software and hardware placed on the EU market in the course of a commercial activity. A paid desktop app is in. A firmware-carrying device is in. A JavaScript library sold under a commercial license is in. Where you are based does not matter, selling into the EU does.
Pure services are the main thing out: SaaS as such falls under NIS2, the sibling regulation for operators, not products. The carve-in to know about is remote data processing that a product needs to function, the cloud half of a companion app being the canonical case, which travels with the product into scope.
One sentence of comfort is justified: the CRA regulates placing products on a market, so code as such, published for anyone to read and use, is not the target. Which brings us to the exemption everyone argues about.
The open source carve-out, precisely
Open source developed or supplied outside a commercial activity is outside the CRA. Publishing a library, maintaining it, accepting contributions, hosting it on a public registry, none of that alone creates obligations, and receiving donations or grants does not by itself change that. The regulation also invented a new category for the organizations in between: an “open source steward”, a legal person that systematically supports development of open source intended for commercial use, a foundation being the model case. Stewards carry a light regime, cooperation duties and, from December 2027, their own reporting obligations, but not the full manufacturer program.
The load-bearing rule for everyone downstream: the moment a company integrates open source into a commercial product, that company is the manufacturer, for the whole product, dependencies included. The CRA does not make your maintainers liable to you. It makes you responsible for what you ship, which after a year of npm supply-chain worms reads less like bureaucracy and more like a description of the actual situation.
Where commercial begins
The gray zone questions all reduce to whether software is supplied in the course of a commercial activity, and the recitals give more guidance than most summaries admit:
- Clearly outside: the free project, the hobby app, donations, sponsored development where the result stays freely available to all.
- Clearly inside: selling licenses or the app itself, dual licensing’s paid tier, a product whose “open core” has paid features.
- Where it tilts: charging for the software’s availability or support beyond cost recovery, monetizing with paid priority access, or shipping the code inside anything you sell. The pattern is monetizing the software rather than being paid around it.
A solo developer with a 4.99 app in an EU store is a manufacturer with the full program: requirements, documentation, reporting, update obligations. That is the honest, uncomfortable answer, softened only by the fact that for a small, well-built app the program is mostly writing down what you hopefully already do.
The fight that shaped the carve-out
The exemption did not fall from the sky. The Commission’s 2023 draft defined the commercial boundary so loosely that accepting donations or corporate contributions looked like it might trigger full obligations, and the open source world reacted accordingly: twelve organizations, the Eclipse Foundation, the Open Source Initiative and Linux Foundation Europe among them, signed an open letter warning the act would have “a chilling effect on open source software development”.
The final text is the result of that pushback, with the non-commercial exemption sharpened and the steward category created as the compromise for foundations. It is a rare case of the loud version of open source advocacy visibly improving a law, and worth remembering the next time a draft regulation looks abstract and far away.
What a small team actually does now
If you ship anything commercial with software in it, the fifteen-month runway to December 2027 is enough, provided the boring parts start early:
- Decide your scope answer once, in writing: which of your things are products, which are services, which are exempt. Every later step depends on it.
- Know your dependencies. The 2027 documentation expects an SBOM, and generating one from the lockfile is the easy version of a habit that also pays off in the next supply-chain incident.
- Have a vulnerability intake. A security contact, a policy, and someone who reads the mailbox. The 24-hour clock is unmeetable if reports land in a support queue nobody triages, and the same discipline as rotating leaked secrets first applies to handling reports: speed beats ceremony.
- Find your CSIRT now, not during an incident. Each member state designated one, and knowing yours by name turns the 24-hour warning from panic into a form.
- Write down support periods. The CRA expects a defined window with security updates, five years as the default expectation. Deciding this per product now is cheaper than retrofitting it under deadline.
CRA questions from small teams
Does the Cyber Resilience Act apply to open source software?
Not to open source developed outside commercial activity: contributing to, maintaining or hosting a free project does not by itself put you in scope. The obligations attach to whoever places a product containing that code on the EU market commercially. So the maintainer of a library stays out, while the company shipping a paid product built on it carries the duties, including for the open source inside.
When does the CRA fully apply?
From 11 December 2027. The reporting obligations came first, on 11 September 2026, and the rules for notified bodies started back in June 2026.
What must be reported under the CRA since September 2026?
Two things, by manufacturers: actively exploited vulnerabilities in their products, and severe incidents affecting them. The clock is tight, an early warning within 24 hours to ENISA and the national CSIRT, a fuller notification within 72 hours, and a final report later, 14 days after a patch exists for exploited vulnerabilities and one month for incidents.
Do I have to report vulnerabilities in my free GitHub project?
No. Non-commercial open source is outside the CRA’s scope, and the September 2026 reporting duties bind manufacturers of commercial products.
What is an open source steward under the CRA?
A legal person that systematically supports the development of open source intended for commercial use without selling it, foundations being the model case. Stewards get a light-touch regime instead of full manufacturer duties, with their reporting obligations starting December 2027.
What are the penalties under the CRA?
Up to 15 million euros or 2.5 percent of worldwide annual turnover, whichever is higher, for breaching the core requirements. Lesser breaches carry lower tiers.
Does the Cyber Resilience Act apply to SaaS?
Mostly no. The CRA covers products with digital elements placed on the market, and pure services fall under NIS2 instead. The boundary case is remote data processing that a product depends on to function, a companion app’s cloud backend for instance, which is pulled into the product’s scope.
Is a paid app from a solo developer covered?
Yes. The CRA has no small-business exemption, and selling to even one EU customer is placing a product on the EU market. Solo scale changes the effort of compliance, not the applicability.