Developer, not a lawyer. Every claim below has an article number so you can check it against the text of Regulation (EU) 2024/2847 on EUR-Lex. Not legal advice.
The short version
On 11 September 2026 the reporting obligations of the EU Cyber Resilience Act (CRA) started to apply. If you supply software commercially into the EU, and you become aware that a vulnerability in it is being actively exploited, you now owe ENISA an early warning within 24 hours, a notification within 72 hours, and a final report 14 days after a fix is available. That applies to a solo developer selling a game on Steam or an app on the App Store exactly as it applies to a large vendor, and it applies regardless of where you live.
The rest of the regulation (SBOM, CE marking, a security support period of at least five years, the conformity paperwork) applies from 11 December 2027. This article is about the part that is live now.
What the CRA is, in two paragraphs
Regulation (EU) 2024/2847 was published in November 2024 and entered into force on 10 December 2024. It sets cybersecurity requirements for "products with digital elements": software and hardware, and their remote data processing, whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network (Article 2(1), Article 3(1)). It is a product regulation in the CE-marking family, like the toy safety or radio equipment directives, and it is enforced by national market-surveillance authorities.
Article 71 staggers application. Most obligations: 11 December 2027. Chapter IV on notified bodies: 11 June 2026. Article 14, the manufacturer's reporting obligations: 11 September 2026.
Article 14: the three clocks
Article 14(1) says a manufacturer shall notify any actively exploited vulnerability contained in the product that it becomes aware of. The notification goes simultaneously to the CSIRT designated as coordinator in the relevant member state and to ENISA, through the single reporting platform ENISA operates under Article 16. Article 14(2) sets the timing:
- (a) an early warning within 24 hours of becoming aware, indicating at least the member states in which the product is available;
- (b) a vulnerability notification within 72 hours, with general information about the product, the nature of the exploit and the vulnerability, and the corrective or mitigating measures taken and that users can take;
- (c) a final report no later than 14 days after a corrective or mitigating measure is available, with a description of the vulnerability, its severity and impact, information about the actor if available, and details of the security update.
Article 14(3) to (5) apply the same 24-hour and 72-hour steps to "severe incidents having an impact on the security of the product", with a final report within one month. Article 14(8) adds that the manufacturer must inform impacted users without undue delay, and where appropriate all users, about the vulnerability and the measures they can take.
Nothing here requires you to have fixed anything within 24 hours. It requires you to have said something within 24 hours.
Who is a manufacturer
Article 3(13): the natural or legal person who develops or manufactures a product with digital elements, or has it developed or manufactured, and markets it under their name or trademark, whether for payment, monetisation or free of charge. The trigger is supply in the course of a commercial activity (Recital 15 and 18), which includes charging for the product, charging for support beyond cost recovery, or monetising through advertising or data collection.
So, in scope:
- A paid game on Steam, itch or a console store, from a studio of any size, in any country.
- A paid or ad/IAP-funded app on the App Store or Google Play.
- Desktop software you sell or license, including an Electron or Tauri client for a web service.
- Browser extensions, plugins, themes and SDKs supplied commercially.
- Self-hosted software your customers install.
- Firmware in any device you sell.
Location does not matter. The test is that the product is made available on the EU market. If a customer in Germany can buy it, it is.
Who is mostly not
Software as a service. Recital 12 states that the regulation is not meant to apply to SaaS. The exception is "remote data processing" (Article 3(2)): processing at a distance, designed and developed by the manufacturer, without which the product could not perform one of its functions. In practice: a web app used in a browser is out; a mobile app plus the backend it cannot work without is in, backend included; a desktop client for your SaaS is in.
Free and open-source software supplied outside a commercial activity (Recital 18 and 19). Publishing a library on GitHub under MIT does not make you a manufacturer. Selling a commercial licence or paid support for it does. Integrating it into your commercial product makes you responsible for it as a component (Article 13(5)).
Products already covered by sector rules: medical devices, motor vehicles, civil aviation, marine equipment (Article 2(2) to (4)), and products developed exclusively for national security or defence.
The definitional hinge: "actively exploited"
This is where most of the anxiety in developer forums is misplaced. The CRA does not ask you to report every CVE in your dependency tree. Article 3(42) defines an actively exploited vulnerability as one "for which there is reliable evidence that execution of malicious code was performed by an actor on a system without permission of the system owner".
That is materially narrower than "vulnerable" and has nothing to do with CVSS. A 9.8 with no observed exploitation does not start a clock. A 6.5 that is being used in the wild does, once you become aware.
For a dependency you ship, the earliest public evidence of exploitation is usually one of two things: the CVE being added to CISA's Known Exploited Vulnerabilities (KEV) catalog, or a vendor or CSIRT advisory that explicitly says "exploited in the wild". KEV's inclusion criteria (an assigned CVE, reliable evidence of active exploitation, and a clear remediation action) are close to the CRA's definition, which makes it the right feed to watch. It is not the only evidence, and a KEV listing for a library is not proof that your product is exploitable. It is the point at which a reasonable person starts finding out, fast.
What "becoming aware" means for a small team
The regulation does not define awareness. The sensible reading, and the one I would want to defend to an authority, is: when someone in your company knows, or when public information you could reasonably be expected to monitor says so about a component you ship. That second half is the practical problem. A three-person studio is not reading the KEV feed every morning, so the first they hear of an exploited vulnerability in their networking library is a customer, a journalist, or the authority.
The fix is not a document. It is a daily job.
Penalties, honestly
Article 64(1): non-compliance with the essential requirements in Annex I or the obligations in Articles 13 and 14 carries administrative fines of up to €15,000,000 or 2.5% of worldwide annual turnover, whichever is higher. Article 64(2): other obligations, up to €10,000,000 or 2%.
Article 64(10) carves out two things. Open-source software stewards are not fined. And microenterprises and small enterprises (under 10 staff and €2M turnover, or under 50 staff and €10M, per Recommendation 2003/361/EC) are not subject to fines for failing to meet the 24-hour deadline for the early warning specifically. The 72-hour notification and the 14-day final report still carry the full fines. Enforcement is by national authorities, and for a non-EU micro studio the realistic first consequence is a takedown request to the store or an information request, not a fine in the post. Neither is pleasant at hour 23.
A minimal, defensible process
Six things, all of which fit on one page:
-
Know what you ship. A lockfile or a CycloneDX SBOM per product, per release, stored with the release.
package-lock.json,Cargo.lock,go.sum,Package.resolved,gradle.lockfile,packages.lock.json,Podfile.lock, orsyft/cyclonedx-*output. An SBOM becomes an explicit requirement in December 2027 anyway (Annex I Part II). -
Check it against OSV.dev. OSV indexes npm, PyPI, crates.io, Go, Maven, NuGet, Packagist, RubyGems, Pub, Hex and Swift packages by repository URL. One
querybatchcall per thousand packages. -
Intersect with KEV. Take every finding's ID and aliases and match them against the
cveIDfield of the KEV JSON. Those matches, and only those, are candidate "aware" events. - Re-run daily. The clock runs on vulnerabilities that became exploited while you shipped nothing. On-push scanning does not catch that; a scheduled job does.
- Timestamp what you knew. Append-only: a commit, an object with a retention lock, an email to yourself. This is the evidence of when the 24 hours began.
- Pre-draft the early warning. Product name, version, the member states where it is sold, the vulnerability ID, a one-line description, contact details. Put the ENISA platform URL next to it. Calendar the 72-hour and 14-day follow-ups the moment you file.
The 40-line check
Here is the core of steps 2 and 3 in Node, for an npm lockfile. Adapt the parser for your ecosystem; the OSV and KEV parts are the same everywhere.
import fs from "node:fs";
const lock = JSON.parse(fs.readFileSync("package-lock.json", "utf8"));
const queries = Object.entries(lock.packages ?? {})
.filter(([p, v]) => p && v.version)
.map(([p, v]) => ({ package: { name: p.split("node_modules/").pop(), ecosystem: "npm" }, version: v.version }));
const kev = await fetch("https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json").then(r => r.json());
const exploited = new Set(kev.vulnerabilities.map(v => v.cveID));
const hits = [];
for (let i = 0; i < queries.length; i += 1000) {
const chunk = queries.slice(i, i + 1000);
const res = await fetch("https://api.osv.dev/v1/querybatch", { method: "POST", body: JSON.stringify({ queries: chunk }) }).then(r => r.json());
res.results.forEach((r, j) => (r.vulns ?? []).forEach(v => hits.push({ pkg: chunk[j], id: v.id })));
}
for (const h of hits) {
const vuln = await fetch(`https://api.osv.dev/v1/vulns/${h.id}`).then(r => r.json());
const ids = [vuln.id, ...(vuln.aliases ?? [])];
const onKev = ids.filter(id => exploited.has(id));
if (onKev.length) console.log("EXPLOITED", h.pkg.package.name, h.pkg.version, onKev.join(","), new Date().toISOString());
}
Run it from cron every morning and pipe the output somewhere you cannot edit quietly. That is most of the control. If you would rather not run it yourself, I built a free web version: paste any lockfile at crawatch.dev, no signup, and it does the OSV and KEV steps and gives you a shareable result page. There is a paid daily-watch version with the countdown and the early-warning draft; the free scan is the part most people need today.
What to do this week if you are in scope
- Produce the dependency list for each product you sell in the EU.
- Run the check once. If nothing is on KEV, write that down with the date; that is also evidence.
- Write the one-page incident procedure: who owns the 24 hours, where the ENISA platform is, the three deadlines, the draft.
- Put a security contact on your website and store page. A coordinated vulnerability disclosure policy and a contact address become explicit requirements in December 2027 (Annex I Part II), and you want the address to exist before someone needs it.
- If you are a pure SaaS, read Recital 12, exhale, and check whether you ship a client.
Open questions I would like answers to
How coordinating CSIRTs will treat a KEV hit in a transitive dependency your product never calls. Whether Apple, Google and Valve will be treated as distributors under Article 20, with their own duties to act on non-conforming products. And whether anyone has yet filed through the single reporting platform and can say what the form actually asks for. If you know, the comments are open, or hello@crawatch.dev.
CRA Watch is run by one developer who read the regulation. Not legal advice.
