EU Cyber Resilience Act: the 24-hour reporting rule for small software vendors

From 11 September, you have 24 hours

Somewhere in your product, right now, there's a dependency you haven't thought about since the sprint you added it in. From 11 September 2026, that dependency can start a clock.

That's the day Article 14 of the EU Cyber Resilience Act takes effect. From then on, if a vulnerability in software you ship is being actively exploited, you must send an early warning to ENISA, the EU's cybersecurity agency, within 24 hours of becoming aware of it. A fuller notification follows within 72 hours, and a final report within 14 days.

Not for new products. For products already on the market. The penalty ceiling is €15 million or 2.5% of global turnover, whichever is higher.

I've spent the past week talking to founders of small European software companies about this, and the pattern is consistent: the enterprise world has known this was coming for two years, and the ten-person ISV has never heard of it.

"We're too small for this to apply to us"

That was my first reaction too. It's wrong in an interesting way.

The CRA covers "products with digital elements" sold in the EU. Installable software, firmware, connected devices, the software inside hardware. There is no small-vendor exemption. A two-person shop shipping a desktop tool is covered the same way Siemens is.

One honest caveat, because you'll read confident claims in both directions: whether pure SaaS is in scope is genuinely contested. The regulation targets products; pure cloud services mostly fall under other rules (NIS2, mainly). If you ship anything a customer installs or runs (an agent, an on-prem component, a plugin, a device) the ambiguity doesn't help you. You're in.

The 24-hour obligation is also narrower than it sounds, and that narrowness is what makes it survivable: it's triggered by actively exploited vulnerabilities. Not every CVE. Not every Dependabot ping. The ones attackers are using in the wild, the kind that end up in CISA's Known Exploited Vulnerabilities catalog, which is a short, brutal list, not a firehose.

The real problem isn't reporting. It's knowing.

Filing a report to ENISA is a form. The hard part is everything before the form: how would you even know, within 24 hours, that something you shipped three years ago just became actively exploited?

You can't answer that question without being able to answer a simpler one first: what is in your product?

I ran one of our own older codebases through this lens, a CMS we built years ago. Twenty-odd dependencies. A mail library pinned to a 2020 version with known CVEs against it. And no lockfile committed at all, which means no way to prove what versions we actually shipped to anyone. That last one stung, because it's not a vulnerability, it's something worse. It's not being able to say.

That's the state of most small-vendor codebases, including well-run ones. Nobody budgeted for a software bill of materials in 2019. The CRA now assumes you have one: the full obligations landing on 11 December 2027 make SBOMs, secure-by-design processes and CE marking mandatory. September's reporting rule is just the first tremor.

So I built a radar for it, in about 24 hours

The symmetry was too good to pass up: a 24-hour rule deserved a 24-hour build.

CRAIR — CRA Incident Radar takes a repository or a lockfile and produces a two-page CRA Readiness Snapshot: what's in your product, which of those components have known vulnerabilities, and the part that actually matters for Article 14, which of them are being actively exploited right now, cross-referenced against CISA KEV and scored with EPSS exploit probabilities. Plus the thing you'd have to tell ENISA tomorrow, drafted.

Two design decisions, because they're the whole philosophy:

Exploited beats exhaustive. A report listing 200 CVEs is a report nobody reads. The snapshot leads with the three findings that are on the KEV list, because those are the ones with a legal clock attached. The rest is appendix.

A missing lockfile is a finding. If your manifest only has version ranges, the snapshot says so, prominently. Committing a lockfile is the single cheapest CRA-readiness step that exists, and almost nobody frames it that way.

What to do this week, with or without any tool

1. Commit your lockfiles. composer.lock, package-lock.json in the repo, today. Reproducibility is the foundation everything else stands on.
2. Produce an SBOM for one product. Any generator will do. The first one is uncomfortable; that's the point.
3. Check yourself against CISA KEV. It's a public JSON file. If anything you ship is on it, you've just rehearsed September 11th.
4. Name the owner. The 24-hour clock starts on awareness. Someone at your company needs to be the person who becomes aware. Decide who, in writing.

Or let the radar do all four: crair.app runs a free Readiness Snapshot against any public repo or uploaded lockfile. It takes about a minute. Continuous monitoring, the part that watches KEV so you don't have to, is €99 a month.

Fifty-six days, as I write this.

A Readiness Snapshot is an automated assessment built on public vulnerability data (OSV, CISA KEV, FIRST EPSS). It is not legal advice and not a conformity assessment under the CRA.