The Complete Guide to the EU Cyber Resilience Act (CRA)

The Cyber Resilience Act (Regulation (EU) 2024/2847) is the EU's cybersecurity law for products with digital elements. It entered into force on 10 December 2024 to address two primary concerns: the low baseline security of connected products, and the lack of information users need to select and operate them safely. Its premise is that any connected product can be an attacker's entry point, so the baseline applies broadly rather than to a narrow list of critical software.

Critically, any organisation placing hardware or software on the EU market commercially is in scope (except for those with certain exemptions, such as pure SaaS, medical devices, aviation, marine equipment, and non-commercial open source open source), even those headquartered outside of the EU. Additionally, importers and distributors inherit manufacturer obligations when they brand or substantially modify a product (or integrate OSS into a commercial product); OSS stewards also face certain CRA obligations.

The first set of CRA requirements took effect on 11 September 2026. These cover reporting procedures for actively exploited vulnerabilities and severe security incidents. The second set of requirements, which includes vulnerability handling processes, SBOMs, secure-by-default configuration, and more, will take effect on 11 December 2027. Products placed on the EU market after this date will need to satisfy the CRA conformity requirements and bear the CE mark.

The CRA phases in over three years. The reporting mandate is already live; remaining requirements follow in December 2027.

Article 14 of the CRA, which took effect on 11 September 2026, includes the vulnerability and security incident reporting requirements. Organisations are now required to report actively exploited vulnerabilities and severe security incidents to ENISA within 24 hours, with additional documentation required at the 48-hour mark, and a final report within the weeks that follow. If you haven't already, appoint a primary and up to 20 secondary Assigned Representatives on ENISA's platfor who will manage the reporting process on your behalf. Additionally, ensure you put in place an incident response workflow that can produce the three distinct reports required by the CRA.

As you ensure compliance with Article 14, it's also wise to focus on preparing for the next set of CRA requirements, which will take effect on 11 December 2027. These include secure-by-design defaults, automated machine-readable SBOMs, a defined security support period, and security updates decoupled from feature releases.

Read More: EU CRA Compliance Timeline

Every in-scope product must meet the same Annex I requirements. What changes by tier is the conformity assessment route, which is determined by the product class.

Classification resolves to four questions, answered in order:

1. Is the product in scope? A product with digital elements, placed on the EU market commercially, not carved out by sectoral rules. (Or, put differently: hardware or software products that are capable of communicating with other hardware or software, except for those that are specifically exempted.)
2. Does its core functionality match an Annex IV category? → Critical.
3. Does its core functionality match an Annex III category? → Important, at the class the annex assigns.
4. Otherwise → Default.

Read More: CRA Product Classification Explained

Article 14 reporting has applied since 11 September 2026 and is broader than the 2027 obligations in one critical respect: it covers every in-scope product already on the EU market, including products sold years before the CRA existed, and it persists after the support period ends. It applies to all four product classes.

There are two independent triggers for reporting: an actively exploited vulnerability (reliable evidence a malicious actor has exploited it without the owner's permission) or a severe incident affecting the product's security. An incident can qualify with no underlying vulnerability at all, such as a compromised build pipeline, stolen signing key, or hijacked update server.

All notifications must go through ENISA's Single Reporting Platform. Email and national portals don't satisfy the obligation. When using the SRA, you select the coordinating CSIRT for your Member State of main establishment (where cybersecurity decisions are predominantly made), and one notification per event covers the whole group.

There several important nuances to be mindful of as you consider your reporting workflows:

Read More: Meeting the CRA's 2026 Reporting Requirements

The CRA requires manufacturers to identify and document components, including by creating an SBOM in a "commonly used and machine-readable format covering at the very least the top-level dependencies of the product."

Although we have a general idea of the required level of SBOM depth, details of the SBOM requirement have not yet been published. For example, it's unclear whether certain data fields (e.g. licence information, component hash, and more) will be mandated. Article 24 gives the Commission implementing powers to specify SBOM format and elements, and CEN/CENELEC is drafting standards. The clearest directional guidance today is BSI TR-03183 Part 2 Version 2.1 (released in March of 2025), which is a recommendation rather than a requirement.

Ultimately, given the current uncertainty, it's best to focus on SBOM foundations that will allow you to meet whatever the implementing acts specify with configuration changes rather than a new programme. This includes the ability to generate a machine-readable SBOM on every build, the ability to ingest and the ability to control the distribution of the SBOM to relevant parties.

Read More: SBOM Requirements in the EU's Cyber Resilience Act

Several leading European manufacturers use FOSSA to manage SBOMs, vulnerabilites, license compliance automation, and regulatory reporting. FOSSA's platform covers the operational core of CRA readiness:

This guide is directional guidance for planning, not legal advice. Consult qualified counsel for a formal conformity determination. Primary sources: Regulation (EU) 2024/2847 (EUR-Lex), the European Commission's CRA policy page, and ENISA.