By ByteBot
Five days. That’s how long developers and software companies have before the EU Cyber Resilience Act’s Article 14 kicks in. From September 11, 2026, any manufacturer shipping a product with digital elements to the EU market must report actively exploited vulnerabilities within 24 hours and file a full notification within 72. Products already on the market are not exempt. Fines reach €15 million or 2.5% of global annual turnover, whichever is higher. Most small teams haven’t set up anything to handle this.
Who This Affects (Hint: Probably You)
The CRA covers virtually any software or hardware product that can connect — directly or indirectly — to another device or network. That means mobile apps, desktop applications, operating systems, libraries, SaaS platforms with downloadable components, and connected devices. Pure cloud-native SaaS with no installed component is generally excluded, but that line is blurrier than the EU’s own guidance makes it sound.
There’s also a retroactive trap that most coverage glosses over. Article 69(3) explicitly states that the Article 14 reporting requirements apply to products placed on the EU market before December 11, 2027 — the full CRA application date. If you shipped software two years ago and it’s still in use by EU customers, and a CVE lands on it tomorrow, you are required to report. Retroactive scope is the most underappreciated risk here.
The 24-Hour Clock Is Not a Soft Target
Here is what Article 14 actually requires, operationally:
- 24 hours — Early warning to ENISA and your national CSIRT after becoming aware of an actively exploited vulnerability
- 72 hours — Full notification with technical details and impact assessment
- 14 days — Final report after a corrective or mitigating measure is available
All reports go through the ENISA Single Reporting Platform (SRP), which simultaneously routes your submission to the relevant national CSIRT. The platform goes live by September 11 — a testing period is already open, and you should register before you need it.
The 24-hour window is not a paperwork problem. It’s an operational readiness problem. To meet it, you need automated vulnerability monitoring that alerts you the moment a CVE is associated with your dependencies, an accurate Software Bill of Materials (SBOM) to know your dependency graph in real time, a designated person or team empowered to file regulatory reports, and a tested incident response playbook. Enterprise teams with 24/7 security operations centers can manage this. A three-person startup team running a SaaS product with a couple hundred EU users might find it genuinely difficult.
The Open-Source Exemption Has Edges
If you maintain a personal GitHub project with no revenue and no corporate backing, you’re exempt from manufacturer obligations. The CRA carves out purely non-commercial open-source software explicitly.
The nuance is what happens downstream. When your library gets integrated into a commercial product, the CRA obligations land on the commercial manufacturer — not on you as the upstream maintainer. You won’t be fined. You may, however, face pressure from enterprise users to patch faster under the weight of their own compliance timelines.
The harder case is open-source stewards — legal entities like foundations or companies that systematically sustain OSS projects intended for commercial use. Under Article 24 of the CRA, stewards must publish a coordinated vulnerability disclosure (CVD) policy and cooperate with ENISA and national CSIRTs. Article 64(10) shields stewards from administrative fines, but the obligations themselves are real. Any EU open-source steward without a published CVD policy is in formal non-compliance starting September 11.
SBOM: You Actually Need It Now, Not in 2027
The formal SBOM mandate doesn’t arrive until December 2027. Don’t let that fool you. You need an SBOM — in CycloneDX or SPDX format — before September 11, because without one you cannot identify which of your dependencies has a new CVE in time to meet the 24-hour reporting window. You are not reporting on a schedule. You are reporting the moment you become aware. You cannot become aware in time if you are manually auditing dependencies after the fact.
End-of-life dependencies compound this. If your product uses an EOL library and a new CVE is published against it and actively exploited, you must report — even if no patch exists from upstream. Eliminating EOL dependencies or getting extended commercial support for them closes that gap before September 11.
What to Do Before September 11
- Determine scope — Does your product qualify as a “product with digital elements” under the CRA? Check the EU’s official CRA summary.
- Register on the ENISA SRP now — Don’t wait for an incident. Contact cra-srp-helpdesk@enisa.europa.eu to onboard before the deadline.
- Generate an SBOM — Integrate CycloneDX or SPDX generation into your build pipeline today.
- Audit EOL dependencies — Replace or arrange extended support for any end-of-life components before September 11.
- Designate a responsible person — Someone must own the 24-hour reporting obligation before an incident happens.
- Write and publish a CVD policy — Required for open-source stewards; essential good practice for everyone.
- Test your incident response playbook — Run a drill before September 11. A tested plan beats an unread document every time.
The EU Cyber Resilience Act is not a future concern. It starts enforcing this week. The 24-hour window is an operational requirement, not a legal formality. Teams that treat it as a checkbox exercise are going to find out quickly that it isn’t one. The ENISA SRP is open for registration now — that’s where to start.
