Start a trial

Operational notes Regulation

Cyber Resilience Act: no SBOM, no CE marking from 11 December 2027

8 min read

Every component of a dismantled device, laid out side by side on a pale surface
A bill of materials is exactly this: every part listed, none left out — including the ones nobody meant to show.

On 11 December 2027 Regulation (EU) 2024/2847 — the Cyber Resilience Act — applies in full: Article 71(2) sets the date. From that day, a product with digital elements may be placed on the Union market only if the manufacturer has first drawn up the technical documentation required by Article 31, carried out the conformity assessment under Article 32, signed the EU declaration of conformity under Article 28 and affixed the CE marking under Article 30. That is the sequence written into Article 13(12): without the first link, the last one does not exist. And inside that file sits a new item — the software bill of materials. From today, 25 July 2026, that is a little over sixteen months away.

This is not the September obligation

The CRA arrives in stages, and the stages are easy to confuse. Article 14 — reporting exploited vulnerabilities and severe incidents, an early warning within 24 hours and a notification within 72 — applies from 11 September 2026, less than seven weeks away; Chapter IV on notified bodies has applied since 11 June 2026. But September is an obligation of conduct: what you do when something happens, and it rests on a mailbox, a policy and a named owner. 11 December 2027 is an obligation of product and paper: one file per product family, kept current version by version, that you must already have written down in order to sell. It cannot be recovered in the closing weeks.

What the technical file must contain

Article 31(1) refers to Annex VII, which lists the minimum content:

  1. a general description of the product: intended purpose, software versions relevant to compliance, the internal layout where there is hardware, and the user instructions set out in Annex II;
  2. design, development, production and vulnerability handling — drawings and schemes, a description of the architecture explaining how software components build on or feed into each other, the software bill of materials, the coordinated vulnerability disclosure policy, the reporting contact address, and the secure update distribution mechanisms;
  3. the cybersecurity risk assessment required by Article 13;
  4. the information used to determine the support period, which Article 13(8) fixes at a minimum of five years;
  5. the harmonised standards and certification schemes applied — or, failing that, the solutions adopted instead;
  6. the reports of the tests carried out;
  7. a copy of the EU declaration of conformity;
  8. “where applicable, the software bill of materials, further to a reasoned request from a market surveillance authority”.

Article 13(13) closes the loop: the file and the declaration must stay at the disposal of the authorities for at least ten years from the date the product was placed on the market, or for the support period if that is longer. Not a form to be filed: a living archive.

One line of regulation, one X-ray

The substantive duty sits in Annex I, Part II, point 1: manufacturers shall “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”. Article 3(39) defines it as “a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements”. Not a spreadsheet compiled at the end of a project: a machine-readable artefact regenerated at every release.

And it says far more than “what is inside”: which open-source libraries you use and in exactly which version, which commercial components you bought and from whom, how the modules depend on one another. From there anyone can reconstruct architectural choices, suppliers, the cost of replacing a part. Cross-referenced with public vulnerability databases, it lets whoever holds it know before the manufacturer does which versions are exposed and to what. It is the same information that serves defence and attack alike.

The regulation knows this, and leaves the problem to you

The text does not hide the tension; it manages it. Recital 77 is explicit: “Manufacturers should not be required to make the software bill of materials public.” Annex II, point 9 asks for the address at which it can be accessed only if the manufacturer chooses to make it available to the user; Annex VII, point 8 makes it conditional on a reasoned request from an authority; even the Union-level software dependency assessment under Article 13(25) reaches ADCO anonymised and aggregated. And Article 63 requires everyone involved in applying the Regulation to protect trade secrets “including source code”.

The legislator has built its own perimeter; yours is up to you. The condition that already protects technical manuals applies here too: Directive (EU) 2016/943, transposed in Italy by Legislative Decree no. 63 of 11 May 2018 amending Articles 98-99 of the Industrial Property Code, protects information as a trade secret only where it is secret, has commercial value because it is secret, and is subject to reasonable steps to keep it secret. An SBOM uploaded to a generic cloud assistant to “get it tidied up quickly” quietly stops meeting that third condition. This is a recurring pattern, not an accusation aimed at anyone: when the document is hard and the deadline close, the most convenient shortcut is always the one that takes the file outside the company.

Who will have to show it to a third party

Not every product self-certifies. Annex III lists the “important” ones — class I: operating systems, routers and switches, VPNs, SIEM systems, microcontrollers and FPGAs with security-related functionalities, smart cameras and smart locks, wearables for health monitoring; class II: hypervisors and container runtime systems, firewalls and intrusion detection and prevention systems, tamper-resistant microprocessors. Annex IV lists the “critical” ones: smart meter gateways, smart cards and secure elements. For class I, where harmonised standards are not applied in full, EU type-examination (module B+C) or full quality assurance (module H) becomes mandatory; for class II, one of the two, always; for Annex IV, a European cybersecurity certification scheme is required (Article 32(2)-(4)). In all these cases the file leaves the company and lands on a notified body’s desk. Article 12 adds a bridge: a product that is also a high-risk AI system (Article 6 of Regulation (EU) 2024/1689) is presumed to meet the cybersecurity requirements of Article 15 of the AI Act where it complies with Annex I of the CRA and demonstrates it in the EU declaration. One file, two regulations.

What not having it costs

Article 64 sets figures, not warnings. Non-compliance with the essential requirements of Annex I and the obligations in Articles 13 and 14: up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher. Technical documentation (Article 31(1)-(4)), declaration of conformity (Article 28), CE marking (Article 30(1)-(4)): up to EUR 10 million or 2%. Incorrect, incomplete or misleading information supplied to notified bodies and market surveillance authorities — that is, a badly compiled file — up to EUR 5 million or 1%. But before any fine comes the block: no file, no declaration; no declaration, no CE marking; no CE marking, no single market. It is the same pattern as the Machinery Regulation, where the manual decides the marking from 14 January 2027.

What to do now

  1. Classify every product: ordinary, Annex III class I or II, Annex IV. That decides whether the file will be read only by market surveillance or by a notified body as well.
  2. Generate the SBOM per product and per version, machine-readable, covering at least the top-level dependencies, and tie it to the release pipeline: compiled by hand, it is already inaccurate by the third release.
  3. Decide and justify the support period: the reasons behind the choice are an item required by Annex VII, point 4, not an internal note.
  4. Classify the SBOM as confidential today, not when the first reasoned request arrives: who sees it, through which channel you transmit it, where it is archived. That is the evidence of the “reasonable steps”.
  5. Consolidate the file: Article 31(3) requires a single set of technical documentation for products also subject to other Union legislation. Anyone already rewriting manuals for January 2027 is working on the same binder.

How we solve it

Compiling and checking technical files and software bills of materials is an enormous documentary workload on material that is at once mandatory to produce and forbidden to circulate. We tackle it with dedicated, closed AI, disconnected from the open web, in the two modes of our offering: on-premises in the client’s own environment, or on our dedicated cloud — an environment reserved for the single client, dedicated VPN access, a data centre resident in Italy, premises we staff directly. Either way the bill of materials and the code stay inside the perimeter: the system reads the file against the points of Annex VII and the requirements of Annex I, shows where an element is missing and proposes how to close the gap; review and sign-off remain with your engineering department. It is the method behind our assisted document compliance, the same one we apply to manuals and instructions across manufacturing districts: built once, it holds for several deadlines at a time.

Would you like to know how many of your connected products would have a presentable technical file today, without the code leaving your company? Half an hour with one of our experts is enough for the first map.

Sources