The product is the device: introducing Devices in EmbedForge

In EmbedForge, one template builds one image. That works well for a build. It does not always match what you sell.

Today we are adding Devices: a way to treat everything that runs on one board as one product, and to release and document it together.

One board, several images

Take the Arduino UNO Q. It has two processors on one board: a main processor that runs Linux, and a microcontroller that runs Zephyr. Before Linux starts, boot firmware brings the board up. So one small board already needs two images, and often a third.

This is common. Industrial gateways pair Linux with a separate safety controller. Many modules need extra firmware from the chip vendor. Each piece is built differently, and each can have its own vulnerabilities.

Until now, each of those images lived in EmbedForge on its own, with its own SBOM and its own security report. That is fine for the engineers building it. It does not answer the question your customers and regulators will ask: what is in this product, and for how long will you keep it secure?

Why the CRA looks at the device

The EU Cyber Resilience Act sets its obligations for the product you place on the market, not for the individual images inside it. The component list, the support period and the declaration of conformity all describe the product as a whole.

A vulnerability in the microcontroller firmware is a vulnerability in your product, even if the Linux image is clean. Three SBOMs with three different support dates are three partial answers. The regulation expects one.

What a Device gives you

A Device groups the builds that make up one product. It can include Linux, microcontroller firmware and UEFI boot firmware built with EDK II. For the UNO Q, that means the Linux image and the Zephyr firmware. EmbedForge takes care of building them in the right order and keeping them together.

What you get back is simple:

• One SBOM that lists every component of the device, across all its images, boot firmware included.
• One support period, declared once for the product your customers buy.
• One declaration of conformity, drafted for the device, ready for you to review and sign.

Every release of a Device records exactly what shipped. Months later, when a new vulnerability is published, you can check whether it affects version 1.2 from the release record, not from memory.

You can also set up and build a Device from your AI agent, through the EmbedForge MCP server.

Boot firmware included

EmbedForge now builds UEFI firmware with EDK II as a sixth platform, next to Yocto, Buildroot, Zephyr, Debian and Ubuntu. An EDK II build can join a Device as its boot firmware, so the firmware that starts the board is covered by the same SBOM and the same declaration of conformity as everything that runs after it.

One thing does not change: EmbedForge produces the evidence, and you remain the manufacturer. Signing the declaration and reporting vulnerabilities stay with you.

Try it

Devices are available to early access users. If your product needs more than one image, request access and tell us about your board.