Skip to main content
The EU Cyber Resilience Act (CRA) brings security obligations for products with digital elements, with the first of them, reporting exploited vulnerabilities, starting in September 2026. A machine-readable SBOM is one of its named artifacts. Adsum turns the readiness work into one click: run it on your build and get a readiness snapshot on both Nordic nRF and Espressif ESP, so you can see where you stand and fix the biggest gaps before the deadlines.
This is a readiness aid, not a conformity assessment and not legal advice. It reports your build’s literal evidence and what to verify. Only a notified body or your own formal assessment establishes conformity. Adsum is an AI-based coding agent and can make mistakes, so the conclusions are yours to verify.
Adsum IoT Coder CRA readiness report with the readiness-aid disclaimer, a component and CVE count, and the SPDX SBOM section for the EU Cyber Resilience Act

The CRA readiness report (CRA_READINESS.md): the readiness-aid header, an at-a-glance count, and the SBOM (SPDX) section.

Here is the whole check running on a real gateway build, in the same session that built the firmware: SBOM, scan, posture, and the top finding fixed and re-verified on the hardware.
From the gateway build: built in chapter one, debugged in chapter two, and CRA-checked in chapter three with the real numbers.

​
What one click gives you

  • SBOM from your real build. A machine-readable software bill of materials (SPDX), the CRA’s named artifact, generated from your actual build with the vendor-native tools: every library really inside the binary, not a guess from the source tree. It is the ingredient list of your firmware, and when a vulnerability appears in some library it is how you find out whether you owe your customers an update.
  • A known-CVE scan of that SBOM, ranked. The component list is checked against the known-vulnerability databases (OSV, EU EUVD, NVD), and the findings are ranked by what actually applies to your exact build. Every finding is dated and attributed to its source, because absence of a finding is not a clean bill of health.
  • Secure-by-design posture against your build’s actual configuration: secure boot, signed updates, debug-port lock, secure pairing, secure storage and more, each with the plain-English requirement and the fix, ranked so you tackle the biggest gap first.
  • Or bring one CVE, and close it. Starting from a vendor advisory instead? It confirms the affected component is really in your build (a literal SBOM lookup), links the advisory, then helps you bump the version, rebuild, and regenerate the SBOM.
  • Fix in the loop, not just flag. It helps you wire the top fix (a secure bootloader, for example), rebuild, and re-verify, without leaving the agent.
  • Version advisories for your detected SDK (links to review, never an automatic verdict).
It tells you which CRA date applies to you and writes a compliance/ folder (report + machine-readable JSON + SBOM).

​
Run it

1

Open your project, or none at all

Run it on your own nRF or ESP firmware, or try it on a bundled sample with nothing open.
2

Pick CRA SBOM & Fix

From the home workflow cards, choose CRA SBOM & Fix. The agent builds the SBOM, reads your real config, and drafts the readiness report.
3

Read the report, then close the top gap

Open compliance/CRA_READINESS.md. The posture gaps are ranked, so start at the top: wire the fix, rebuild, and re-verify in the same loop.

​
What it is not

  • Not a conformity assessment or certification. It never asserts “compliant” or “conformant”. Only a notified body or your formal assessment establishes that.
  • Not a discoverer of unknown vulnerabilities. The scan matches your components against published CVEs in the public databases, as of the scan date, and says so on every finding. It does not find zero-days, and identifier-sparse embedded components that the databases cannot match are reported as unqueried, not as clean.
  • Not legal advice. It surfaces evidence and the requirement in plain English; the interpretation is yours.
See Limitations for the full list of what it does not do, and the roadmap for what comes next.