CRA reporting started on 11 September 2026 - what a 15-person ISV actually has to do

Written 8 August 2026, updated 15 September 2026. Every claim below is dated, because two of them were going to change within weeks - and one of them has. Superseded passages are kept as quotations rather than deleted, so you can see what changed.

The Cyber Resilience Act has two dates that matter. The one everyone talks about is 11 December 2027: CE marking, technical documentation, conformity assessment. The one that arrives first is 11 September 2026 and it is the one with teeth for a small vendor, because it applies to products you have already shipped.

From that date, Article 14 obliges manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform. No CE marking involved, no notified body, no transition period for existing products. If you sell software in the EU and a vulnerability in it turns out to be under active exploitation, a clock starts.

The clock

Three deadlines, from Article 14(2):

• 24 hours from becoming aware - an early warning to the CSIRT designated as coordinator for the Member State of your main establishment and to ENISA, simultaneously.
• 72 hours - a vulnerability notification: what it is, what you know, what corrective or mitigating measures you are taking.
• 14 days - a final report. Note the start of that count: not 14 days from awareness, but 14 days after a corrective or mitigating measure is available.

Severe incidents run on the same 24 h / 72 h rhythm under Article 14(4), with the final report due one month after the notification rather than 14 days.

"Aware" is doing a lot of work in that first line. Article 3(42) defines an actively exploited vulnerability as one for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission. In practice, for a small vendor, that evidence usually arrives as a CVE appearing in CISA's Known Exploited Vulnerabilities catalogue - for a package three levels deep in your dependency tree.

The obligation nobody puts on the slide

Article 14(8) requires you to inform affected users about the vulnerability or incident and about any corrective measures - and where necessary, in a structured, machine-readable format. This is not a filing. No tool discharges it for you. If your answer to "how do we tell our customers" is "we email whoever we can remember", that is the gap to close first, because it is the only one that needs a decision from a human being rather than a purchase.

Does it apply to you at all?

Two boundaries decide it and both were clarified this year.

Pure SaaS is generally outside the CRA. The regulation covers products with digital elements and Article 3(1) includes a product's "remote data processing solutions" - defined in Article 3(2) as processing at a distance, designed by or under the responsibility of the manufacturer, the absence of which would prevent the product from performing one of its functions. Commission guidance approved on 27 July 2026 (C(2026) 5252, formal adoption still pending the remaining language versions as of this writing) puts it plainly: where the software runs decides. A web application reached only through a browser is generally not a product. A mobile banking app with a backend it cannot work without is one product, backend included.

So: if you sell a hosted service and nothing runs on your customer's device, the CRA is probably not your regime - NIS2 is the one to check. If you ship anything that executes on someone else's hardware, you are in.

Non-commercial open source is outside - through a definition, not an exemption. This one is worth stating carefully, because a lot of published summaries get it wrong and cite "Article 2(6)". Article 2(6) is about spare parts. There is no FOSS exemption in Article 2 at all. The carve-out works like this: Article 2(1) applies the regulation to products made available on the market and Article 3(22) defines that as supply "in the course of a commercial activity, whether in return for payment or free of charge". Recitals 18–19 then explain that free and open-source software which its manufacturer does not monetise is not a commercial activity and that how the development was financed does not matter.

Monetise your open-source project - support contracts, a paid tier, anything - and you are supplying it commercially. Note the compensation, though: Article 32(5) lets important open-source products use the lighter Article 32(1) conformity procedures, provided the technical documentation is public.

Class matters less than you think - for now

Article 7 and Annex III sort "important" products into class I (19 categories) and class II (4 categories); Annex IV lists 3 critical categories. Implementing Regulation (EU) 2025/2392, adopted 28 November 2025, gives each category a technical description and the decisive test is your product's core functionality - the primary purpose it is on the market for, not a feature it happens to include.

Your class decides the 2027 conformity route: self-assessment for default-class products, notified body for class II, a certification scheme for Annex IV. It decides nothing about the September deadline. Article 14 applies to every product in scope, in every class. "We're not class I, so this doesn't apply to us" is the most expensive sentence in this whole regime.

All 26 categories, with the route each one implies and the annex point it comes from, are listed under the scope classifier.

The platform you have to report to went live the same day the duty did

Update, 15 September 2026. The Single Reporting Platform is open. ENISA deployed its initial operating capability on 11 September 2026 - the same day Article 14 started binding - and manufacturers file through portal.cra-srp.enisa.europa.eu. Registration is still for assigned representatives, and ENISA still asks manufacturers to register when filing a specific notification rather than in advance. This is one of the two claims the top of this article said would change within weeks.

What follows is what was true on 8 August 2026, kept rather than deleted because the advice in it never depended on the platform being open:

As of 8 August 2026, the Single Reporting Platform is not open. ENISA's own page says it will be used by CSIRTs and manufacturers "as of 11 September 2026 onwards". What does exist is guidance for assigned representatives - user registration and submitting and updating notifications - both updated 31 July 2026.

That is not a reason to wait. It means the part you can do now is the registration path and the internal plumbing and the part you cannot do now is rehearse against the real form. Nobody has seen a published technical schema for a report. If a vendor is selling you an API integration with the SRP today, ask them what they are integrating against.

What to actually have in place

Nothing here needs a budget approval.

1. An SBOM per product version, in a machine-readable format. Annex I Part II(1) requires identifying and documenting components, "including by drawing up a software bill of materials in a commonly used and machine-readable format". CycloneDX or SPDX JSON, generated in CI - there is a generate step per stack for Maven, Gradle, npm, pip, Go, Cargo, NuGet, Bundler, Composer and Mix. Two minutes of pipeline work.
2. Package identifiers on those components. A CVE maps to a package URL. Components identified by name only get matched by heuristics, which means both misses and false alarms on the day it matters. Measure your purl coverage before you need it - the ecosystems and purl types we match against are the ones where a version turns into an advisory.
3. A monitored inventory. Awareness is what starts the clock, so decide where it comes from: NVD, OSV and CISA KEV as the exploitation signal. If awareness reaches you through a customer, you have already lost hours of the 24.
4. A named owner and a deputy. The first deadline is 24 hours including weekends. An unassigned duty is missed by default.
5. Your CSIRT coordinator, looked up in advance. Reports go to the CSIRT of your main establishment's Member State and to ENISA (Article 14(7)). This is a five-minute lookup that should not happen during hour one of an incident.
6. A CVD policy and a contact address. Annex I Part II(5) and (6). A security.txt and a page saying where to report and what to expect - ours is here if you want a worked example to copy.
7. A way to notify affected users - Article 14(8), above.

Check your own inventory in CI

We built the readiness check as a free GitHub Action, because the argument above is easier to believe against your own dependency list than in the abstract. Point it at the SBOM your build already produces:

- uses: actions/checkout@v4
- run: npx @cyclonedx/cdxgen -o sbom.json .
- uses: mmalinowski/cradesk-action@v1
  with:
    sbom-path: sbom.json

It reports what your SBOM does and does not tell you - component count, purl coverage, whether dependency relationships are recorded - and the readiness items above, with the provision behind each one. Nothing leaves the runner. Where a check rests on practice rather than on an operative provision, it says so, because "the act requires purls" would be a claim we cannot cite.

If you want the scope question answered first, the classifier runs in your browser and cites its reasoning.

This is a compliance aid, not legal advice. The obligations rest with the manufacturer. Product classes may be refined by further implementing acts and the guidance cited above was still awaiting formal adoption when this was written - check the rules version stamped on any verdict you rely on.