On 11 December 2027 the whole Cyber Resilience Act (Regulation (EU) 2024/2847, "CRA") starts to apply (Art. 71(2)). From then on, before you place a product on the EU market, you must draw up its technical documentation, carry out a conformity assessment (Art. 13(12)), and issue an EU declaration of conformity with the CE marking. At the heart of that documentation is a software bill of materials (SBOM).
This guide is for small companies that sell an app, a plugin, an SDK or a device with firmware. It covers what goes into the technical documentation, what the CRA actually asks of an SBOM, how long you must support your product, which conformity route applies to you, and what you can start doing this month.
Which products need it
The requirements apply to products with digital elements that you place on the market from 11 December 2027 (Art. 71(2)). A product placed on the market before that date is covered only if it undergoes a substantial modification afterwards (Art. 69(2)). A substantial modification is a change after placing on the market that affects compliance with the essential cybersecurity requirements of Annex I (Art. 3(30)). The European Commission's guidance of 27 July 2026 explains with examples what counts as a substantial modification and how support periods should be applied.
Reporting is different: Article 14 has applied to all products, including those already on the market, since 11 September 2026 (Art. 69(3)). See our guide to CRA 24-hour reporting.
What goes into the technical documentation (Annex VII)
The technical documentation must show how your product and your processes meet the essential requirements of Annex I, and must include at least the elements listed in Annex VII (Art. 31(1)):
- A general description of the product: its intended purpose, the software versions that affect compliance, photos or illustrations for hardware, and the user information and instructions from Annex II.
- Design, development and vulnerability handling: system architecture, and your vulnerability handling processes, including the SBOM, the coordinated vulnerability disclosure policy, evidence of a contact address for vulnerability reports, and how you distribute updates securely. For hardware, also production and monitoring processes.
- The cybersecurity risk assessment and how the essential requirements apply to your product (see also Art. 13(2)-(4)).
- The information used to set the support period.
- The harmonised standards or common specifications applied, or a description of the solutions you used instead.
- Test reports showing conformity with the essential requirements.
- A copy of the EU declaration of conformity.
- The SBOM, where a market surveillance authority asks for it in a reasoned request.
You draw it up before placing the product on the market and keep it updated, where appropriate, at least during the support period (Art. 31(2)). You keep it, with the declaration of conformity, for at least 10 years after placing the product on the market or for the support period, whichever is longer (Art. 13(13)).
Micro and small companies may provide all elements of Annex VII in a simplified format (Art. 33(5)). The Commission is to specify that format in an implementing act. As of 14 October 2026 we could not find it published. Simplified means the format, not fewer elements: the eight items above still have to be covered.
What the CRA actually asks of an SBOM
The rule is in Annex I, Part II, point 1: manufacturers must
identify and document vulnerabilities and components contained in products with digital elements, 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.
What that means in practice:
- Format: "commonly used and machine-readable". The Regulation does not name a format. The Commission may specify the format and elements in an implementing act (Art. 13(24)). In ENISA's 2026 SBOM survey, 44% of respondents used CycloneDX and 29% SPDX.
- Depth: at least the top-level dependencies, meaning the components you include directly. Going deeper is not required by that point, but it helps. You must handle vulnerabilities of the product "including its components" (Art. 13(8)), so a vulnerable library deeper in the tree is still your problem.
- Not public: the SBOM is part of the technical file (Annex VII, points 2(b) and 8). The Regulation says manufacturers should not be obliged to make it public (Recital 77). If you choose to share it with users, you tell them where to find it (Annex II, point 9).
- Kept current: the documentation must stay up to date (Art. 31(2)) and lists the software versions (Annex VII, point 1(b)). In practice this means generating an SBOM with every release, not once.
The hard part is rarely the first SBOM. In ENISA's survey (334 responses), 62% named SBOM completeness as a technical challenge, and only 39% generated an SBOM on software builds.
Support period and security updates
You must set a support period that reflects how long the product is expected to be used. It must be at least five years, unless the product is expected to be in use for less, in which case it matches the expected use time (Art. 13(8)). During that period you handle vulnerabilities according to Annex I, Part II.
What this includes:
- fix vulnerabilities without delay, with security updates provided separately from feature updates where technically feasible (Annex I, Part II, point 2);
- distribute security updates without delay and free of charge, with advisory messages for users, unless a business customer agreed otherwise for a tailor-made product (Annex I, Part II, point 8);
- keep each security update available for at least 10 years after it is issued, or for the rest of the support period, whichever is longer (Art. 13(9));
- state the end date of the support period clearly at the time of purchase (Art. 13(19); Annex II, point 7).
Conformity assessment and CE marking, in short
Which route you take depends on your product's category:
| Category | Examples | Route |
|---|---|---|
| Default | most apps, plugins, SDKs, many devices | self-assessment (internal control, Module A) allowed, no notified body (Art. 32(1)) |
| Important, class I (Annex III) | password manager, VPN, browser, smart lock | Module A only if you fully apply harmonised standards, common specifications or a European cybersecurity certificate; otherwise a notified body (Module B+C or H) (Art. 32(2)) |
| Important, class II (Annex III) | hypervisor, firewall, intrusion detection | notified body (Module B+C or H) or a European cybersecurity certificate at level at least "substantial" (Art. 32(3)) |
| Critical (Annex IV) | hardware security module, smartcard | European cybersecurity certificate where the Commission requires it, otherwise the class II routes (Art. 8(1), Art. 32(4)) |
What counts is the product's core functionality (Art. 7(1)). Embedding, say, a VPN library does not make your whole app "important". After the assessment you issue the EU declaration of conformity and affix the CE marking (Art. 13(12)). If you are in class I and want to self-assess, check whether harmonised standards for your category have been published in the Official Journal before you rely on Module A.
What a micro company can do now
You have about 14 months. These steps cost little and also help with the reporting duty that already applies:
- Generate an SBOM with every release in your build pipeline, in CycloneDX or SPDX, and keep one per version.
- Check your dependencies against known vulnerabilities every day. If one of them is actively exploited, the 24-hour clock is already running.
- Publish a coordinated vulnerability disclosure policy (Annex I, Part II, point 5) and a contact address for vulnerability reports (point 6). A common way is a
security.txtfile at/.well-known/security.txtwith the required fieldsContactandExpires(RFC 9116). - Decide your support period, write down why (Annex VII, point 4), and plan where customers will see the end date.
- Open a technical file with the eight Annex VII headings and start with the risk assessment (Art. 13(2)).
- Check your category against Annex III and IV, so you know early whether you need a notified body.
Not sure where you stand?
Take the free "Does the CRA apply to me and what must I do by December 2027" check: 8 questions, about 3 minutes. You see your result on screen, including your product category, and get a checklist by e-mail. Take the free check
If the CRA applies to you, Earlybell does this work every week: an SBOM with every release, a daily check of your dependencies, ready-to-send drafts of the 24-hour and 72-hour reports for you to submit, an up-to-date disclosure policy and security.txt, and technical documentation kept ready for 11 December 2027. 49 EUR per product per month. We prepare drafts and documentation; you stay the manufacturer. We are not a notified body.
This article is based on Regulation (EU) 2024/2847 (Cyber Resilience Act) and on information published by ENISA and the European Commission. It is not legal advice. Article numbers refer to that Regulation.