CRA compliance tools for software teams: what fits your workflow?

Which CRA tools belong on your shortlist?

For EU Cyber Resilience Act compliance software, consider ConformOps when the main job is connecting source evidence to assessments and controlled documentation; KONFORMA for monitoring supported connected-product releases; Regulus for guided CRA planning; ONEKEY for firmware analysis linked to requirements; and OWASP Dependency-Track for SBOM-based component monitoring. These are workflow-fit recommendations, not an overall ranking.

ConformOps publishes this comparison and is one of the products discussed. We reviewed the linked first-party pages on 9 September 2026 and checked ConformOps descriptions against its implementation. We have not conducted a hands-on comparative trial of the other tools. Their capabilities below are vendor-described, and an unanswered demo question does not mean a feature is absent. This is a selected shortlist, not an exhaustive market survey.

What should CRA compliance software actually help you do?

Software product compliance involves more than finding vulnerable dependencies. For an in-scope product, the manufacturer needs a defensible scope and classification assessment, cybersecurity risk work, vulnerability handling, support planning and technical documentation. Regulation (EU) 2024/2847 is the legal source: Article 13 addresses manufacturer obligations, Article 14 reporting, Annex I essential requirements and Annex VII technical documentation. Software can organise this work; responsibility remains with the manufacturer.

The European Commission's CRA overview distinguishes the dates: Article 14 reporting obligations apply from 11 September 2026, while the main obligations apply from 11 December 2027. A 2026 purchasing decision should address reporting preparation and the wider implementation work separately. An advisory match is not automatically a reportable event, and an internal case record is not proof of submission to an authority.

For this comparison, release traceability means being able to identify the inputs, findings, decisions and artifacts belonging to a particular version. Auditability means another person can reconstruct that record, including what was unknown and what changed. These are purchasing criteria, not prescribed CRA database fields or a new certification standard.

ConformOps: connecting source evidence to the technical file

ConformOps fits software teams that need a traceable chain from a release-bound source snapshot through assessment findings, accountable approvals and working documentation. It retains assessment provenance, separates readiness dimensions and provides an inspectable evidence-lineage view. A supplied SBOM remains identified as manufacturer-supplied evidence; accepting it does not establish inventory completeness.

Full Assessment covers the initial assessment workflow. Named releases, ongoing monitoring, CI/CD integration and Article 14 reporting operations require Continuous access. The CI/CD guide explains engineering gate outcomes, which do not grant legal approval. Check current plans against the number of products and maintained releases you need to operate.

In a demo, start with a completed assessment, change the source or supplied SBOM, then inspect both runs and download their artifacts. Check that the earlier record remains understandable and that pending approvals are visible. ConformOps is not a firmware reverse-engineering suite, does not replace security testing and does not establish legal compliance. Its data-residency disclosure also matters for EU buyers: it does not claim EU-only processing.

KONFORMA: monitoring supported connected-product releases

KONFORMA's product overview describes CycloneDX and SPDX input, GitHub inventory import, release-specific vulnerability monitoring, affectedness decisions and evidence packs. It focuses on embedded, IoT and connected products, including older releases that remain supported. That makes it worth considering when the recurring problem is keeping product inventories and vulnerability decisions current between assessments.

Ask the vendor to follow one new advisory across two supported versions, record different affectedness decisions and retrieve the evidence for each. Confirm monitoring frequency, reporting handoff, support-period handling and what customers receive in an export. Also establish which risk-assessment and technical-documentation work your team or consultant must maintain around that workflow.

Regulus: structuring the first CRA assessment

Regulus describes applicability checks, product classification, a requirements matrix, documentation templates and a compliance roadmap. Its public site also advertises early access at the review date. It is a candidate for teams whose immediate obstacle is organising the questions and responsibilities in a first CRA implementation project.

Before buying, confirm which advertised functions are available in the offered plan. Ask to see the actual workspace, attach evidence to a requirement, revise a product fact and retrieve the previous decision. For a team shipping frequently, also request a demonstration of release history and engineering integration. The public planning description alone does not establish how those workflows operate.

ONEKEY: firmware analysis with requirement review

The ONEKEY Compliance Wizard documentation describes a firmware-centred workflow that includes CRA provisions, automated suggestions, manual decisions, supporting materials and downloadable compliance bundles. It also describes marking affected provisions as outdated after relevant analysis changes. This is worth evaluating when firmware or device software is a major part of the product evidence.

ONEKEY explicitly recommends manual checks because its automated findings depend on the information available in the firmware. Ask it to analyse a representative image, explain one finding and one requirement needing manual review, then export the supporting bundle. Confirm how the workflow covers your source-level evidence, non-firmware product functions and organisational vulnerability-handling process. A firmware result alone cannot settle those questions.

OWASP Dependency-Track: a component-monitoring layer

OWASP Dependency-Track is an open-source platform for SBOM ingestion, component inventory, vulnerability analysis and policy enforcement. Its documentation describes project-version tracking and integration through APIs and CI tooling. It is a practical candidate when you already produce CycloneDX SBOMs and need to monitor component risk across a software portfolio.

Treat that as a defined part of your CRA process. Ask who owns the product risk assessment, support decisions, reporting reviews, approvals and technical file alongside it. If your existing tools already hold those records reliably, a separate component platform may be enough to close the operational gap. If they do not, an SBOM dashboard will not organise the entire process for you.

Open-source software still needs an operating budget. Include hosting, patching, backups, access control, feed failures and the engineer responsible for integrations. Test the quality of the incoming inventory as well: monitoring an incomplete SBOM does not establish that every shipped component is covered.

When existing tools and a specialist are enough

SME software manufacturers do not necessarily need another platform at the beginning. Version-controlled documents, an issue tracker, release artifacts and a competent reviewer can be a workable arrangement for a small portfolio if ownership and evidence retention are explicit. Specialist advice is particularly useful when the open question is product scope, classification or the applicable conformity-assessment route.

The test is maintenance. Can someone retrieve the evidence for an older supported version, identify the responsible decision-maker and explain a later change without searching personal inboxes? If not, measure that retrieval and reconciliation work before assuming a spreadsheet is cheaper. Equally, do not buy automation before agreeing what the product is and which records it must maintain.

Run the same release-evidence exercise with every vendor

Bring a representative, approved-for-sharing sample: one product, two versions, an SBOM, a security test and a requirement that still needs review. Ask the vendor to use those materials instead of relying entirely on a prepared dashboard. The following is a buyer's acceptance exercise, not a legal compliance test.

• Identify the release and retain its inputs. Establish whether the inventory was supplied, generated or inferred, and what remains unobserved.
• Connect one requirement to evidence. Open the evidence and explain what it proves and what it does not.
• Record a decision. Show the reviewer, rationale, date and version, then change a relevant input and inspect what happens to that decision.
• Investigate one vulnerability. Separate a package match, product affectedness and a reporting decision; show how missing intelligence is displayed.
• Retrieve both versions. Export the earlier evidence and decisions after the newer release has been assessed.
• Exercise the reporting handoff. Identify the responsible person and distinguish internal drafts from actual authority submissions.
• Test your exit. Confirm export formats, retention, access after cancellation and which records can be understood outside the platform.

Compare the full operating cost, then choose

Request a quote for the same product count, release history, users, integrations and support needs. Include onboarding, inventory preparation, internal review time, external assessment where applicable, and export access. We have not normalised vendor prices here because the offerings cover different work; confirm current terms directly rather than comparing headline subscriptions as if they were equivalent.

For EU teams, include procurement questions about source access, hosting and processing locations, subprocessors, AI use, deletion and access controls. A European vendor address does not establish EU-only processing. Ask for the documented boundary and check it against the data you plan to upload.

Choose the option that handles your hardest recurring task and lets your team reconstruct its decisions. Keep effective scanners and build tooling where they already work. For a longer procurement checklist, use the CRA software buyer's guide; for the underlying evidence work, start with technical documentation. If source-to-document traceability is your missing piece, see how ConformOps works and run the same exercise against it.