Meet the Cyber Resilience Act without a security team.

What is the Cyber Resilience Act, and who does it apply to?

The Cyber Resilience Act (CRA) is Regulation (EU) 2024/2847, the EU law on cybersecurity requirements for products with digital elements. It applies to hardware with software and to software products placed on the EU market, and its obligations fall mainly on their manufacturers, whatever their size. Sectors with their own rules, such as medical devices, motor vehicles and civil aviation, are excluded, and pure software-as-a-service without a product is generally outside it. The regulation entered into force on 10 December 2024.

CRA reporting obligations in detail →

Source: Regulation (EU) 2024/2847, EUR-Lex, Cyber Resilience Act, European Commission

What is the CRA reporting obligation?

Since 11 September 2026, manufacturers must report every actively exploited vulnerability in their product and every severe incident affecting its security - also for products already on the market. An early warning is due within 24 hours of becoming aware, a notification within 72 hours, and a final report at the latest 14 days after a fix is available (vulnerabilities) or within one month of the notification (incidents). Reports go through ENISA's single reporting platform to the coordinating CSIRT and to ENISA; the platform has no API for manufacturers, so each report is submitted by hand in the browser.

CRA reporting: triggers, deadlines, recipients → Watch: The CRA reporting workflow (4 min)

Source: Regulation (EU) 2024/2847, Article 14, EUR-Lex, ENISA

How do you create an SBOM?

Generate it automatically in your build pipeline instead of writing it by hand. Use one of the two widely used machine-readable formats, CycloneDX or SPDX, and create one SBOM per released version. Generators exist for most ecosystems, for example Syft or cdxgen for containers and file systems, the CycloneDX plugins for Maven, Gradle and npm, and the SPDX output of the Yocto Project for embedded Linux.

1. Choose the format. CycloneDX or SPDX - both are machine-readable.
2. Generate it in CI. Run the SBOM generator for your ecosystem on every release build.
3. Keep one SBOM per release. Store it with the release as part of the technical documentation.
4. Check it against vulnerability data. Kernwatch checks components with a package identifier (purl) daily on paid plans, weekly on Free.

SBOM for the CRA → Watch: Products, releases and SBOMs (4 min) Watch: Upload SBOMs from CI with an API key (2 min)

Source: CycloneDX specification, SPDX specification

When does the CRA make an SBOM mandatory?

The SBOM belongs to the CRA requirements that apply from 11 December 2027: from then on, products with digital elements need CRA conformity and CE marking to be placed on the EU market. Annex I requires an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies. It is part of the technical documentation - it need not be published, but market surveillance authorities can request it. Since reporting started on 11 September 2026, a current SBOM is also the quickest way to tell whether an exploited vulnerability affects your products.

What the CRA requires of an SBOM →

Source: Regulation (EU) 2024/2847, Annex I, EUR-Lex

What does a CRA vulnerability reporting tool do?

It turns monitoring results and deadlines into tasks. In Kernwatch, a finding on a list of actively exploited vulnerabilities becomes an action-inbox task to open a reporting case due 24 hours after you became aware, and the early warning, notification and final report are drafted from your product, release and triage data for your sign-off. You submit on ENISA's platform yourself and record the reference; when a newer release no longer contains the vulnerable version, Kernwatch proposes the fix date that starts the 14-day final-report clock. Tasks appear on every plan; approving reporting cases and reports needs Starter or above.

Plans and prices → Watch: The action inbox (6 min)