Tracefile turns a firmware image into a CycloneDX SBOM, watches it for exploited vulnerabilities, and drafts the technical file the Cyber Resilience Act asks for. For hardware companies with one or two products and nobody whose job title says "security".
No spam. One email when the free scanner is public, one when pricing is. Or write to hello@tracefile.app.
The regulation is staggered, so the product is too. The first obligation already applies; the second is 2027. Each stage is useful on its own.
.bin, Yocto image or ESP-IDF build.Binary analysis is heuristic. We'd rather tell you now than in an audit.
The regulation applies the same to a 20-person company as to a multinational. The tools so far are priced for the multinational.
Industrial sensors, building automation, EV chargers, agritech, audio and lighting. One or two products, a C/C++ firmware, a vendor BLE stack, and a shipping date.
You put your name on a device made elsewhere. Under the CRA that makes the obligations yours. You need to see inside firmware you didn't write.
Offer "CRA-ready" as a line item. White-label the scanner and the technical file generator; keep your clients' documentation in one place.
You have a product-security team, an existing SBOM pipeline and a budget in five figures per year. Existing platforms will serve you better.
Short, checkable answers. Every one cites the article or annex it comes from.
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.
The command-line scanner ships open source. Waitlist members get it a few weeks before it's public, plus early pricing on the watch and reporting service.
Tell us your RTOS or SoC in the reply email and we'll prioritise its fingerprints.