Getting compliant

Do You Need CRA Compliance Software? A Vendor-Neutral Look at What These Tools Actually Do

Last updated · October 9, 2026

No, the Cyber Resilience Act does not require you to buy anything. There is no mandated tool, no approved vendor list, and no software product that makes you compliant. What there is, above a certain number of products and dependencies, is a volume of tedious, repetitive work that tooling handles better than a person with a spreadsheet. This piece is about telling those two things apart before you sign a contract.

This article provides general guidance, not legal advice. CRA Facts is independent. We have no commercial relationship with any vendor named below, we take no affiliate revenue, and nothing here is a recommendation or endorsement.

Key points

Nothing in the CRA requires you to buy software. Reporting through ENISA's Single Reporting Platform is free.
Tooling genuinely automates SBOM generation, vulnerability matching, VEX handling and evidence retention. That is real work, and at scale it is a lot of it.
Tooling cannot decide your scope, product class, support period, or whether a vulnerability is actively exploited. Article 28(4) puts responsibility on the manufacturer; Article 64 fines the manufacturer, not the vendor.
A small team shipping one or two products can meet the SBOM obligation with free, open-source generators and a version-controlled repository.
Treat any claim of "CRA certified" or "CRA compliant" as a product badge with scepticism. No such certification exists for buying software.
No CRA harmonised standard is yet cited in the Official Journal, so no vendor can deliver presumption of conformity today.

Why this question is live right now

Two dates are driving budget conversations. Reporting obligations under Article 14 became applicable on 11 September 2026, and ENISA switched on the Single Reporting Platform the same day^[1]. Full product obligations - essential requirements, SBOM, CE marking, declaration of conformity, technical documentation - follow on 11 December 2027.

Which means a lot of companies are, this quarter, being asked to put a number in a budget line next to the words "CRA compliance". Vendors know this too.

One thing worth stating plainly before anything else: the SRP is an official channel operated by ENISA, it is free, and you do not need a vendor to submit a report through it. Tooling may help you assemble a report quickly. It does not buy you access.

What the CRA actually requires you to produce

Before evaluating any tool, be clear about the artefacts and processes the regulation asks for:

Obligation	Where it lives
Cybersecurity risk assessment	Article 13
Security by design and secure by default	Annex I, Part I
SBOM in a machine-readable format	Annex I, Part II(1)
Vulnerability handling and CVD policy	Article 13, Annex I Part II
Free security updates across the support period	Annex I, Part II
Technical documentation, retained 10 years	Annex VII
EU Declaration of Conformity and CE marking	Annex V, Articles 28-30
Reporting actively exploited vulnerabilities and severe incidents	Article 14

Now the useful question becomes: which of these can a tool actually touch?

What tooling genuinely automates well

These are the areas where software earns its keep, because the work is mechanical, repetitive and unforgiving of human error:

SBOM generation at build time. Producing a CycloneDX or SPDX inventory automatically on every build, rather than by hand, quarterly, badly.
Continuous vulnerability matching. Watching your component inventory against vulnerability feeds and telling you when something in your product becomes a problem.
VEX handling. Vulnerability Exploitability eXchange lets you record that a listed component vulnerability is not exploitable in your particular product - because the vulnerable code path is never reached, say. Without something like VEX, SBOM-driven alerting drowns a small team in findings that do not matter. This is one of the more underrated reasons to have tooling.
Evidence collection and retention. Annex VII requires the technical documentation to be kept for ten years. Tools that capture build artefacts, test results and SBOMs automatically, with timestamps, make that a background process rather than an archaeology project.
Release traceability. Knowing which SBOM belongs to which firmware version - which is exactly what field 4 of your declaration of conformity will need.

What no tool can do for you

This is the heart of it, and the part vendors are least likely to lead with.

Deciding scope and class. Whether your product is in scope, and whether it is default, Important Class I or II, or critical, is a legal determination about your product and your market. A tool can hold the answer. It cannot reach it for you, and it will not be liable if the answer is wrong.

Judging whether a vulnerability is actively exploited, or an incident severe. This is the Article 14 trigger, and it is a judgement call made under time pressure by a named human. Vulnerability feeds inform it; they do not make it.

Setting and justifying your support period. This follows from your product's expected lifetime and your commercial reality, not from a dropdown.

Signing the declaration. Article 28(4): by drawing up the EU Declaration of Conformity, the manufacturer assumes responsibility for the compliance of the product^[2]. Under Article 64, the top penalty tier - up to €15 million or 2.5% of worldwide annual turnover, whichever is higher^[2] - attaches to the manufacturer for breaches of the essential requirements or Articles 13 and 14.

Your vendor is not on that hook. You are. A dashboard is not a defence.

If a demo implies that adopting the product makes you compliant, the demo is describing something the regulation does not permit. Responsibility does not transfer.

What you can do with free tools

If you are a small team shipping one or two products, this section may be the whole answer.

The SBOM obligation in Annex I, Part II(1) asks for a machine-readable inventory covering at least the top-level dependencies, in a commonly used format^[4]. Open-source generators cover this well - Syft for images and filesystems, Trivy for containers, cdxgen for source, Tern for container layers - producing CycloneDX or SPDX output. Store the result in the same version control as the code it describes, tagged to the release, and you have both the artefact and its provenance.

We walk through exactly that in How to Generate Your First CRA-Ready SBOM, so we will not repeat it here.

Add a monitored security contact, a written CVD policy, a named owner for Article 14 triage, and SRP access, and a small manufacturer has a defensible position with no licence spend at all.

When buying starts to make sense

Honest thresholds, roughly in order of how strongly they point towards tooling:

Many products or variants. Ten SKUs with divergent firmware is a different problem from one product.
Deep dependency trees. Heavy use of third-party and transitive open-source components, especially in embedded stacks.
A long declared support period. Ten years of monitoring is not a manual task. See The CRA Support Period.
Customers demanding evidence. If enterprise or public-sector buyers are already asking for SBOMs and attestations in procurement, tooling pays for itself in sales cycles alone.
More than one regime in play. Where the CRA sits alongside the Radio Equipment Directive, the Machinery Regulation or NIS2, one evidence base serving several obligations is worth real money.
No engineer with time to own the pipeline. This is the honest one. A free toolchain nobody maintains is worse than a paid one somebody does.

For orientation on what exists: the market divides roughly into SBOM management and vulnerability monitoring platforms (Keysight SBOM Manager, OPSWAT MetaDefender Software Supply Chain and Finite State are examples of offerings in this space) and consultancy-led compliance services (BearingPoint, for instance, has announced SBOM management and CRA compliance services). These are named as factual examples of market categories only - we have not tested them, and their inclusion is not an endorsement.

Questions to ask any vendor

Take this list into the call. The answers separate serious products from repackaged dashboards fast.

Which specific CRA article or annex does this discharge, and which does it only assist with? Anyone who cannot answer at that granularity has not read the regulation.
Do you generate SBOMs from the shipped binary or artefact, or only from the source manifest? These give materially different answers. What you ship is what is in scope.
Which formats do you export, and can I leave with my data? CycloneDX and SPDX, exportable, or you are building a dependency you cannot undo.
Do you support VEX? If not, ask how they expect you to handle non-exploitable findings at volume.
How does the ten-year Annex VII retention work if we stop paying you? This is the question most likely to produce an uncomfortable pause. Your obligation outlives your subscription.
Do you claim to submit Article 14 reports on our behalf? If so, who is legally the reporter? Understand exactly where the legal act sits and what your own record of it looks like.
Can you show me the evidence pack a market surveillance authority would actually ask for? Not a dashboard screenshot - the exported artefacts. See CRA Market Surveillance for what authorities can demand.
What happens when harmonised standards are finally cited in the Official Journal - is that a product update or a new contract?
What do you explicitly not cover? A good vendor answers this readily. A bad one says "everything".

Red flags

"CRA certified" or "CRA compliant" as a product badge. There is no CRA certification scheme for compliance software, and no CRA logo - see There Is No CRA Logo.
Promises of automatic compliance. Scope, class, support period and the declaration are all yours.
Claims of presumption of conformity today. No CRA harmonised standard has yet been cited in the Official Journal. Presumption of conformity is not currently available through any route a tool can sell you. We track this in CRA Harmonised Standards and the Presumption of Conformity.
Anything implying the vendor carries your liability. Article 64 does not work that way.
A countdown clock to 11 September 2026 still on the pricing page. That date has passed. It tells you how current the product actually is.

How to decide in two weeks

Count your products, variants and third-party dependencies. Write the numbers down. They decide this more than anything a vendor says.
Try the free path first. Generate one SBOM for one product with an open-source tool. A single afternoon will tell you whether this is tractable in-house.
Identify who would own the pipeline if you kept it in-house, and confirm they have the hours.
List the obligations you are actually worried about - usually retention, monitoring at scale, or customer evidence requests.
Take the nine questions above to two vendors, and ask them to map their answers onto your list from step 4.
Price the alternative honestly, including the engineering time the free path consumes over a year.
Decide, and write down why. That note is useful the next time someone asks whether the line item is still justified.

Where to go next

Confirm what applies to you at all with the scope checker.
Work backwards from the CRA deadlines page.
Sequence the programme with the CRA compliance checklist.
Start on the artefact most tools are built around with the SBOM guide.

{{component:callout|level=tip}} We do not sell anything. CRA Facts is a free, independent information hub run by Nukipa Labs GmbH, with no vendor relationships and no affiliate revenue. Subscribe to The CRA Brief for one update a week on what actually changed. {{/component}}