How to automate CRA compliance (instead of managing it in spreadsheets)

Most teams start their CRA compliance in a spreadsheet: a tab listing components, a tab tracking vulnerabilities, a document template for the technical file. It works — until the second release. Then the SBOM is out of date, a new CVE surfaced that nobody checked, the reporting contact left the company, and the "compliance" you had six weeks ago no longer reflects the product you ship today.

The Cyber Resilience Act isn't a one-time project you file and forget. It's continuous: an SBOM per release, monitoring that never stops, reporting readiness that has to survive a weekend, documentation that stays current. That's exactly the kind of work spreadsheets fail at — and exactly the kind that's worth automating. Here's how.

Not sure the CRA applies to your product yet? Run the free scope check first — three minutes, no signup.

What actually needs to stay current

Four things drift out of date the moment you stop maintaining them by hand:

1. Your SBOM — changes with every release. A component added, a version bumped, a library removed. A stale SBOM fails its purpose: it can't tell you whether a new vulnerability affects you.
2. Your vulnerability status — new CVEs are published daily. A component that was clean last month may carry a known, exploited flaw today. Manual checking means you find out late, or not at all.
3. Your reporting readiness — from 11 September 2026 you have 24 hours to report an actively exploited vulnerability. You can't assemble a process during the incident; it has to already exist.
4. Your technical documentation — the Annex VII file and Declaration of Conformity reference your current SBOM and risk assessment. Every time the product changes, they're a little more out of date.

The spreadsheet approach handles all four badly, because it depends on someone remembering to update it. Automation removes the remembering.

The four things to automate

1. SBOM generation. Instead of maintaining a component list by hand, generate it from what you already have — your lockfile (package-lock.json, requirements.txt, go.mod) for software, or a one-time inventory for firmware. The right tool builds a valid CycloneDX SBOM from that and regenerates it on every release, so it's never stale. If you have a build pipeline, this can run automatically on each release via an API.

2. Vulnerability monitoring. Rather than checking components against CVE databases yourself, automate a daily scan of your SBOM against sources like OSV and the NVD. New findings surface as alerts — and, crucially, the good tools filter the noise: you see open critical and high issues that need attention, not a wall of forty low-severity entries. Each finding gets a triage decision (fix planned / accepted risk / not applicable) that becomes your compliance record.

3. Reporting readiness. Automate the playbook: a defined responsible person, the correct national CSIRT, pre-filled ENISA notification templates, and a live 24h/72h countdown from the moment you became aware. When an incident hits, filing is a fill-in exercise, not a scramble.

4. Documentation. Generate the technical file (Annex VII) and the EU Declaration of Conformity from the data you already have — product details, SBOM reference, risk assessment, vulnerability-handling process — and regenerate them when the product changes, so they never fall behind.

Build it yourself vs use a tool

You can automate each piece with separate open-source tools: Syft for SBOMs, a scanner for vulnerabilities, your own scripts to glue it together, a template for documents. For a team with DevOps capacity and time, that's a legitimate path.

For most small manufacturers, it isn't — because the work isn't writing the tooling, it's maintaining it: keeping the scanner updated, filtering false positives, wiring the SBOM into the documentation, tracking which release maps to which conformity file, and doing all of it without a compliance department. That maintenance is where spreadsheets and DIY scripts quietly rot.

This is the gap purpose-built CRA compliance software fills: it does the four steps above in one place, keeps them current automatically, and speaks the manufacturer's language rather than requiring you to become a security engineer.

What "automated" looks like in practice

A working setup does this without you thinking about it:

• You upload a lockfile once (or connect your pipeline to push it on every release)
• The SBOM is built and versioned automatically
• Every day, components are matched against vulnerability databases; genuinely new findings are flagged
• Your CRA readiness — SBOM present, monitoring active, reporting set up, documents generated — shows at a glance per product
• Your technical file and Declaration of Conformity generate from that same data, always reflecting the current product

The difference from the spreadsheet is not features — it's that it stays true without maintenance. That's the whole point of automating compliance: turning a task you have to remember into one that just runs.

Nordchecks does exactly this — SBOM, daily monitoring, reporting readiness and documentation in one simple tool, free during early access. See how it works →

First step: check whether the CRA applies to your product — free, three minutes, no signup.