CRA compliance tools compared

Who this page is for

You make a product with digital elements and place it on the EU market. The Cyber Resilience Act, Regulation (EU) 2024/2847, applies to you in stages: its reporting obligations from September 11, 2026, and its main provisions from December 11, 2027. You are choosing tools for the technical parts of that work. We build CRACI, so weigh that in. We describe every tool from its own documentation and say where another tool fits better.

One rule runs through this page. Compliance is a process the manufacturer runs, with risk assessment, documentation and conformity assessment. Tools produce evidence and automate parts of the work. None of the tools below makes a product compliant on its own.

What the CRA asks for

For the software supply chain, five requirements do most of the work.

1. An SBOM. Manufacturers identify and document the components in the product, "including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products" (Annex I, Part II). Annex VII places it in the technical documentation, which a market surveillance authority can request.
2. Vulnerability handling. Address and remediate vulnerabilities without delay, including through security updates, test regularly, and run a coordinated vulnerability disclosure policy (Annex I, Part II).
3. Reporting. Notify actively exploited vulnerabilities and severe incidents to your CSIRT and to ENISA through the CRA Single Reporting Platform: an early warning within 24 hours, a notification within 72 hours, and a final report no later than 14 days after a fix or mitigation is available for a vulnerability, or within one month for a severe incident (Article 14).
4. Evidence. Technical documentation, a conformity assessment and an EU declaration of conformity (Articles 28, 31 and 32, Annex VII), kept available to authorities for at least 10 years after the product is placed on the market or for the support period, whichever is longer (Article 13).
5. A support period. A period that reflects how long the product is expected to be in use, at least five years unless the expected use is shorter, during which vulnerabilities are handled effectively (Article 13).

How to choose

• Do you build the software, or integrate it? If much of the product arrives from chip vendors and suppliers as binaries, binary analysis is how you see inside it. If you build it yourself, the build is the most direct source of evidence.
• Where does your SBOM come from, and how do you know it is complete? Scanners, build tool queries and build recording can give different answers for the same release.
• Can you find affected releases in hours? A 24-hour early warning depends on a per-release inventory you trust.
• Do you need a system of record? With many products and suppliers, SBOM management with VEX and sharing becomes its own job.

At a glance

Two tables: SBOM, SCA and SBOM management tools first, then tools built for firmware and devices. Rows follow the requirements above. "Not stated" means the vendor pages we cite do not say either way.

SBOM, SCA and SBOM management

Firmware and devices

SBOM management

Cybeats

Cybeats SBOM Studio calls itself "the SBOM system of record." It stores SBOMs from your products and suppliers in SPDX 2.2 to 3.0.1 and CycloneDX 1.2 to 1.7, validates them with a Quality Score before import, matches every component against vulnerability intelligence, issues VEX, and shares SBOMs with customers, including over the Transparency Exchange API. Its regulations guide sets out the CRA's 24-hour, 72-hour and 14-day timeline. Helps with: SBOM management, vulnerability handling, evidence. Watch out: for generation it points to vendors in its Marketplace, so the SBOM itself comes from another tool. CRACI vs Cybeats

FOSSA

FOSSA started in license compliance and now covers the SBOM lifecycle. It generates SPDX and CycloneDX SBOMs, optionally with VDR or VEX statements, imports supplier SBOMs with policies for NTIA and FDA minimum elements, monitors them for vulnerabilities, and shares them through an SBOM Portal on Enterprise. As of September 2026 it has a free plan, and Business costs $20 per project per month, billed annually. Helps with: SBOM, sharing with authorities, licenses. Watch out: the FOSSA CLI analyzes the project through its build tool or infers from source, rather than recording the build. CRACI vs FOSSA

Anchore

Anchore Enterprise builds on the open-source Syft and Grype. It scans container images, filesystems and imported SBOMs, rescans stored SBOMs without the original artifact, applies policy packs such as FedRAMP and NIST, and runs self-hosted, including air-gapped. Its CRA material covers SBOM management, monitoring against sources including CISA KEV, support for the 24-hour and 72-hour windows, VEX annotations and audit trails. Helps with: SBOM, vulnerability handling, evidence. Watch out: its SBOMs describe what a scanner finds in an image or directory, not what the build fetched and left behind. CRACI vs Anchore

SCA suites

Black Duck

Black Duck SCA combines package manager, signature, snippet and binary scanning, so it finds open source nobody declared, and its KnowledgeBase tracks more than 2,750 licenses. Binary Analysis examines firmware without source code, Coverity provides SAST with a CRA-aligned checker option announced in July 2026, and Defensics does fuzz testing. Black Duck argues that the CRA needs layers of testing, not SCA alone. Helps with: SBOM, vulnerability handling for components and your own code, testing. Watch out: pricing is by quote, and every technique inspects code or output rather than the build. CRACI vs Black Duck

Sonatype

Sonatype Lifecycle applies open-source policy with reachability and upgrade data and opens Golden Pull Requests. Repository Firewall quarantines components that fail policy before they enter your repositories. SBOM Manager imports, monitors and shares SBOMs with a VEX workflow, and Sonatype positions it as its CRA product; its guide also points to Nexus Repository as an update site for security updates. Helps with: vulnerability handling, SBOM management, keeping bad components out. Watch out: packaging is changing (new customers buy Sonatype Guide), and Lifecycle analyzes what the build produced rather than what it fetched. CRACI vs Sonatype

Firmware and devices

ONEKEY

ONEKEY analyzes compiled firmware with "no source code or network access needed." It generates an SBOM from the binary, imports supplier SBOMs, looks for likely zero-days such as hardcoded credentials, and re-analyzes firmware daily. Its Compliance Wizard walks teams through the CRA, IEC 62443-4-2, ETSI EN 303 645 and the Radio Equipment Directive. Helps with: SBOM for firmware you did not build, vulnerability handling, guided checks. Watch out: it works on the image after the build, so it does not record what the build fetched. CRACI vs ONEKEY

Finite State

Finite State analyzes firmware, binaries, source code and supplier SBOMs, with support for more than 50 binary instruction set architectures, and brings them into one product record. It ranks findings by reachability and exploit intelligence, records VEX decisions, and its compliance workflow covers CRA control mapping and audit-ready reports with SBOM and VEX artifacts. Helps with: SBOM across suppliers, vulnerability triage, evidence. Watch out: it starts from artifacts, so controlling what your own build could reach is outside its scope. CRACI vs Finite State

Exein

Exein works on the device. Exein Runtime uses eBPF to monitor and block malicious behavior on embedded Linux, and the open-source meta-exein Yocto layer puts its Pulsar agent into your image. Exein Analyzer scans firmware before release, or your SBOM when the binary is not available, prioritizes with reachability scoring, and maps findings to CRA requirements. Helps with: vulnerability handling in the field, firmware SBOM, CRA mapping. Watch out: the Yocto layer changes what runs on the device; it does not run or record your build. CRACI vs Exein

Reporting within the deadlines

Article 14 puts the notification on the manufacturer. What tools can do is shorten the time between "this vulnerability is being exploited" and "we know which products and releases contain it". That depends on per-release inventories you trust, continuous monitoring, and a link from each shipped artifact to its components. Anchore and Cybeats describe the reporting windows in their CRA material, and binary analysis from ONEKEY, Finite State or Exein covers supplier code you cannot rebuild. CRACI's API goes from an artifact to its producing build, its CycloneDX SBOM and the job's network trace.

How CRACI fits

CRACI is a GitHub Actions runner. For software you build, it records what each job fetched, including packages restored from CI caches, and produces a CycloneDX or SPDX SBOM with a completeness state per job and per cache. It enforces an egress policy on the build, signs provenance that links each artifact to its build, keeps re-evaluating the SBOMs of what shipped, and exports reports in PDF, HTML, CSV, Excel and JSON. For Yocto, it runs BitBake on runners of up to 32 vCPUs and 96 GB of RAM, next to Yocto's own SPDX output. CRACI automates a significant part of the software supply chain visibility and evidence that companies need for their wider CRA compliance process.

It is not enough on its own if most of your product comes from suppliers as binaries, or if you need VEX and license policy (on the roadmap), a vendor SBOM upload portal, guided checks against standards, protection on the device, or CI systems other than GitHub Actions. A common pairing is CRACI for the builds you own and a binary analysis or SBOM management tool for everything else. See what the CRA is, CRA compliance and industrial IoT.