10 days to CRA reporting: readiness check
CRA reporting readiness: a 7-question self-test before 11 Sep 2026, what 'actively exploited' means and what an early warning looks like.
Marius Gill6 min readDeutsche Fassung
In ten days, on 11 September 2026, reporting under Art. 14 of the Cyber Resilience Act begins. You are ready if you can tell within 24 hours whether an actively exploited vulnerability affects one of your products, and if it is settled who submits the early warning.
We covered deadlines and content in CRA reporting: the 24h/72h clock. This post is about practice: how to check your readiness in one hour.
Self-test: 7 questions
- Do you have a complete list of all products and versions made available in the EU – including older ones?
- Can you name the components in each of these versions (SBOM)?
- Is there a public contact point for vulnerability reports, and is it monitored?
- Do you watch sources of active exploitation, such as exploit catalogues and vendor advisories?
- Is it defined who decides on a report – with a deputy, including at weekends?
- Are templates ready for early warning, notification, final report and customer notice?
- Have you rehearsed the process once with a real example?
Roles and on-call
For mid-sized companies this does not have to be a 24/7 security operations centre. A named on-call rota with three roles is enough: technical assessment (are we affected?), decision (is it reportable?) and communication (report and customer notice). In small teams one person can hold several roles – what matters is the deputy.
What is an 'actively exploited' vulnerability?
The CRA defines it as a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission. A high CVSS score alone is not enough, nor is a research proof of concept.
KEV catalogues as a signal
The US CISA Known Exploited Vulnerabilities Catalog lists vulnerabilities with evidence of exploitation. It is not a legal yardstick for the CRA, but a good trigger for your assessment: if a component from your SBOM appears there, your team's clock should start.
Published CVEs per year
| 2021 | 20,700 CVEs |
|---|---|
| 2022 | 25,499 CVEs |
| 2023 | 29,232 CVEs |
| 2024 | 40,921 CVEs |
| 2025 | 49,421 CVEs |
The number of published vulnerabilities has more than doubled since 2021. Only a small share is actively exploited – but you need to find that share fast. Reading advisories by hand does not scale.
A sample early warning
The early warning is deliberately brief. A possible skeleton:
- Manufacturer and contact person
- Affected product and versions
- Type: actively exploited vulnerability or severe incident
- Time of awareness
- Member states where the product is made available (as far as known)
- Initial assessment and planned next steps
The reporting platform defines the exact fields. Keep this information ready so you can transfer it in minutes.
Status in Germany
The German government has tabled a draft CRA implementation act (Bundesrat printed paper 260/26 of 1 May 2026); the first reading in the Bundestag took place in June 2026. The draft designates the BSI as market surveillance and notifying authority. The reporting obligation itself follows directly from the EU regulation – it applies from 11 September regardless of the national act.
If a zero-day notice arrives on 12 September
Suppose that the day after the deadline the maintainer of a widely used library warns that a vulnerability is being actively exploited. Your process could look like this:
- Capture the signal: the warning reaches the agreed channel via monitoring or a customer. Note the time.
- Check exposure: use the SBOM to determine whether and in which product versions the library is included.
- Assess exploitability: is the affected function used in your product at all? Document the result.
- Decide: if an actively exploited vulnerability affects your product, submit the early warning within 24 hours.
- Prepare customers: formulate mitigation advice until a patch is available.
Minimum setup by company size
| Small software house | Mid-sized device maker | Agency | |
|---|---|---|---|
| On-call | Two people alternating | Rotation in the engineering team | Defined per client project |
| Inventory | List of products and versions | Product and firmware levels per customer | Projects with manufacturer role |
| Signal sources | Advisories of used ecosystems, KEV | Plus supplier notices | Framework and plugin advisories |
| Templates | Early warning, customer notice | Plus multiple languages | Hand-over to manufacturer |
Using the last ten days well
- Days 1–3: define inventory and roles, name deputies.
- Days 4–6: generate SBOMs for the most important products, check the contact point.
- Days 7–8: write templates and agree them internally.
- Days 9–10: run a drill with a real past example.
Common misunderstandings
- 'We report once the patch is ready.' No – the early warning is due regardless of the patch.
- 'Only new products are affected.' Reporting also covers legacy products.
- 'Our supplier reports for us.' The manufacturer of the product you place on the market is obliged to report.
Beta access for the incident workflow
Nuowei matches your SBOMs against exploit signals, shows affected product versions and prepares data for early warning and notification. The platform is in beta, launching November 2026 – beta access via the waitlist. The CRA compliance checklist covers the steps after the deadline.
No. Reporting follows directly from the EU regulation and applies from 11 September 2026.
Only if the vulnerability affects your product. The catalogue is a signal, not a legal definition.
No. A named on-call rota with clear roles and deputies is enough for many mid-sized companies.