The EU put a 24-hour clock on your side project's vulnerabilities

On September 11, 2026 — three weeks ago as I write this — the EU Cyber Resilience Act's reporting obligations went live. If you ship software into the EU, you are now a "manufacturer" with a legal clock: an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure (or one month for a severe incident). All filed through ENISA's Single Reporting Platform.

A late-September Bitkom survey of 1,003 German companies found only 29% understand what the CRA means for their own business, and 28% have never heard of it at all. If you're a solo dev shipping an app, you're probably in the 71%.

Does this apply to you?

The CRA covers "products with digital elements": software whose foreseeable use involves a data connection. Mobile apps, desktop apps, browser extensions, Electron apps, plugins, firmware, container images — yes. It applies regardless of where you're headquartered, and it covers products already on the market, not just new launches.

Pure SaaS (everything runs on your servers, users only see a website) is generally out — that's a different regime. But if your SaaS ships a downloadable client, mobile app, or agent, that component is in scope. Commercial open source is in; pure non-commercial open source is out.

The part everyone gets wrong

The 24-hour clock does NOT start when you first hear a rumor. Per Commission guidance, it starts when an initial assessment gives you reasonable certainty of active exploitation or a severe incident — not on first suspicion, not on a scanner finding. And every CVE in your dependency tree is not a 24-hour event: presence ≠ exploitation. Only actively exploited vulnerabilities and severe incidents are reportable.

The solo-dev setup (do this week, not during an incident)

1. One intake channel. A security@ address plus a SECURITY.md in every repo. The clock starts while you're searching inboxes if reports scatter.
2. A 15-minute triage checklist. Is it my product? Is there evidence of active exploitation? How many users affected? Write it down — this log entry is your "awareness timestamp," and every deadline counts from it.
3. Pre-written drafts. Your 24-hour early warning, 72-hour notification, and user notice, written now while you're calm. Filing should take 20 minutes at 2am, not 20 hours.
4. ENISA platform readiness. EU Login accounts for you and one backup person. Know your CSIRT routing now (if you have no EU establishment, there's a decision tree — work it out in advance).
5. A dated evidence log. Product inventory, your role per product, every intake record, every filing with timestamps. If a regulator ever asks, this is your answer.

The honest framing: enforcement against tiny indie teams is unlikely to be anyone's first priority. But the duty is live now, and "we had no process" is the worst possible position during an actual incident.

The five mistakes I keep seeing

1. Treating every CVE as a 24-hour event (burns credibility with the CSIRT).
2. No intake channel — reports arrive via DMs and forgotten inboxes.
3. "I'm too small to matter" (the duty applies regardless of size).
4. Designing the process during the incident.
5. Forgetting to inform users — if you don't, the CSIRT can do it for you, and their version will be worse for your reputation.

Disclosure: I build small compliance kits for indie devs. This article's playbook is expanded in my $29 CRA 24-Hour Reporting Kit — the manufacturer decision tree, the full reporting cascade, what counts as reportable, the solo intake pipeline, copy-paste filing drafts for each stage, the ENISA walkthrough, and the evidence-log template: https://8286544375711.gumroad.com/l/cra-reporting-kit