Your firmware has a bill of materials.
You just haven't written it down.

Regulation (EU) 2024/2847. It sets cybersecurity requirements for any product with digital elements placed on the EU market: hardware that connects, and the software in it. It covers how the product is designed, how vulnerabilities are handled across its supported life, and what has to be documented and reported.

If it has digital elements and can connect, directly or indirectly, to a device or a network, and you place it on the EU market, then yes. There is no small-company exemption. Some categories are carved out because other law already covers them, such as medical devices, motor vehicles, civil aviation and marine equipment.

11 September 2026: the reporting obligations under Article 14 apply, including to products already on the market.
11 December 2027: the regulation applies in full, including the essential requirements in Annex I, the technical documentation in Annex VII, the EU declaration of conformity and CE marking.

An actively exploited vulnerability in your product, or a severe incident affecting its security. Article 14 sets three steps: an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report within 14 days of a corrective or mitigating measure becoming available. For a severe incident the final report is due within one month. Reports go through the ENISA single reporting platform. Note the trigger is actively exploited, not every CVE.

Yes. Annex I Part II requires manufacturers to identify and document the components in the product in a machine-readable software bill of materials covering at least the top-level dependencies. It forms part of the technical documentation under Annex VII. CycloneDX and SPDX are the usual formats; Germany's BSI TR-03183-2 is the most concrete published guidance on what fields to include.

Harder than from a package manager, which is why generalist tools produce so little from an embedded build. The reliable sources, in order: a manifest from the build system (Yocto emits SPDX, Zephyr has west, ESP-IDF writes a project description); a package database inside the image itself (opkg on OpenWrt, dpkg on Debian-based systems), which carries exact versions and often CPEs; container header structures; and only then version strings and SONAMEs recovered from the binary. Anything from that last group is a guess and should be labelled as one.

A general description of the product and its intended purpose; the software versions affecting compliance; a description of the design, development and vulnerability handling processes; the cybersecurity risk assessment; the reasoning behind the support period; the standards applied; test reports; the EU declaration of conformity; and the SBOM. It must be kept for 10 years from placing on the market, or the support period, whichever is longer.

The support period must reflect how long the product is reasonably expected to be used, and in principle should be at least five years unless the expected use is shorter. You have to document the reasoning, and tell users the end date.

Usually not. Default products are self-assessed. Products in the important classes of Annex III and the critical categories of Annex IV face stricter routes: class I can use harmonised standards plus self-assessment, class II requires third-party assessment, and critical products may need a European cybersecurity certification scheme.

Up to 15 million EUR or 2.5% of worldwide annual turnover, whichever is higher, for breaching the essential requirements or the manufacturer obligations. Market surveillance authorities can also order a product withdrawn or recalled.