Free CRA Readiness Check
Where does your product stand with the CRA? Know in 24 hours.
One small program, one command in your project folder — and you receive a clear report: traffic-light CRA readiness status, the full list of your software components, and known vulnerabilities with severity, plus a license review. Free, once per company (repeat check: €99).
--dry-run. The collector is open source.In force from 11 September 2026
Is one of your flaws being exploited right now?
From 11 September, actively exploited vulnerabilities must be reported within 24 hours — not the severe ones, the exploited ones. Those are two different criteria, and a CVSS score only answers the first.
Your report therefore checks every finding against the CISA KEV catalog — the official register of vulnerabilities demonstrably under active exploitation — and states the EPSS exploitation probability for every listed finding — with context, because “higher than 97% of all CVEs” says more than “12%”. A KEV hit leads the report instead of sitting on page 7. The prediction helps you sort; the traffic light follows documented findings alone.
The reverse explicitly does not hold: no hit does not mean “not being exploited”. The catalog lists what is documented, not what exists. We will not write you an all-clear we cannot evidence.
Vivado · Libero SoC · Quartus Prime
What sits inside the FPGA, too
The check now reads FPGA projects as well — AMD/Xilinx Vivado, Microchip Libero SoC and Intel/Altera Quartus Prime. The third-party IP cores in your design end up in the report with name and version, not just the processor side. On a public Zynq reference design that came to 27 IP cores — building blocks that appear in no hand-kept list, and that your customers will ask you for regardless.
The promise above still holds. The program knows an IP core’s supplier on your machine — it does not transmit it. That is why the supplier column stays empty for FPGA cores in the report. You see the full list in the analysis that runs inside your own building.
And we say what does not work. FPGA IP cores cannot be matched against vulnerability databases. The report marks them explicitly as unchecked rather than showing you a green light for something that was never checked.
Licensing, too
Copyleft obligations are evaluated along the entire dependency chain, not just for the packages you include directly — a GPL three levels down applies just the same. Anything that cannot be attributed to a license is reported as exactly that: an unknown license is an unbounded risk, not an empty field.
The promise above holds here as well. We resolve licenses on our side from name and version — you send nothing for this.
No false alarms
A report that lists components which are not installed at all gets closed on first sight — rightly so. If a manifest says pillow>=10.0 and the lockfile says pillow 12.3.0, then 12.3.0 is the installed version; the manifest’s lower bound no longer appears as a component of its own, with vulnerabilities of its own.
Directories holding build output (dist/, build/, node_modules/) are never read — they contain copies of your source tree and would double-count everything. Your own exclusions belong in an .embtraceignore.
How it works
-
1
Request your code. Fill in the form below — you receive your personal one-time code and the download link by e-mail.
-
2
Install and run the collector.
pipx install embtrace-check— or use the standalone binary from the e-mail (no Python required). Then, in your project folder:embtrace-check . --code YOUR-CODE. Preview what would be sent first:--dry-run. -
3
Receive your report. Within 24 hours: CRA traffic light, component list, known vulnerabilities with concrete update recommendations and license risks with options — as a PDF to your registered address.
Request your free code
The code arrives by e-mail and is valid for one check.
✅ Registration received!
Your personal code is on its way by e-mail (please also check your spam folder). Then: one command, 24 hours, report.
Frequently asked questions
What exactly leaves our building?
Only the names, versions and package ecosystems of your software components — no source
code, no file paths, no configuration. With --dry-run you see byte-for-byte what would be
transmitted before anything is sent. On request, --anonymize even hashes the project name.
And because trust should be verifiable, the collector is open source:
github.com/Innomatica-GmbH/embtrace-check.
What does the check cost?
The first check is free — once per company. A repeat check with an updated report costs €99 against invoice. For continuous monitoring (new vulnerabilities within hours, monthly audit report) there is embtrace Monitor as a subscription.
Which projects are supported?
Anything with package-manager or build files: Conan, vcpkg, CMake, Cargo, npm/yarn/pnpm, Python, Go, Maven/Gradle, Yocto/Buildroot environments and more. Plus FPGA projects from Vivado, Libero SoC and Quartus Prime. Plain Make projects without manifests can declare components manually — the report states that clearly.
Who produces the report?
The analysis runs on our own servers in Germany; every report is personally reviewed by our team before it goes out. No call centre, no data resale — we are a German embedded-software company.