EU Cyber Resilience Act: timeline, SBOM rules and a checklist

The EU Cyber Resilience Act (CRA) is Regulation (EU) 2024/2847. It sets security rules for "products with digital elements": software and hardware sold or supplied on the EU market. If your team ships software that people in the EU buy, download or install, it probably applies to you. Its first hard deadline has already passed: since 11 September 2026, manufacturers must report actively exploited vulnerabilities within 24 hours.

This page sets out the dates, who the law covers, what it asks of software teams, what it says about SBOMs, and a checklist. It goes deeper on one part of What is software supply chain security?.

Not legal advice. This is a plain-language summary of the regulation's text, written for engineers. It is not legal advice. Whether and how the CRA applies to your products depends on facts we don't know. Read the regulation on EUR-Lex and talk to a qualified lawyer.

The timeline

Every date below comes from Article 71 and Article 69 of the regulation as published in the Official Journal.

Two details matter for products already on the market:

• Reporting covers old products too. The Article 14 reporting duties apply to every in-scope product, including those placed on the market before 11 December 2027 (Article 69(3)).
• The other requirements don't, unless you change the product a lot. A product placed on the market before 11 December 2027 is only subject to the rest of the regulation if it gets a "substantial modification" from that date (Article 69(2)).

Who it covers

The CRA applies to products with digital elements made available on the EU market whose intended or reasonably foreseeable use includes a data connection to a device or network (Article 2(1)). A product with digital elements is "a software or hardware product and its remote data processing solutions" (Article 3(1)).

The roles you are most likely to hold:

• Manufacturer. Anyone who develops or manufactures a product, or has it made, and markets it under their own name or trademark, "whether for payment, monetisation or free of charge" (Article 3(13)). Most of the obligations fall here.
• Open-source software steward. A legal person, other than a manufacturer, that provides sustained support for free and open-source software intended for commercial activities, such as some foundations. Stewards have a lighter regime: a documented cybersecurity policy and cooperation with authorities (Article 24), and they can't be fined under the CRA (Article 64(10)).
• Importers and distributors have their own, smaller set of duties.

Three boundaries that come up often for software teams:

• Commercial activity. The rules apply to products supplied "in the course of a commercial activity, whether in return for payment or free of charge" (Article 3(22)). Recital 15 gives examples of what counts, such as charging for support beyond cost recovery or monetising through a platform.
• SaaS is mostly outside. Recital 12 says cloud services such as SaaS, PaaS and IaaS fall under the NIS 2 Directive instead. But remote data processing that a product needs in order to work is part of that product: the regulation's own example is a mobile app that needs an API or database run by the manufacturer.
• Some sectors have their own rules. Medical devices, in vitro diagnostics, vehicle type-approval and certified aviation products are excluded (Article 2(2) and 2(3)).

What applies now: reporting

Since 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability in its product, or a severe incident affecting its security, must notify both the national CSIRT designated as coordinator and ENISA, through the single reporting platform (Article 14(1), 14(3) and 14(7)).

An incident is "severe" if it harms, or can harm, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or if it led or can lead to malicious code running in the product or the user's systems (Article 14(5)).

The notification goes to the CSIRT of the Member State where you have your main establishment in the EU: where decisions about your products' cybersecurity are mostly taken (Article 14(7)). If you have no establishment in the EU, Article 14(7) sets the order to follow, starting with where your authorised representative is.

What this means in practice: 24 hours starts when you become aware, not when you finish investigating. Somebody must be able to decide, at any hour, whether a report is about an actively exploited vulnerability and send the early warning. That is a process and an on-call question more than a tooling one.

What applies from 11 December 2027

From December 2027, products placed on the market must meet the essential requirements in Annex I, and manufacturers must meet the obligations in Article 13. For software teams the main ones are:

Security of the product (Annex I, Part I). Based on a documented risk assessment, products must ship without known exploitable vulnerabilities, with a secure default configuration, with a way to fix vulnerabilities through security updates (automatic by default where applicable, with an opt-out), with access control, encryption of relevant data at rest and in transit, integrity protection, data minimisation, a limited attack surface, security logging, and a way for users to delete their data.

Vulnerability handling (Annex I, Part II). Manufacturers must:

1. identify and document vulnerabilities and components, including with an SBOM (more on this below);
2. fix vulnerabilities without delay, with security updates kept separate from feature updates where technically feasible;
3. test and review the product's security regularly;
4. publish information about fixed vulnerabilities once an update is out;
5. have and enforce a coordinated vulnerability disclosure policy;
6. provide a contact address for reporting vulnerabilities;
7. distribute updates securely, automatically where applicable for security updates;
8. ship security updates without delay and, as a rule, free of charge, with advisory messages.

A support period. You must handle vulnerabilities for a support period that reflects how long the product is expected to be in use. It must be at least five years, unless the product is expected to be in use for less (Article 13(8)).

Risk assessment and documentation. You assess the product's cybersecurity risks, keep that assessment up to date during the support period, and include it in the technical documentation (Article 13(2) to 13(4), Article 31 and Annex VII).

Your dependencies are your problem. You must exercise due diligence when integrating third-party components, including open-source ones (Article 13(5)). If you find a vulnerability in a component, you report it to whoever maintains it and fix it in your product (Article 13(6)).

What the CRA says about SBOMs

The regulation defines a software bill of materials as "a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements" (Article 3(39)). If you are new to SBOMs, start with What is an SBOM?.

What it requires:

• You must draw one up. Annex I, Part II, point 1: identify and document components, "including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products".
• It is part of your technical documentation. Annex VII lists the SBOM among the information on your vulnerability handling processes.
• Authorities can ask for it. A market surveillance authority can request it, with a reasoned request, where it needs it to check compliance (Annex VII, point 8).
• You don't have to publish it. If you decide to make it available to users, your user information must say where to find it (Annex II, point 9).
• The format may be set later. The Commission may specify the SBOM's format and elements in implementing acts (Article 13(24)).

What that means for a team:

• Use a standard format. CycloneDX and SPDX are the two formats most tools produce. "Commonly used and machine-readable" rules out a spreadsheet you maintain by hand. See the CycloneDX entry in the glossary.
• Generate it in the build, for every release. An SBOM describes one version. A new build with different dependencies needs a new one, kept with the release it describes.
• Go beyond the minimum. The law asks for top-level dependencies at least. Most vulnerabilities sit deeper in the dependency tree, and you need the full tree to answer "are we affected?" within the 24-hour window.
• Keep it where you can query it. When a vulnerability is announced, the useful question is which of your releases contain the affected component. That needs SBOMs you can search, not files scattered across build logs.

Fines

Member States set the penalties, within the ceilings in Article 64:

• up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher, for breaking the essential requirements in Annex I or the obligations in Articles 13 and 14;
• up to EUR 10 million or 2% for breaking a list of other obligations, including those of importers and distributors;
• up to EUR 5 million or 1% for giving incorrect, incomplete or misleading information to notified bodies or market surveillance authorities.

Microenterprises and small enterprises can't be fined for missing the 24-hour early-warning deadline, and open-source software stewards can't be fined at all (Article 64(10)).

A checklist for software teams

Now (reporting applies)

• List the products you place on the EU market and decide, with legal advice, which are in scope and in which role.
• Find your main establishment in the EU, and so the CSIRT you report to. If you have none, work through the order in Article 14(7).
• Name who decides, at any hour, whether a report concerns an actively exploited vulnerability or a severe incident.
• Write the runbook for the 24-hour early warning, the 72-hour notification and the final report, and rehearse it.
• Publish a contact address for vulnerability reports and a coordinated vulnerability disclosure policy.
• Generate an SBOM for each release, so you can tell within hours whether you ship an affected component.

Before 11 December 2027

• Run and document a cybersecurity risk assessment per product, and keep it current.
• Decide each product's support period (at least five years unless expected use is shorter) and say so to users.
• Check the Annex I, Part I security properties against each product: secure defaults, updates, access control, encryption, logging, data deletion.
• Separate security updates from feature updates where you can, and make sure they are free.
• Set up due diligence for third-party and open-source components, and a route for reporting their vulnerabilities upstream.
• Assemble the technical documentation in Annex VII, including the SBOM, test reports and the EU declaration of conformity.
• Check whether any product is an "important" or "critical" product (Annexes III and IV), which changes the conformity assessment route.

Where AI CodeOps fits

AI CodeOps is not a CRA compliance product, and it doesn't file reports for you. It covers a few of the engineering records the CRA expects you to keep, for code written by AI agents and people alike:

• SBOM records per project. You generate the SBOM with your usual tool, in CycloneDX or SPDX, and record it against the project. Each record keeps the commit it describes, a SHA-256 hash, the component and vulnerable-component counts and a license summary. AI CodeOps doesn't generate SBOMs and has no CVE scanner. See Security and SBOM.
• A release gate. Your CI can ask whether a change is ready. The gate refuses a change with open high-severity findings, failing tests or, if you set license rules, a disallowed license in the latest SBOM.
• Signed evidence packs. For each change, a signed record of the task, the models used, approvals, findings, tests and delivery, which anyone can verify. See Evidence packs.

To look inside an SBOM file now, without signing up, try the SBOM viewer.

Primary sources

• Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex: the text this page is based on.
• Cyber Resilience Act, European Commission: the Commission's policy page, with its guidance and updates.

We checked every date and article reference on this page against the regulation's text on EUR-Lex on 24 October 2026.