Cyber Resilience Act compliance software: what to look for
A buyer's checklist for cyber resilience act compliance software: the six capabilities that actually matter — SBOM, daily monitoring, 24h reporting, Annex VII docs, self-assessment and fair pricing.
Not sure if you’re in scope?
Run the free 3-minute scope check for your product and get your risk class, deadlines and obligations.
Check if the CRA applies to youIn short
Good cyber resilience act compliance software should do six things: generate and maintain an SBOM from your lockfile, monitor it for vulnerabilities daily with recorded triage, run the 24-hour / 72-hour / 14-day ENISA reporting workflow, generate the Annex VII technical documentation and EU Declaration of Conformity, support self-assessment for the Default class, and price transparently. A tool that only produces an SBOM — or that hides its price behind a sales call — solves a fraction of the problem.
Search for CRA tooling and you get two kinds of results: security scanners that generate an SBOM and stop there, and enterprise GRC platforms priced for compliance departments you do not have. Neither is built for a small manufacturer who needs to place a product on the EU market and be done with it.
This guide is an evaluation checklist. It lists what CRA compliance software should actually do — not the marketing categories, the concrete workflows — so you can compare tools on the same terms and spot the ones that cover a corner of the problem while calling themselves complete.
Not sure the CRA applies to your product yet? Run the free 3-minute scope check first — it tells you your risk class before you shop for anything.
The six things that matter
The Cyber Resilience Act (Regulation (EU) 2024/2847) turns compliance into four ongoing obligations plus the paperwork that proves them. A tool worth paying for covers all of it in one place. Use this table as your scorecard:
| Capability | What to check | Why it matters |
|---|---|---|
| 1. SBOM generation | Builds a CycloneDX or SPDX SBOM from a lockfile or component list, and regenerates it per release | The SBOM is the foundation everything else stands on. A stale one fails silently |
| 2. Daily vulnerability monitoring | Scans the SBOM against OSV/NVD daily, filters noise, records a triage decision per finding | New CVEs appear every day; manual checking means finding out late |
| 3. Incident reporting workflow | A 24h / 72h / 14-day countdown with pre-filled ENISA + CSIRT notifications | You cannot design a reporting process during the incident |
| 4. Documentation generation | Produces the Annex VII technical file and the EU Declaration of Conformity from your data | These are mandatory for CE marking by 11 December 2027 |
| 5. Self-assessment support | Guides Default-class self-assessment without a notified body | ~90% of products are Default class and self-assess |
| 6. Transparent pricing + fast start | A published price and a working setup in an afternoon, not a procurement cycle | Small teams cannot absorb enterprise onboarding |
The rest of this guide unpacks each row and the red flags that fail it.
Does it actually generate and maintain an SBOM?
Not "can it import an SBOM" — can it make one from what you already have, and keep it current? The right tool takes your lockfile (package-lock.json, requirements.txt, go.mod) or a simple firmware component list and produces a valid CycloneDX file, then regenerates it on every release so it never drifts out of date. If you are new to this, our guide on what an SBOM is covers the formats and free tools first.
Red flag: a product that is SBOM-only. Generating the parts list is the easy 10% of CRA compliance. If that is all a tool does, you still have monitoring, reporting and documentation to solve yourself. See Nordchecks vs sbomify for how an SBOM generator compares with an end-to-end tool.
Does it monitor daily — and filter the noise?
An SBOM is only useful if something watches it. The Black Duck (formerly Synopsys) OSSRA report found an average of 581 vulnerabilities per commercial codebase — a figure that varies by year and report, but makes the point: raw scan output is a wall of alerts, most of them irrelevant. Good software matches your SBOM against vulnerability databases daily and shows you the open critical and high findings that need attention, not forty low-severity entries you will ignore.
Just as important, every finding should carry a recorded triage decision — fix planned, accepted risk, or not applicable. That record is your compliance evidence. A scanner that dumps CVEs without letting you triage and log them leaves you re-doing the assessment by hand.
Does it run the reporting clock?
From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA and their national CSIRT on a fixed sequence: an early warning within 24 hours, a vulnerability notification within 72 hours, and a final report within 14 days. Weekends included. This is the deadline most tools ignore entirely.
Check for a live countdown from the moment you became aware, a named responsible person, the correct CSIRT, and pre-filled notification templates — so filing is a fill-in exercise, not a scramble. A tool with no reporting workflow at all is the single biggest red flag on this list, because reporting is the first obligation to bite.
Does it generate the documents?
By 11 December 2027, every in-scope product needs a technical documentation file per Annex VII and a signed EU Declaration of Conformity. Both reference your SBOM, risk assessment and vulnerability-handling process. Software that generates these from data you already entered — and regenerates them when the product changes — saves you assembling a compliance file by hand and keeping it in sync. If a tool has no documentation output, you are still writing the technical file yourself, which is most of the actual work.
Does it support Default-class self-assessment?
Roughly 90% of products fall into the Default class and can self-assess — no notified body required. Password managers, firewalls, VPNs and network management tools sit in the Important classes; hypervisors, hardware security modules, smartcards and smart meter gateways are Critical. Good software knows the difference and walks a Default-class manufacturer through self-assessment rather than pushing you toward a certification process you do not need. A tool built only for the Critical-class minority will overcomplicate the common case.
Most CRA tools cover one corner - an SBOM, or a scanner, or a document template - and leave you to wire the other three obligations together and keep them current.
Nordchecks does all six in one place: SBOM per release, daily monitoring with triage, ENISA reporting readiness, and generated Annex VII docs plus the Declaration of Conformity.
Try Nordchecks freeBuild it yourself vs buy a tool
You can assemble a DIY stack from free open-source parts, and for some teams that is the right call:
| DIY open-source stack | Purpose-built tool | |
|---|---|---|
| SBOM | Syft or cdxgen (free) | Generated and versioned for you |
| Monitoring | Wire a scanner to OSV/NVD yourself | Daily, de-noised, with triage log |
| Reporting | Build your own playbook + templates | Countdown and pre-filled notifications |
| Documentation | Write Annex VII from a template | Generated from your data |
| Real cost | Free in licenses, expensive in maintenance | A monthly fee, near-zero maintenance |
The DIY route is legitimate if you have DevOps capacity and time. The catch is that the work is not writing the tooling — it is maintaining it: keeping the scanner updated, filtering false positives, mapping each release to its conformity file, and doing it without a compliance department. That is exactly where DIY stacks and spreadsheets quietly rot. Our guide on how to automate CRA compliance walks through the trade-off in detail, and Nordchecks vs spreadsheets shows what the manual approach costs over time.
Red flags at a glance
- SBOM-only. Solves the easy tenth and calls it compliance.
- No reporting workflow. Ignores the obligation that bites first, in September 2026.
- No document generation. Leaves the technical file — most of the work — to you.
- Enterprise-only pricing. A "contact sales" button and no public price usually means a contract sized for a compliance team, not a five-person product company.
- Slow time-to-value. If you cannot upload a lockfile and see your CRA status the same afternoon, the tool is built for a different buyer.
On price specifically: transparent, published pricing is itself a signal the product is built for small manufacturers. Nordchecks is free during early access, then €99/month for a single product (Starter) and €249/month for a product range (Pro) — no sales call to find out. If you are evaluating a named alternative, Nordchecks vs CRA Evidence compares the two feature by feature.
Putting it together
The right question is not "does this tool do CRA compliance" — every vendor says yes. It is "which of the six capabilities does it actually cover, and what am I left to do by hand?" Score each candidate against the table at the top of this guide. A good CRA compliance tool covers all six, keeps them current without maintenance, and tells you its price up front. Anything less, and you are buying part of a solution and building the rest yourself.
Before you shortlist any tool: check your product's scope and risk class free — it takes three minutes and tells you which of the six capabilities you even need.