Device manufacturers · Cyber Resilience Act
Firmware SBOM for the CRA, from your Keil, IAR or Linux build
Since 11 September 2026, device manufacturers report actively exploited vulnerabilities within 24 hours, also for devices already in the field. From 11 December 2027, every product newly placed on the market or substantially modified needs a machine-readable SBOM.
You upload the file your build produces. Back come the linked libraries with their versions, the known vulnerabilities and the missing hardening, as an SBOM and a findings report. Without source code.
As of 20 October 2026 · Cyber Resilience Act, Regulation (EU) 2024/2847
What the CRA requires
Three dates that set your schedule
The Cyber Resilience Act applies to every product with digital elements that has a data connection to a device or a network (Art. 2(1)). For firmware, that almost always means your device is in scope.
The legal text and references are under CRA and NIS2.
10 December 2024
In force
Twenty days after publication in the Official Journal.11 September 2026
Reporting obligation, Art. 14
Also for devices already on the market (Art. 69(3)).11 December 2027
All requirements
Annex I, SBOM, CE marking (Art. 71(2)).
- Support
- A support period of at least five years, unless the product is expected to be in use for a shorter time (Art. 13(8)).
- Fines
- For infringements of Annex I, Art. 13 or Art. 14: up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher (Art. 64(2)).
The reporting obligation
Three deadlines once you know of an exploited vulnerability
If a vulnerability in your product is actively exploited, three deadlines run from the moment you become aware of it (Art. 14(2)). The report goes at the same time to the CSIRT designated as coordinator and to ENISA (Art. 14(1)).
You can only report what you know: which releases contain the component, and in which version. That is in an SBOM per release.
- 24hours
- Early warning notification, after you become aware of the exploited vulnerability
- 72hours
- Vulnerability notification with the product, the nature of the exploitation and the corrective or mitigating measures taken
- 14days
- Final report, after a correction or mitigation is available
A device placed on the market before 11 December 2027 only has to meet the requirements if it is substantially modified afterwards (Art. 69(2)). The reporting obligation applies regardless (Art. 69(3)).
Is your device in scope?
Default, class I, class II or critical
The class decides who assesses conformity. It changes nothing about the SBOM and the reporting obligation: those apply to every class. Products with their own rules are excluded, such as medical devices and vehicles with type approval (Art. 2(2)).
Default
Any device with a data connection that is on neither list: controllers, sensors, measuring instruments, drives.Self-assessment by the manufacturer.Class I, Annex III
Among others routers, modems and switches, microcontrollers and microprocessors with security-related functions, operating systems, smart home alarm systems and door locks.Self-assessment only if you fully apply harmonised standards, common specifications or a European certification (Art. 32(2)).Class II, Annex III
Firewalls, intrusion detection systems, tamper-resistant microcontrollers and microprocessors.EU-type examination or full quality assurance with a notified body, or a European cybersecurity certificate.Critical, Annex IV
Smart meter gateways, smart cards and secure elements, hardware devices with security boxes.
What you upload
The file your build produces anyway
The AXF, ELF or OUT with debug information yields the most: it holds libraries, paths and versions. A BIN from the same build gets that build's components when the AXF comes with it.
- No source code, no access to your systems.
- You upload the file yourself, into your own account.
- What happens to it afterwards is described under Security.
- .elf .axf .out
- Keil MDK, IAR, GNU ArmComponents, versions, vulnerabilities
- .hex .ihex .s19 .srec
- Intel HEX, Motorola S-RecordComponents, as far as the bytes evidence them
- .bin
- Raw image for the flashComponents, as far as the bytes evidence them
- .zip .tar .gz .tgz
- Embedded Linux, as shippedComponents, versions, vulnerabilities
What comes back
Your firmware, as the app shows it
A public Keil project, ble_freertos_amota.axf, analysed on our platform. 6 components, 3 with an evidenced version. Where the file carries no version, the field stays blank, and the component stays in the list.
Components and SBOM
Every component with its version, its origin in the build and its CVEs. The export delivers CycloneDX, SPDX 2.3 and SPDX 3.0.1.
Finding on the RTOS kernel
FreeRTOS 10.1.1
- CVEs reported
- 6
- with code in the build
- 2
- in the KEV catalogue
- 0
FreeRTOS 10.4.3 fixes the 2 with code in the build; all 6 need FreeRTOS 11.3.1. Code in the build: the AXF's symbol table, checked with nm (finding).
Hardening with evidence and remedy
Which protection mechanisms are missing in the image, how you can tell, and how to fix it in the next build. Here: stack canary, MPU, privilege separation.
Stack canary
No__stack_chk_guard, no__stack_chk_failin the symbol table.MPU
NoMPU_symbol; the build uses the portportable/Keil/AMapollo2.Privilege separation
Without the MPU port every task runs privileged; noxPortRaisePrivilegein the symbol table.
Obligation and evidence
What the analysis contributes to your obligations
The app maps the findings to the obligations they give evidence for, and it also says what a firmware analysis cannot evidence: processes and documentation remain your job.
Reporting obligation, Art. 14
When a vulnerability is exploited, the first question is which shipped releases contain the component. With an SBOM per release, that is one search.SBOM, Annex I, Part II, point (1)
The SBOM as CycloneDX or SPDX, from the file your build produces, with the version wherever the file carries it.No known exploitable vulnerabilities, Annex I, Part I, point (2)(a)
Every component with a version is matched against the public vulnerability databases, with its severity and a note on whether the vulnerability is already being exploited.Bought-in code, Art. 13(5)
Your supplier's SBOM with CVE matching, on the same device, next to the inventory we read from your image.
If you already have an SBOM
What your existing SBOM does not cover
Some manufacturers already produce SBOMs, for the Radio Equipment Directive or from the package manager, for example. The question is whether the list matches the file that runs on the device.
The SBOM a chip vendor ships with its package describes the package. The SBOM from the source tree names what sits in the repository. What the linker actually took in is only in the build.
- Import your SBOM. You upload your existing CycloneDX or SPDX file to the device. We match it against vulnerabilities, and it sits next to the inventory we read from the image.
- Per release. Every shipped firmware version gets its own SBOM. Then one search answers which releases contain an affected library.
Five checks for your own SBOM: Checking an existing SBOM.
74
components named in the package's SBOM
0 of 5
bundled libraries among them
| Middlewares/Third_Party | in the package's SBOM |
|---|---|
| FreeRTOS | no |
| mbedTLS | no |
| LwIP | no |
| FatFs | no |
| LibJPEG | no |
STM32CubeF4 v1.28.3 ships FreeRTOS, mbedTLS, LwIP, FatFs and LibJPEG under Middlewares/Third_Party. The package's SBOM names 74 components, none of these five.
Questions from the first call
What heads of development want to know first
Does this really work without source code, even for plain C projects?
Yes. A Keil, IAR or GCC build writes library names, paths and versions into the file it produces. In the public Keil example, the path with FreeRTOS and its version appears 406 times in the AXF. We read the components from that, without you handing over any code.
Which file should we upload, the AXF or the BIN?
The AXF, ELF or OUT of the build: it names the linked libraries, and a Keil or GNU Arm build also their versions. A BIN on its own yields only what its own bytes evidence. Upload both from the same build and the BIN gets the AXF's components.
A release or a development build?
For the obligations, what you ship is what counts: start with the release that is in the field. A development build shows you earlier what is in the next release. We treat both files as equally confidential.
Does the reporting obligation also apply to devices already sold?
Yes. Since 11 September 2026, Art. 14 also applies to products placed on the market before 11 December 2027 (Art. 69(3)). The other requirements only reach such a device if it is substantially modified after that date.
Is the SBOM from the STM32Cube package or the Keil pack enough?
Not for your device. It describes the package the chip vendor ships. The SBOM of STM32CubeF4 v1.28.3, for example, names none of the five libraries the package ships under Middlewares/Third_Party. Your SBOM names what your build linked.
Can we check our suppliers' SBOMs?
Your suppliers' SBOMs in CycloneDX (JSON, XML) or SPDX (JSON, tag-value, SPDX 3.0 JSON-LD), up to 64 MB. We detect the format from the content. Every component with a CPE, distribution or repository identifier is matched against the vulnerability sources. Matching for npm, PyPI and Maven packages follows.
Does the SBOM have to be published?
No. It is part of the technical documentation. The market surveillance authority can ask for it in a reasoned request (Annex VII, point 8, recital 77).
CycloneDX or SPDX?
The regulation asks for a commonly used machine-readable format and names none. LegacyMind exports CycloneDX 1.6, SPDX 2.3 and SPDX 3.0.1 as JSON, plus CSV.
Is the report proof of conformity?
No. It is technical evidence for your technical documentation: what is in the firmware, which vulnerabilities attach to it, which protection mechanisms are missing. As the manufacturer, you make the declaration of conformity.
Your build, one findings report
The CRA readiness check is free. You get the report and SBOM within three working days of the upload.