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

• Which half of the work do you need help with? Technical tools produce the SBOM, the vulnerability records and the build evidence. Compliance management platforms map requirements to controls, draft policies and track the process. Most tools are strong in one half, so decide which gap is bigger.
• 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

CRACI

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 keeps re-evaluating the SBOMs of what shipped, supports VEX, and submits the CRA notifications on your behalf when an actively exploited vulnerability has to be reported. For Yocto, it records what Yocto's own SPDX output leaves out. Helps with: SBOM generation, vulnerability handling, CRA notifications, evidence. Watch out: it does not analyze binaries you did not build, has no control mapping or policy management, and supports GitHub Actions today (GitLab CI and Jenkins are on the roadmap). CRA compliance with CRACI

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 and Cybeats alternatives

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 and ONEKEY alternatives

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 and Finite State alternatives

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

Compliance management platforms

These tools do not generate SBOMs or scan code. They work on the governance half: mapping the CRA's requirements to controls, drafting policies, and tracking deadlines and sign-offs. They need technical evidence from elsewhere.

Venvera

Venvera is a compliance platform built in the EU that covers the CRA next to NIS2, DORA, ISO 27001 and SOC 2. For the CRA it tracks the 24-hour and 72-hour reporting clocks, vulnerability handling, the SBOM as a maintained requirement, the conformity assessment route per product class, and the Annex VII technical documentation and EU declaration of conformity. Helps with: control mapping, reporting deadlines, tracking the conformity process. Watch out: it tracks that an SBOM exists and is maintained; the SBOM itself comes from another tool.

ZeroRisk

ZeroRisk is an agentic compliance platform covering GDPR, ISO 27001, SOC 2, NIS2, DORA and the CRA. For the CRA its agent maps the requirements to your organization, pre-fills a readiness assessment, drafts missing controls and policies, and monitors the suppliers inside your products, re-checked every 24 hours, with human sign-off on each conclusion. Helps with: readiness, policies, supplier assurance. Watch out: its CRA page does not mention SBOM generation or vulnerability monitoring of your own builds.

Reporting within the deadlines

Article 14 puts the notification on the manufacturer, and it has applied since September 11, 2026, including for products already on the market. 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, Venvera tracks the clocks, and binary analysis from ONEKEY, Finite State or Exein covers supplier code you cannot rebuild. CRACI's API returns SBOMs, network traces and provenance, and CRACI submits the early warning, notification and final report on the manufacturer's behalf.

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, keeps re-evaluating the SBOMs of what shipped, supports VEX, and exports SBOMs as CycloneDX or SPDX, including vulnerabilities, for your CRA evidence. When an actively exploited vulnerability has to be reported, CRACI submits the CRA notifications on your behalf. For Yocto, it runs BitBake on runners of up to 32 vCPUs and 96 GB of RAM and records what Yocto's own SPDX output leaves out, such as host packages and package URLs for Rust crates. CRACI's inventory view shows exactly which software versions are deployed to which products, globally. 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 guided checks against standards, control mapping and policy management, protection on the device, or CI systems other than GitHub Actions today (GitLab CI and Jenkins are on the roadmap). For the builds you own, CRACI covers the SBOM, monitoring and CRA notifications in one product; for firmware you cannot rebuild, binary analysis sees what your build never did. See what the CRA is, CRA compliance and industrial IoT.

CRA compliance tools: common questions

What CRA compliance software does, and what stays with the manufacturer

What is CRA compliance software?

Software that helps a manufacturer meet the Cyber Resilience Act. It comes in two kinds: technical tools that produce the SBOM, vulnerability records and build evidence, and compliance management platforms that map the requirements to controls and track the reporting clock, the risk assessment and the conformity assessment. None makes a product compliant on its own.

Which CRA obligations can a tool automate?

Mostly the vulnerability handling side: generating the SBOM, monitoring it for new vulnerabilities, finding affected releases, recording triage and VEX decisions, preparing and submitting the Article 14 notifications, and exporting evidence for the technical documentation. The risk assessment, secure design, conformity assessment and declaration of conformity remain the manufacturer's decisions.

Do I need one tool or several?

Usually more than one. A technical tool gives you the SBOM and vulnerability evidence; a compliance management platform or a consultant covers controls, policies and the conformity route. For firmware you receive from suppliers as binaries, binary analysis adds what your own build cannot see.

What is the deadline for CRA reporting?

Article 14 has applied since September 11, 2026: an early warning within 24 hours of becoming aware of an actively exploited vulnerability, a notification within 72 hours and a final report no later than 14 days after a fix or mitigation is available. It covers products already on the market. The rest of the CRA applies from December 11, 2027.

Does CRACI submit CRA notifications?

Yes. CRACI submits the early warning, the notification and the final report on the manufacturer's behalf. The reporting obligation stays with the manufacturer.

Does any tool perform the CRA conformity assessment?

No software tool replaces it. The manufacturer carries out the assessment, by internal control or, for important and critical products, with a notified body or a certification scheme where the CRA requires one. Tools supply the evidence the assessment uses.