CRA readiness check · free
Send one firmware image. Get a findings report for your technical documentation.
We analyse one firmware image of your choice without access to the source code and deliver technical evidence from the release you actually ship.
The check for one image is free.
Direct contact · +49 176 81152657 · info@legacymind.de
How the check works
Four steps, from the call to the report
- 1
Call
30 minutes, at a time from the calendar. We show you the analysis on a file of yours, or on a public image if you would rather watch first. The calendar is in German; the call can be in English.
What you see in the call
- the components that are actually in the image
- the known vulnerabilities per component
- credentials and private keys, if the image contains any
- 2
Your file
On request we sign an NDA first. You upload one file in your own LegacyMind account: the AXF, ELF or OUT of your build, or the image your customer receives. No source code, no access to your systems.
Which files
- .elf .axf .outBare-metal builds (ELF, AXF) · Components, versions, vulnerabilities
- .hex .ihex .s19 .srec .motIntel HEX and Motorola S-record · Components, as far as the bytes evidence them
- .binRaw microcontroller images (BIN) · Components, as far as the bytes evidence them
- .zip .tar .gz .tgz .bz2 …Firmware images with Linux · Components, versions, vulnerabilities
- .json .xml .spdxSupplier SBOMs · Components, versions, vulnerabilities
What happens to the file
- The uploaded firmware image is deleted after the analysis, also when the analysis fails.
- The analysis runs on servers in Germany; the results are stored in a database in Frankfurt.
- For the matching, only component name and version go to public vulnerability databases, never the file itself.
- 3
Analysis
Rule-based, on the file you uploaded. You receive the report and the SBOM within three working days of the upload.
Read
Components with version, known vulnerabilities per component, credentials, keys and certificates, the hardening of the binaries and unsafe C functions that are linked in.
Not part of the analysis
Runtime and penetration tests, hardware and side-channel analysis, and your processes.
Encrypted images
We do not decrypt an image the manufacturer has encrypted. If a file cannot be read, the report says why.
- 4
Report
The technical findings report and the management summary as PDF, plus the SBOM as CycloneDX or SPDX, free of charge. You keep both, also if we do not work together afterwards. Once the report is there, we schedule the call in which we go through the findings; you make the conformity statement.
How the libraries and their versions come out of a Keil build: checking Keil firmware for known vulnerabilities.
Scope
Which points of CRA Annex I the check answers from the image
The rest are properties of your processes or of the device at runtime. A file does not show them, so the report does not claim them.
With a finding from the image
- No known exploitable vulnerabilities (Part I, point 2(a))
- Secure by default configuration: accounts shipped in the image (2(b))
- Protection from unauthorised access: credentials and keys shipped in the image (2(d))
- Confidentiality: private keys and certificates in the image (2(e))
- Exploitation mitigation: stack protection, memory protection, privilege separation (2(k))
- Identify and document components and vulnerabilities, with an SBOM (Part II, point 1)
Process or runtime, not in the file
- Development appropriate to the risks (Part I, point 1)
- Limiting attack surfaces (Part I, point 2(j))
- Security updates, integrity, data minimisation, availability, impact on other devices, logging, secure deletion (Part I, points 2(c), (f) to (i), (l), (m))
- Handling, testing, disclosure and distribution of updates (Part II, points 2 to 8)
Questions before the upload
What manufacturers ask first
- What does the check cost, and what does it commit us to?
- The check for one image is free and commits you to nothing. You keep the report and the SBOM, also if we do not work together afterwards.
- Which file should we send?
- The AXF, ELF or OUT of your build, a HEX or BIN, or the image your customer receives. A build with debug information yields the most, because the libraries and versions are recorded there.
- Can we use a file from a project that is still in development?
- Yes. For the obligations the shipped release counts; for planning the next release a development build helps. On request we sign an NDA before the upload.
- What happens to the file?
- The uploaded firmware image is deleted after the analysis, also when the analysis fails. The analysis runs on servers in Germany. Only component name and version go to public vulnerability databases.
- What if the image is encrypted?
- We do not decrypt an image the manufacturer has encrypted. Send the unencrypted file from the build. If a file cannot be read, the report says why.
- Is the report proof of conformity?
- No. It is technical evidence for your technical documentation. You make the conformity statement as the manufacturer.
- Are the app and the report in English?
- The app and the reports are in German. The SBOM is a standard CycloneDX or SPDX file. Questions and the call can be in English.
Book the 30 minutes
The calendar is in German. You can also write to info@legacymind.de or call +49 176 81152657.