Skip to main content
Chapter three of the gateway build. The gateway scans, it publishes, and it has been running for two chapters. In Europe, working is no longer the bar.

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.
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.

Then, how the device is built

Four questions, in the plain language a design review would use: 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.
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 for what the check is and is not.

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.

What the check is

The capability in full: what one click gives you, how to run it on your own project, and what it is not.

1 · Base wiring and build

Back to the start: one written spec to firmware on two chips.

Verified with