The Cyber Resilience Act is creating a new market: CRA compliance software. Manufacturers of digital products are searching for tools to help them implement CRA requirements. The market is growing – but most solutions only cover partial areas. This article shows why a fragmented approach is problematic and what manufacturers should look for when choosing.
The Problem: CRA Compliance Has Many Building Blocks
CRA compliance is not a single topic solvable with one tool. It encompasses at least five interconnected areas: SBOM creation and management, continuous vulnerability monitoring, conformity assessment and documentation, vulnerability reporting processes, and ongoing maintenance throughout the entire product lifecycle.
Most vendors on the market focus on one or two of these areas. This forces manufacturers to combine multiple tools – with the typical problems of fragmented toolchains: data silos, missing integration, manual transfer effort, and the risk of information falling through the cracks.
Typical Partial Solutions on the Market
The market for CRA-relevant software includes various categories of vendors, each addressing a specific aspect.
Pure SBOM tools like FOSSA, Snyk Open Source, or Black Duck (Synopsys) excel at Software Composition Analysis (SCA) and generating SBOMs from source code. They identify open-source components, check licenses, and create SBOMs in SPDX or CycloneDX format. What they lack: context for CRA conformity assessment, integration with reporting processes, and management of technical documentation. They answer "What is in my product?" but not "Is my product CRA-compliant?"
Vulnerability scanners and management platforms like Qualys, Tenable, or Rapid7 are strong at detecting and prioritizing vulnerabilities. They offer extensive databases and automated scanning. However, they are primarily oriented toward IT infrastructure, not product security in the CRA sense. They help with vulnerability detection but not with SBOM management per product version, CRA-specific reporting obligations, or conformity documentation.
GRC platforms (Governance, Risk, Compliance) like ServiceNow GRC, OneTrust, or Archer offer broad compliance frameworks into which the CRA can theoretically be embedded. They are strong in process management and documentation. But they are generic – they lack CRA-specific functions like SBOM handling, automated vulnerability matching against product components, and the linkage between product versions and their security status.
DevSecOps tools like Dependabot, Renovate, or GitHub Advanced Security integrate well into the development process and detect vulnerabilities in dependencies during development. For CRA compliance, however, they are insufficient because they only cover the development process, not the entire product lifecycle. Post-market surveillance, reporting obligations, and management of already-shipped products fall outside their scope.
Why Integration Matters
CRA requirements are interconnected – and that is precisely what makes fragmented solutions problematic.
An example: A new vulnerability is disclosed in an open-source library. To respond in a CRA-compliant manner, you must know within minutes which of your products use this library in which version (SBOM), whether the vulnerability is relevant in your product context (risk assessment), whether it is actively exploited (reporting obligation within 24 hours), and which customers need to be informed (user notification). When SBOM data lives in Tool A, vulnerability assessment happens in Tool B, and customer communication runs through Tool C, coordination costs valuable time – time you do not have with a 24-hour reporting deadline.
What to Look for When Choosing
When evaluating CRA compliance software, the following criteria are decisive.
SBOM management across the entire lifecycle. The tool must not only generate SBOMs but manage them across all product versions. Every shipped version must be linked to its SBOM, and when a vulnerability alert fires, it must be immediately apparent which versions are affected.
Automated vulnerability matching. SBOM data must be continuously checked against current vulnerability databases – automated and in real-time, not as a manual process.
CRA-specific documentation. The tool must understand CRA-specific documentation requirements: technical documentation per Annex VII, EU declaration of conformity, user information, and documentation of the vulnerability management process.
Reporting process support. From September 2026, actively exploited vulnerabilities must be reported within 24 hours. The tool should support this process – from detection through assessment to report generation.
Audit readiness. Market surveillance authorities can request technical documentation at any time. The tool must be capable of quickly and completely compiling all relevant information.
Kunnus: CRA Compliance as an Integrated Platform
Kunnus was designed from the start as an integrated CRA compliance platform – not as an SBOM tool with features bolted on afterward. We combine SBOM management, vulnerability monitoring, conformity documentation, and reporting processes in a single system.
The difference from partial solutions: with Kunnus, all CRA-relevant data flows together in one platform. When a new vulnerability is disclosed, you immediately know which products are affected, whether reporting is required, and what steps are needed next. Technical documentation is continuously updated rather than hastily assembled before an audit.
For manufacturers already using tools for partial areas, Kunnus offers integration capabilities: existing SBOM generators, CI/CD pipelines, and vulnerability databases can be connected. Kunnus adds the CRA-specific orchestration that makes the difference between "we have tools" and "we are CRA-compliant."
Want to see where you stand today? Our free CRA readiness assessment shows you in just a few minutes which areas are covered and where the biggest gaps in your current toolset exist.