Zephyr teams

The Cyber Resilience Act for a team building on Zephyr

Your firmware builds on Zephyr, and west spdx gives you four documents that point at each other, with module versions that are often commits. You need an SBOM that a vulnerability database can match, and you need it on every release, not once.

You also have a CI pipeline and a small team. The workflow has to fit into it: upload on each build, hear about new flaws without logging in, and keep the paperwork next to the release it describes.

Check an SBOM, free

What the Cyber Resilience Act asks of you

Component list (SBOM) — every piece of software inside your product, in a format machines can read (, source)
Vulnerability handling — finding, fixing and telling people about security flaws for as long as you support the product (, source)
Reporting to ENISA — telling the EU cybersecurity agency about an actively exploited flaw or a severe incident, in three steps (, source)

What Declarable does about it

Merges the four west spdx documents into one component list and flags what is missing.
Takes the SBOM from your CI on every build with an API key, so each release is recorded as it ships.
Emails you when a new vulnerability is published against a component in a saved release.
Handles the nRF Connect SDK layout, such as the Nordic modules and vendor blobs.
Counts the Article 14 deadlines if a flaw in your firmware is being exploited.

What it does not do

It does not build your firmware or run west for you.
It does not judge whether your product meets the Regulation, and it does not give legal advice.
It does not file reports for you. You submit them yourself on the ENISA platform.

Questions

Which files do I upload?: All four west spdx documents, and your .config if you want the compiled-in subsystems found. The Zephyr page lists them.
Does it work with the nRF Connect SDK?: The nRF Connect SDK is built on Zephyr. Its page covers what differs from plain Zephyr.
Can I upload from CI?: Yes, on the Maker and Studio and Fleet plans, with an API key. Each build posts its SBOM and the release is recorded as it ships. The setup is in /docs/ci. On the other plans, upload in the browser.
Do my files leave my browser?: The files are read in your browser. When you ask for a vulnerability check, only component identifiers are sent, not the files.

Check an SBOM, free

What Declarable is, and what it is not

A documentation aid. Declarable prepares drafts and checklists for you to review and edit.
Not legal advice. For a legal question about your product, ask a lawyer.
Not certification. Nobody at Declarable assesses or signs off your product. You sign your own declaration of conformity.
Not an assessment body. Some products need an outside assessment body: an An important product, class I. Self-assessment (module A) is open only if its maker applies in full a harmonised standard, a common specification or a European cybersecurity certification scheme at assurance level “substantial” or higher; otherwise a notified body takes part: modules B and C, or module H (Article 32(2)). Open-source software whose technical documentation is public may self-assess (Article 32(5)). product unless its maker fully applies a harmonised standard or one of the alternatives in Article 32(2), and those on the CRA's Annex III class II and Annex IV lists — the higher-risk product categories, where self-assessment is not enough. Declarable is not one. The scope check asks the questions that point to your category.
Not a filing agent. Declarable does not file reports for you. You submit them yourself on the ENISA platform.

Source for the assessment lists and when an outside body is needed: Annexes III and IV and Article 32 of Regulation (EU) 2024/2847 (Cyber Resilience Act), as recorded in legal state 2026.10.13-1.

The Cyber Resilience Act for a team building on Zephyr

You also have a CI pipeline and a small team. The workflow has to fit into it: upload on each build, hear about new flaws without logging in, and keep the paperwork next to the release it describes.