> ## Documentation Index
> Fetch the complete documentation index at: https://docs.adsumnetworks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# CRA readiness on the firmware we just built

> An SBOM, a ranked CVE scan and a secure-by-design posture check run on a real gateway build in the same session that produced it. 175 components, 46 known CVEs, five posture gaps, and the top one closed and re-verified on the board.

Chapter three of [the gateway build](/ble-wifi-gateway). The gateway scans, it publishes, and it has been running for two chapters. **In Europe, working is no longer the bar.**

<iframe className="w-full aspect-video rounded-xl my-6" src="https://www.youtube.com/embed/uwl76c6FuY0" title="CRA readiness with an AI agent: SBOM, CVE scan, and fix on a real gateway build" frameBorder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowFullScreen />

## Why this chapter exists

The EU Cyber Resilience Act says products with software in them have to be secure, **and that you have to prove it**. The first obligations, reporting actively exploited vulnerabilities, apply from **September 2026**. The essential requirements bind from **11 December 2027**, and they include serving security updates for years after you ship.

This ran in the same session as the build. No new project, no separate tools.

## First, an SBOM

A software bill of materials is the **ingredient list of your firmware**: every library actually inside the build, not what the source tree claims.

The law asks for exactly this for a practical reason. When a vulnerability appears in some library, **this list is how you find out whether you owe your customers an update.**

|                                                         |                                                             |
| :------------------------------------------------------ | :---------------------------------------------------------- |
| Components found                                        | **175**                                                     |
| Known CVEs matched                                      | **46**                                                      |
| Further EUVD advisories to verify                       | **93**                                                      |
| Components with an identifier the databases could query | **6 of 175**                                                |
| Generated by                                            | `west spdx` on the nRF side, `esp-idf-sbom` on the ESP side |

<Note>
  **The last row is the one to read.** Most embedded components carry no CPE or PURL identifier, so no database can be asked about them. The report lists them as unqueried, never as clean. A scanner that returned "no findings" on this build would be describing its own blind spot, and an auditor would notice.
</Note>

## Then, how the device is built

Four questions, in the plain language a design review would use:

|                       |                                                                   |
| :-------------------- | :---------------------------------------------------------------- |
| **Secure boot**       | Does this chip verify the firmware before running it?             |
| **Signed updates**    | Can someone push fake firmware to it?                             |
| **Encrypted storage** | Are the Wi-Fi and MQTT passwords sitting in plain text?           |
| **Debug port**        | Can anyone with physical access read out your code and your keys? |

**A development build fails several of these, and this one did.** The check found **five posture gaps**, ranked so the biggest is first, with the config line behind each one.

This is the list an experienced engineer would flag in a design review. The difference is that it took a minute, with the evidence attached to each item, and that **it never claims we are compliant.**

<Warning>
  Conformity is a formal process with legal weight, and this does not replace it. It gives you evidence and a head start, and it says so on every page it writes. See [CRA readiness](/cra-readiness) for what the check is and is not.
</Warning>

## Then close the top gap

The last step was not a report. We asked it to close the highest-ranked gap, and it **wired the change into the project, rebuilt, and re-verified without leaving the agent.**

New firmware on the same board. The scanner, the dashboard and the MQTT uplink all still working, with the gap closed.

Run the check again and it is gone: an updated SBOM and an updated posture, **generated from the firmware that is actually running** rather than from the one we meant to build.

## The point

CRA is a firmware problem before it is a paperwork problem. Start where the truth is.

<CardGroup cols={2}>
  <Card title="What the check is" icon="shield-check" href="/cra-readiness">
    The capability in full: what one click gives you, how to run it on your own project, and what it is not.
  </Card>

  <Card title="1 · Base wiring and build" icon="arrow-left" href="/ble-wifi-gateway">
    Back to the start: one written spec to firmware on two chips.
  </Card>
</CardGroup>

## Verified with

|                  |                                                                                      |
| :--------------- | :----------------------------------------------------------------------------------- |
| Run on           | The firmware built in chapters one and two, on a Fanstel BWG840X                     |
| Report generated | 2026-08-11                                                                           |
| Extension        | 0.2.0                                                                                |
| Toolchains       | NCS 3.3.1 · Zephyr 4.3.99 · ESP-IDF 5.5.4                                            |
| Databases        | OSV, EU EUVD and NVD, as of the scan date                                            |
| Artifacts        | `compliance/CRA_READINESS.md`, its JSON companion, and the SPDX SBOMs for both chips |