Cyber Resilience Act for software makers: setting up SBOM, vulnerability handling and the 24-hour report

The reporting duties have applied since 11 September 2026. This guide shows how to set up SBOM, vulnerability handling and reporting so that they work in day-to-day practice.

Does the CRA apply to my software?

The CRA covers products with digital elements made available on the EU market: software and hardware including firmware, whether sold on its own or as part of a device. Desktop programs, mobile apps and libraries you distribute commercially are covered too. This also applies to makers outside the EU whose products are sold in the EU.

Three borderline cases deserve a close look:

Open source: free software developed outside a commercial activity is not covered. If you build open source into a commercial product, you are responsible for the whole product, including the components you took over.
Pure SaaS: a service that runs only in the browser and is not part of a product is generally not covered by the CRA, but may fall under NIS2. If a cloud function belongs to a product, such as controlling a device via an app, it is part of that product.
Important and critical products: stricter conformity assessment procedures apply to certain product classes, such as password managers, VPNs, firewalls or operating systems.

The free applicability check gives a first assessment for your company.

Since 11 September 2026: reporting within 24 hours

Since 11 September 2026, manufacturers must report two kinds of events (Art. 14 CRA), also for products that were already on the market before that date:

actively exploited vulnerabilities in their product,
severe incidents that affect the security of the product.

Reports go through ENISA's single reporting platform to the competent CSIRT. They come in stages:

Stage	Actively exploited vulnerability	Severe incident
Early warning	within 24 hours	within 24 hours
Notification	within 72 hours	within 72 hours
Final report	no later than 14 days after a corrective or mitigating measure is available	within one month of the notification

The clock starts when you become aware, not when your analysis is finished. In addition, you inform the affected users of your product about the vulnerability or incident and about measures they can take themselves.

The free CRA reporting deadline calculator works out which deadlines apply in your case.

The reporting clock starts when you become aware. Prepare the process before the first case.

From 11 December 2027: all remaining duties

From 11 December 2027, only products that meet all CRA requirements may be placed on the market:

Essential requirements (Annex I): secure default settings, protection against unauthorised access, security updates, vulnerability handling throughout the support period.
Technical documentation: risk assessment, product description, SBOM, evidence of testing.
Conformity assessment: for most products as a self-assessment, for important and critical products with stricter procedures, partly by a notified body.
EU declaration of conformity and CE marking.
Support period: you set how long you deliver security updates, as a rule at least five years.

The time until then sounds long. For a product with several releases a year, however, it is only a few development cycles.

SBOM in practice

A software bill of materials (SBOM) lists every component of your product with version and origin. The CRA requires it explicitly (Annex I, Part II(1) CRA), and it belongs in the technical documentation.

Format. CycloneDX and SPDX are established. BSI TR-03183-2 (version 2.1.0), the German technical guideline on SBOMs, accepts CycloneDX from version 1.6 and SPDX from version 3.0.1.

Depth. At least the direct dependencies, preferably the transitive ones too. An SBOM that only shows the top level does not help with the next vulnerability in a deeply embedded library.

Currency. Generate the SBOM automatically in the build for every release, not once a year by hand. Every shipped version needs its own SBOM.

Linking. An SBOM pays off only when you match it against vulnerability data: which of my shipped versions contains the affected component?

An SBOM is only useful if it is current and linked to vulnerability data.

Handling vulnerabilities: the process

Intake: vulnerabilities reach you from databases such as CVE, from your suppliers' advisories, through your reporting address or from your own testing. Publish a contact address and a coordinated vulnerability disclosure policy.
Assessment: is your product affected, in which versions, how severely? Is the vulnerability actively exploited? Then the 24-hour deadline is running.
Fix: develop, test and ship a security update. Where possible, separately from feature updates.
Advisory: publish fixed vulnerabilities with a description, affected versions, severity and remediation, machine-readable, for example as CSAF.
Customer notice: affected users learn what to do, and you can show later that you informed them.

Roles and on-call

Settle who does what before the first case:

Who reports? A named person with a deputy who has access to the reporting platform.
Who decides? Whether a vulnerability is actively exploited or an incident is severe is decided by someone with authority, at weekends too.
Who informs customers? Product management, support or communications, with agreed text blocks.

Many manufacturers bundle these tasks in a product security incident response team (PSIRT). In small teams, two or three people with clear responsibilities and a reachable on-call rota are enough.

CRA work is product work. It belongs in the release process, not in a yearly audit.

How Complass helps

CRA framework: requirements step by step, with explanations and templates.
SBOM per product: export as CycloneDX 1.6 and SPDX 3.0.1.
Vulnerability management: with CVE data, CSAF advisories and vendor advisories, matched against your products.
Incidents with deadlines: Complass tracks the deadlines under Art. 14(1) and 14(3) CRA, NIS2 and the GDPR and prepares the content. You submit the report yourself through the reporting platform.
CRA security notices and PSIRT: write advisories, publish them as CSAF, send them to your users and keep proof of dispatch.
Free CRA reporting deadline calculator on our website, no sign-up.

Request a demo Calculate CRA reporting deadlines

Checklist

Checked which products fall under the CRA and in which class.
Person responsible for reporting named, with a deputy; access to the reporting platform settled.
Process for the 24-hour early warning described and rehearsed once.
Contact address and coordinated vulnerability disclosure policy published.
SBOM generated automatically with every release, in CycloneDX or SPDX.
SBOM matched against vulnerability data continuously.
Security advisories published machine-readable (e.g. CSAF).
Users can be informed about vulnerabilities and incidents.
Support period set for each product.
Plan for technical documentation and conformity assessment by 11 December 2027 in place.

Deadlines at a glance

Date	What applies
11 September 2026	Reporting duties under Art. 14 CRA, also for products already on the market
11 December 2027	All remaining duties: essential requirements, technical documentation, conformity assessment, CE marking
On becoming aware	Early warning within 24 hours, notification within 72 hours
After the fix or the notification	Final report: 14 days (vulnerability) or one month (incident)

Not legal advice. This guide gives a general overview and does not replace an assessment of the individual case.