Platform

Components, vulnerabilities and hardening from your firmware

LegacyMind reads from a firmware image or build which components at which version are inside, which known vulnerabilities attach to them, which credentials and keys ship with it and which protection mechanisms are missing. Back come an SBOM in CycloneDX or SPDX and two reports with findings against CRA Annex I and § 30 BSIG (Germany's NIS2 implementation). No source code needed.

Free CRA readiness checkSupported formats

As of 20 October 2026

Vulnerabilities per component in the app, under the app bar with the device industrial gateway · OpenWrt 23.05.5, filter high and above, by risk: Linux kernel 5.15.167 with 8 KEV entries, libmbedtls12, BusyBox, PPP daemon, GRUB2, grub2-efi and librt, each with actionable CVEs and highest severity
Industrial gateway · OpenWrt 23.05.5 · Vulnerabilities tab, filter high and above (the app is in German) · public firmware image (x86-64), analysed on 22 October 2026

How it works

From upload to monitoring in four steps

  • 01

    Upload

    Provide a firmware image, a supplier SBOM (CycloneDX, SPDX) or a bare-metal build (ELF, for example from Keil) by upload, or read it out of the target environment with the Extractor (closed beta)

  • 02

    Analysis

    Specialised analyses assess components, vulnerabilities, hardening and compliance in parallel

  • 03

    Report

    SBOM, technical findings, compliance mapping and risk assessment in one report

  • 04

    Monitoring

    New CVEs and KEV entries keep being matched to the analysed releases

Per file

What comes back from which file

How much the analysis finds depends on what the file carries. A build with debug information names libraries and versions; a raw image only what its bytes evidence. Every file extension is listed under formats.

  • .zip .tar .gz .tgz

    Firmware images with Linux

    The image as you ship it: archives, raw images, file systems (SquashFS, JFFS2, CramFS, UBI, YAFFS2, ext), kernel and boot images including ARM zImage, update containers and VM disks. The analysis unpacks down to the root file system and finds the packages of Debian, OpenWrt, Alpine and Red Hat based systems, the programs and the kernel, each with its version.
    Components, versions, vulnerabilities

  • .elf .axf .out

    Bare-metal builds (ELF, AXF)

    Microcontroller builds from Keil MDK, IAR or GNU Arm. It finds the libraries built in, with their versions, for example CMSIS packs, RTX5, FreeRTOS, lwIP, mbedTLS and STM32Cube. Plus hardening (stack canary, MPU, privilege separation) and embedded keys.
    Components, versions, vulnerabilities

  • .bin

    Raw microcontroller images (BIN)

    A BIN without a file system. When the AXF of the same build is there, the BIN gets its components with their versions. On its own it names the components the image itself evidences, for example TLS libraries.
    Components, as far as the bytes evidence them

  • .hex .ihex .s19 .srec

    Intel HEX and Motorola S-record

    Converted to bytes and analysed like the BIN of the same build. When the AXF is there, they get its components with their versions.
    Components, as far as the bytes evidence them

  • .json .xml .spdx

    Supplier 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.

01 / 05

Overview per device

One device, one page: the risk score, the actions in their order, and the findings on CRA Annex I and § 30 BSIG.

  • Risk score from the technical findings and evidenced exploitation
  • Actions in the order to work through them, each with the affected component
  • Findings on CRA Annex I and § 30 BSIG in one view
  • New CVEs and KEV entries for releases already analysed
Device overview in the app: risk score 82, critical; 183 actionable vulnerabilities (4 critical, 51 high, 93 medium), 8 in the KEV catalogue, 156 components, 1 exposed credentials entry; below, three priority actions, first the 8 KEV vulnerabilities of Linux kernel 5.15.167
Industrial gateway · OpenWrt 23.05.5 · Overview tab · public firmware image (x86-64), analysed on 22 October 2026

02 / 05

Vulnerability analysis

What is actively exploited sits at the top. CVSS alone does not decide the order.

  • Matched against 18 public sources, CISA KEV and EUVD among them
  • Findings grouped by affected component, with version and source on every row
  • Every match notes whether the version is confirmed or assumed
  • CVE details with the version that closes the finding
CVE table in the app, sorted by risk, the first eight rows: Linux kernel vulnerabilities in the CISA KEV catalogue, each with CVE ID, CVSS, severity, KEV and EUVD listing and description
Industrial gateway · OpenWrt 23.05.5 · Vulnerabilities tab, CVE table · public firmware image (x86-64), analysed on 22 October 2026

18sources

Distributions, vendor CSAF advisories, authorities and the open-source ecosystem, plus CISA KEV and EUVD for actively exploited vulnerabilities.

Distributions

Vendor CSAF

Government agencies

Ecosystem

03 / 05

Components and SBOM

SBOM generation straight from binary firmware, without source code.

  • CycloneDX export, machine-readable
  • Crypto inventory, assessed against BSI TR-02102-1
  • Per component: name, version and where in the image it was found
  • A version without evidence in the image stays blank. It is never guessed.
Components view in the app: 156 components from the build artefact, 154 with an evidenced version, 15 with known vulnerabilities; below, sorted by vulnerabilities, Linux kernel 5.15.167 in the KEV catalogue and libmbedtls12, BusyBox and PPP daemon at critical severity
Industrial gateway · OpenWrt 23.05.5 · Components tab, with CVEs · public firmware image (x86-64), analysed on 22 October 2026

04 / 05

Hardening analysis

What sits in the image and should not: credentials, keys, unprotected binaries.

  • Accounts with an empty or weak password, the hash algorithm per account
  • Certificates with expiry date, key length and self-signing
  • Linux: RELRO, NX, PIE and stack canaries, binary by binary
  • Microcontrollers: stack canary, MPU and privilege separation, measured on the build
  • Binaries and builds that pull in unsafe C functions such as strcpy, sprintf or gets
Hardening view in the app for an STM32F429 firmware (GCC build): 4 of 4 protection mechanisms missing, each row with the evidence in the image, the evidence level and the way to fix it: stack canary, MPU, privilege separation, the RTOS stack overflow check
Measuring device STM32F429 · Hardening tab · public firmware (STM32CubeIDE, ELF), analysed on 22 October 2026

05 / 05

CRA Annex I and § 30 BSIG

The findings of an image, mapped to the requirements, each point with its basis.

  • CRA Annex I: the analysis answers 5 requirements from the image and gives counts for 1; the report lists 16 by number for your documentation
  • § 30 BSIG: the analysis answers 2 items from the image and gives counts for 1; the report lists 7 by number as actions for the entity itself
  • A manufacturer gets CRA Annex I by part and letter, an operator § 30(2) sentence 2 BSIG by number, from the same analysis and the same figures
  • Each point takes one of five forms: finding, checked with no finding, not checked with a reason, observation, not determinable from the image
Compliance view in the app on CRA Annex I for the Keil build of the Apollo3 radio module: per point, the finding, its basis and the form of the finding
Radio module Apollo3 · Compliance tab, CRA Annex I · public Keil MDK build ble_freertos_amota.axf (Arm Cortex-M4), analysed on 22 October 2026; none of the findings is a conformity verdict

See these views with your own firmware

Continuous monitoring

Analyse once. Keep the risks in view.

A scan shows today's state. After that, LegacyMind keeps matching newly published CVEs to the same firmware releases, and the risk score follows.

2hours
KEV and EUVD matching, every 2 hoursCatalogues of actively exploited vulnerabilities, against every release already analysed
24hours
CVE matching, once a dayNew vulnerabilities are matched to firmware releases already analysed

Risk updates on every run. The risk score is computed from the findings.

The report

What the technical findings report contains

The table of contents of the real report on a public Keil build. The report is in German. Sections that do not apply to an image are not printed.

  1. Geltungsbereich und Prüfgegenstand3
  2. Management-Kurzfassung4
  3. 6Komponenten-Schwachstellenkatalog9
  4. 12Abdeckung, Grenzen und Erklärung zum Prüfumfang13
  5. 14Maßnahmenplan je Befund (Release-Planung)15
  6. 15Normbezug: CRA Anhang I16
All 20 sections
  1. Geltungsbereich und Prüfgegenstand3
  2. Management-Kurzfassung4
  3. 1Technische Einordnung5
  4. 2Methodik und Prüfgrundlage6
  5. 3Priorisierung: vom Rohbefund zur Handlung7
  6. 4Angriffsfläche und Exposition · not printed for this build
  7. 5Vorrangig zu behandelnde Befunde8
  8. 6Komponenten-Schwachstellenkatalog9
  9. 7Anmeldedaten und Geheimnisse10
  10. 8Speicherschutz und Exploit-Schutzmaßnahmen10
  11. 9Kernel-Härtung und Kernel-Exposition · not printed for this build
  12. 10Weitere statische Prüfungen10
  13. 11Software-Stückliste (SBOM) und Begleitdokumente11
  14. 12Abdeckung, Grenzen und Erklärung zum Prüfumfang13
  15. 13Befundliste zur Nachverfolgung14
  16. 14Maßnahmenplan je Befund (Release-Planung)15
  17. 15Normbezug: CRA Anhang I16
  18. AGlossar und Abkürzungsverzeichnis17
  19. BReferenzen und Normenverzeichnis18
  20. CBerichtsnachweis und Dokumentenlenkung18

Outputs

What you export and pass on

The SBOM for your technical documentation, the reports for management and engineering, the vulnerabilities as CSV for your ticket system.

  • SBOM export

    CycloneDX 1.6 JSON, SPDX 2.3 and SPDX 3.0.1 JSON, plus CSV. Every component says where in the image it was read.

  • Vulnerabilities

    Matched against 18 public sources, CISA KEV and EUVD among them. Supplier SBOMs are matched against 14 of these 18: your suppliers' component names go to no public query API.

  • A decision per finding

    A CERT/CC SSVC decision for every vulnerability found, with the inputs it follows from.

  • Two reports

    A management summary and a technical findings report, both in German, with findings against EU CRA Annex I and § 30 BSIG.

Not yet: VEX and CSAF export, Firmware Extractor (closed beta).

Questions about the platform

What developers and buyers ask

Do you need source code?

No. The analysis runs on the firmware image you ship, or on the file your build produces.

Which formats do I get the SBOM in?

CycloneDX 1.6 JSON, SPDX 2.3 JSON and SPDX 3.0.1 JSON, plus CSV. Every component names the place in the image where it was read.

What happens if a version is not in the file?

Then the field stays blank, and the component stays on the list. A version is never guessed, because a guessed version leads to wrong vulnerabilities.

How often are new vulnerabilities matched?

The catalogues of actively exploited vulnerabilities, CISA KEV and EUVD, every two hours. New CVEs daily, against every release already analysed.

How is the order of the findings decided?

By rules, and traceably: actively exploited vulnerabilities (CISA KEV) first, then by need for action and severity. Every vulnerability gets a CERT/CC SSVC decision, with the inputs it follows from.

Does the report replace a conformity assessment?

No. It provides technical evidence on the points a firmware can evidence. You make the conformity statement, as a manufacturer under the CRA or as an entity under § 30 BSIG.

See it on your own firmware

In the free CRA readiness check we analyse one file from your build or your shipped image.

Free CRA readiness checkBook a call