Companies selling products built on ESPHome will soon be able to produce a software bill of materials (SBOM) for its firmware without editing it by hand. Two pull requests merged on 24 October 2026 make ESPHome write the metadata that Espressif's esp-idf-sbom tool reads. The author names the reasons directly: EN 18031 and the EU Cyber Resilience Act expect connected products to have an SBOM. The change is in the development branch, so it should arrive with ESPHome 2026.11.

What was missing

esp-idf-sbom could already turn an ESP-IDF build into an SBOM from build/project_description.json. ESP-IDF itself and components from Espressif's registry describe themselves, so they came out right. The code ESPHome adds did not. The project was labelled with the ESPHome version, ESPHome showed up as component-src with no version, supplier or license, and external components and converted PlatformIO libraries were either merged into it or listed without a version.

ESPHome now writes sbom.yml manifests into the build tree for the parts only it knows about:

  • the project, with the name and version from esphome: project: (nothing is written if project is not set);
  • ESPHome itself, with its version, the GPL-3.0-only license of its C++ runtime, the supplier and the repository; a git install is identified by its commit, a release by its version tag;
  • every external component as a separate package, with its repository and the commit it was built from; local external components get their own named package instead of being counted as ESPHome;
  • converted PlatformIO libraries, with name and version, unless the library ships its own manifest. Licenses are left out here, because library manifests often contain free text and esp-idf-sbom aborts on anything that is not valid SPDX.

For the same reason ESPHome only writes values that pass the tool's checks. A build that never runs esp-idf-sbom is not affected.

Supplier and security contact

The second pull request adds an optional sbom: block under esphome: project: for the details ESPHome cannot guess. supplier is the organisation that makes and supplies the firmware, contact is an email address for security reports and url is a web page for them. When the block is present, supplier is required, along with at least one of contact and url. The values end up as the supplier of the project package and as the manufacturer of the SBOM document, in both SPDX and CycloneDX output.

The block is accepted only on ESP32, because only ESP32 builds with ESP-IDF produce the manifests. On other platforms validation fails, so nobody ends up thinking they have an SBOM when they do not. A project license key was left out on purpose: esp-idf-sbom already combines the licenses of the parts.

The SBOM itself is still made by Espressif's tool, with esp-idf-sbom create build/project_description.json. The author tested both pull requests on a real product configuration with an ESP32-S3 and ESP-IDF 5.5.6, producing SPDX and CycloneDX files.

For a home user flashing a plug or a sensor, nothing changes. The audience is companies selling ESPHome-based devices in the EU, which until now had to assemble that list from several sources. The documentation for the new keys is still an open pull request.