The Cyber Resilience Act, for the devices you ship

The EU Cyber Resilience Act applies to every product with digital elements sold in the EU, microcontroller firmware included. Pinscope keeps the SBOM of each build, checks it against the known vulnerabilities every day, shows which devices run an affected build, and records what you decided about each one.

What the Act asks, and when

From Regulation (EU) 2024/2847:

From 11 September 2026: report actively exploited vulnerabilities and severe incidents in your products (Article 14): an early warning within 24 hours of becoming aware, a notification within 72 hours, a final report later.
From 11 December 2027: everything else, for products placed on the market from then on. Among it:
- a software bill of materials in a machine-readable format, covering at least the top-level dependencies (Annex I, Part II (1));
- vulnerabilities identified and remedied without delay, through security updates, separate from new features where that is possible (Annex I, Part II (2));
- a support period during which vulnerabilities are handled, of at least five years unless the product is expected to be in use for less (Article 13 (8)).

What Pinscope does for it

An SBOM with every build. Attach the SPDX or CycloneDX file your build writes to the firmware it belongs to, by hand or from CI. It stays with that image.
Known vulnerabilities, every day. The packages linked into the firmware are checked against the NVD each day, with the matching Espressif's own checker uses: on ESP-IDF 5.5.3 it finds the same vulnerabilities as idf.py sbom-check, and leaves out the ones Espressif has excluded.
Which devices are affected. Each device reports the build it runs, so a vulnerability shows up with the devices that carry it, not only the image.
A decision for each one. Mark a vulnerability as affecting you, not affecting you, or fixed, with a note on why. The decision is kept with who made it and when.
A new vulnerability reaches you. By email and webhook, the day it appears in the NVD for something you ship.
The fix reaches the devices. Firmware updates over the air, to one device or the fleet in waves that stop at the first failure, with rollback (MCUboot on Zephyr, two OTA slots on the ESP32, A/B partitions on the Pico 2 W).
The support period of the project, shown with the rest, and a report of all of it as JSON or CSV, to keep as evidence or hand to a customer.

What it does not do

The Act asks for more than this, and some of it only you can do: the risk assessment, the technical documentation, the conformity assessment and the CE marking, a policy for coordinated vulnerability disclosure, and the report itself to the authorities. Pinscope gives you the facts those need: what is in each build, what is vulnerable, where it runs, what you decided and when you fixed it. This page is not legal advice.

An SBOM from your build

Pinscope reads SPDX (tag-value, JSON, 3.0) and CycloneDX. The build tools already write them:

# ESP-IDF (pip install esp-idf-sbom)
idf.py sbom-create          # writes build/<project>.spdx

# Zephyr
west spdx --init -d build
west build ... -- -DCONFIG_BUILD_OUTPUT_META=y
west spdx -d build          # writes build/spdx/*.spdx

Arduino and PlatformIO builds have no SBOM generator of their own yet. Any SPDX or CycloneDX file of the build works, written by hand or by another tool, as long as each package carries its CPE, the identifier the NVD uses (for example cpe:2.3:a:espressif:esp-idf:5.5.1:*:*:*:*:*:*:* for the ESP-IDF that arduino-esp32 is built on); packages without one are listed but not checked.

Attach it to the firmware it belongs to, in the dashboard's Security tab, or from CI together with the image:

curl -fsSL https://pinscope.dev/ci.sh | sh -s -- build/app.bin --sbom build/app.spdx

The GitHub Action takes the same file as its sbom input.

Help with the cost, in the EU

Until 11 December 2026, the EU-funded SECURE open call co-funds Cyber Resilience Act work at small and medium-sized companies in the EU: half of the cost, up to €30,000. Among the goods its Annex 2 gives as examples are SBOM management and dependency scanning tools, vulnerability scanners, and secure update solutions for embedded and IoT devices; software licences count for the months of the project, at most 180 days. Whether a purchase is accepted is up to the call's evaluators, for each project.

Pinscope's own part

The Pinscope library is a component of your firmware, so you need the same facts about it as about the rest:

Its SBOM. Every repository carries sbom.spdx.json (SPDX 2.3) for its release: Pinscope's own code, and the public-domain ref10 and poly1305-donna code its crypto is built on. It has no other third-party code; ESP-IDF, Zephyr or the Pico SDK come from your build and your SBOM. ESP32, Zephyr, Pico 2 W, ESP8266.
Reporting a vulnerability in it. Write to security@pinscope.dev (also in security.txt) or report it privately on GitHub. We answer within 3 working days, fix it in a new release and publish an advisory. The policy is in each repository's SECURITY.md.
Fixes reach you. A security fix goes into the newest release, without changes to the API; the dashboard shows which of your devices still run an affected version of the library.

Try it

See it first, without an account: the live demo has a firmware with the SBOM of an ESP-IDF 5.5.3 build attached; open its Security tab.

It is part of the paid plans, from Maker up (pricing). Open the Security tab of a project, attach the SBOM of a build you have uploaded, and the list fills in once the NVD has answered: from a few seconds to a few minutes, depending on the number of packages. The docs have the details.

Shipping hundreds of devices, or need it for a SECURE application? Write to hello@pinscope.dev and we will go through it with you.