How many SBOMs does a CRA product need when it has firmware and a cloud back end?

A Cyber Resilience Act SBOM for a connected device covers the firmware and each back-end application that the manufacturer built and the device or its app calls directly. Back-end systems that the device never calls stay outside the SBOM.

A typical case is firmware for one device, a dozen back-end applications, and an SBOM uploader that takes one file. The work has two steps. First, sort the twelve applications with the two tests in Article 3(2). Then merge the SBOMs of the applications that pass into one CycloneDX file for each product.

Key takeaways

• Article 3(1) of the Cyber Resilience Act makes the remote data processing solutions of a device part of the product, so their software belongs in the product SBOM.
• A back-end application is a remote data processing solution when the device needs it for a function and the manufacturer designed or developed it, according to Article 3(2).
• Commission guidance C(2026) 5252 limits remote data processing to the systems that interact directly with the product, so a data warehouse behind the device API stays outside the SBOM.
• CVD Portal stores one SBOM for each product, and a product's own SBOM fully replaces the account-wide SBOM for that product.
• A hierarchical CycloneDX merge puts the firmware SBOM and the back-end SBOMs into one file and keeps each application as a separate branch of that file.

What does the CRA count as one product?

A product with digital elements is "a software or hardware product and its remote data processing solutions", in the words of Article 3(1). The device, its firmware and the cloud services that the device needs are therefore one product.

Article 3(2) defines remote data processing with two conditions that must both be true. The manufacturer designed and developed the software, or someone did so under the manufacturer's responsibility. And the absence of the processing would prevent the product from performing one of its functions. Recital 11 gives an example. A mobile application that needs an API or a database "provided by means of a service developed by the manufacturer" brings that service into scope.

The Commission guidance C(2026) 5252 of 27 July 2026 applies the same idea to companion apps. In example 9 of section 2.4, a fitness wearable and the smartphone app that displays its measurements are a single product, although the app comes from an app store. See the CVD Portal summary of all worked examples.

Does the SBOM have to cover the back end?

The SBOM has to cover the back-end software that is a remote data processing solution. The CRA has no separate SBOM rule for the back end. Two definitions give the answer together.

Article 3(39) defines the SBOM as a formal record of the "components included in the software elements of a product with digital elements". Article 3(1) makes the remote data processing solution part of that product. Its software elements are therefore software elements of the product. Annex I Part II point 1 asks for an SBOM "covering at the very least the top-level dependencies of the products".

Two limits follow from the same text.

• The SBOM covers software elements. The CRA does not ask for a hardware bill of materials, so the circuit board and its chips stay out. The firmware that runs on the chips stays in.
• The legal floor is top-level dependencies. BSI TR-03183-2 and the CISA 2026 minimum elements ask for more. Our article on the 2026 minimum elements explains where they differ.

Which of my back-end applications count?

Ask two questions for each application. Does the device or its app call this application to perform a function? Did you design and develop it, or did someone do so under your responsibility? Both answers must be yes.

The guidance adds a third rule in its banking example, section 8.3.1. The banking interface that the app calls is remote data processing. The ledger and account systems behind it are not, because "the CRA covers only those parts of the system that interact directly with the product with digital elements". The manufacturer must still assess the risks of those systems and mitigate them through measures in the product.

Back-end system	Remote data processing solution?	In the product SBOM?
Device API or MQTT endpoint that the device connects to	Yes	Yes
Firmware update service that the device downloads from	Yes	Yes
Login and account service of the companion app, built by you	Yes	Yes
Analytics, billing or support tools behind the device API	No. The device does not call them directly (section 8.3.1)	No. Assess their risk
Third-party SaaS that the product calls, for example a push notification service	No. The guidance treats it like a component (section 8.3.3)	No. Apply due diligence
Cloud infrastructure under your applications	No. Record the reliance in the technical documentation (section 8.3.2)	No
Company website, web shop, CRM and ERP	No	No

In our reading, third-party software that you deploy as part of a remote data processing solution is a component of that solution. A database server or message broker that runs in your containers goes in the SBOM. A managed database from a cloud provider is infrastructure, so you document the reliance on the provider instead.

Use the table on your twelve applications before you generate anything. Applications that fail the tests can keep their SBOMs for your own security work. Those SBOMs do not go into the product file.

Why does CVD Portal take one file per product?

Annex VII point 8 files the SBOM in the technical documentation of a product. CVD Portal follows that structure. It stores one current SBOM for each product and one account-wide SBOM, and each upload replaces the SBOM at its scope.

A product's own SBOM fully replaces the account-wide SBOM for that product. The technical file, the exposure search and the SBOM coverage of the product then read the product file alone. This makes one common shortcut fail. Suppose you upload the firmware SBOM to the product and the back-end SBOM to All products. The technical file of the product then lists the firmware only. The back end is still scanned as the account-wide list, and a serious finding there creates a review trigger on every assessed product with a note to confirm whether the product uses the component. The authority that reads the technical file sees no back end.

The account-wide SBOM suits a manufacturer with one product, or with one component list that is true for every product. A device with its own firmware and its own back end needs its own merged file.

How do I merge the firmware SBOM and the back-end SBOMs?

Merge them with the CycloneDX CLI in hierarchical mode. The merged file has the product at the top, and each input SBOM becomes a branch under it with its components nested inside.

cyclonedx merge --hierarchical \
  --name "Thermostat T1" --version "4.2.0" \
  --input-files firmware.cdx.json device-api.cdx.json ota-service.cdx.json \
  --output-format json --output-file thermostat-t1.cdx.json

Hierarchical mode needs --name and --version for the merged product. Each input file needs a metadata.component entry that names the application, or the merge stops with an error. Check each input file for that entry before you merge.

Upload the merged file in CVD Portal under Settings, SBOM Registry, and set This SBOM covers to the product. On 3 November 2026 we ran the uploader's parser on a file with the structure of a hierarchical merge, made from one firmware SBOM and two back-end SBOMs. The parser read every nested component, and it also listed the firmware and the two applications as components.

The uploader has these limits.

Limit	Value
Files for each product	One current SBOM, plus one archived SBOM for each recorded release
File size	5 MB
Unique components	10,000
Formats	CycloneDX JSON, SPDX 2 JSON, SPDX 3 JSON, and dependency manifests such as package.json
Not accepted	XML SBOMs and SPDX tag-value files

A library at the same version in two applications is stored once. A finding then names the product and the component. To see which application ships the component, search the merged file. The branch that holds the component names the application.

What if several devices share one back end?

Put the back-end SBOMs into the merged file of each device that calls the back end. Three devices that use one device API get three merged files, and each file contains the same device API branch. A component in the shared back end then shows up under every product that ships it, which is the answer you need when an advisory for that component is published.

Script the merge, so that one change to the back end rebuilds every product file. A manual copy of the same branch into three files goes out of date after the first deploy.

How do I keep the file current when the firmware and the back end release on different schedules?

Rebuild and upload the merged file each time one of its parts changes. Firmware changes at each release. A back end can change every week. CVD Portal flags an SBOM that is older than 90 days, and a scan only knows the versions that the stored file pins.

Two practical routes exist.

1. Keep the newest SBOM of each part as a build output. Firmware builds publish firmware.cdx.json, and each back-end pipeline publishes its own file.
2. Add one job that downloads the newest parts, runs the merge and pushes the result to the product. The CI endpoint takes a productId and needs the Enterprise plan.

jq -n --rawfile content thermostat-t1.cdx.json --arg productId "$PRODUCT_ID" \
  '{filename: "thermostat-t1.cdx.json", content: $content, productId: $productId}' |
curl -fsS -X POST https://cvdportal.com/api/v1/sbom \
  -H "Authorization: Bearer $CVD_API_KEY" -H "Content-Type: application/json" -d @-

For a firmware release, add releaseVersion to the body. CVD Portal then also keeps the file in the archive of that release. BSI TR-03183-2 asks for an SBOM for each software version, and the archive keeps one for each release. See SBOM Registry for how the newest release is found.

Which components can the portal check for vulnerabilities?

A component is checked when the SBOM gives an identifier that a database can match.

The component carries	The portal checks it against
A package URL (purl) with a version	OSV.dev
A CPE that includes the version	The NVD
Neither	Nothing, and the component is counted as not checked

Back-end SBOMs from package managers usually carry purls. Firmware SBOMs often do not. A component such as BusyBox or OpenSSL in a custom Linux image needs a CPE with a version, or the scan cannot match it. Check the firmware SBOM for identifiers before you merge it.

The NVD check has a limit. One scan sends up to 20 CPE components to the NVD, because the NVD allows few requests in each 30 seconds. Components past that number stay unchecked in that scan. A firmware SBOM with hundreds of CPE-only components is therefore only partly checked today.

The OSV.dev check has a limit too. One scan sends up to 2,048 components to OSV.dev. A product SBOM with more package components than that is only partly checked, and the portal does not count the scan as a complete check. A merged file of a dozen back-end applications can pass that number. The free SBOM validator shows the fields that each component has.

Do I have to publish the SBOM?

The CRA does not require you to publish the SBOM. Annex VII point 8 asks for it "further to a reasoned request from a market surveillance authority". Annex II point 9 applies only if you decide to make the SBOM available to users. Then the user instructions must say where users can get it.

What to do this week

1. List the twelve back-end applications and sort each one with the table above.
2. Generate a CycloneDX SBOM for the firmware and for each application that is a remote data processing solution.
3. Check that every input file has a metadata.component entry and that firmware components carry a purl or a CPE with a version.
4. Merge the files with cyclonedx merge --hierarchical and upload the result to the product in CVD Portal.
5. Move the merge into a pipeline job, so that the product file changes when any of its parts changes.

Sources

• Regulation (EU) 2024/2847 (Cyber Resilience Act), CELEX 32024R2847, Article 3 points 1, 2 and 39, recital 11, Annex I Part II point 1, Annex II point 9 and Annex VII point 8.
• Commission guidance C(2026) 5252 of 27 July 2026 on the application of the Cyber Resilience Act, section 2.4 example 9 and sections 8.3.1 to 8.3.3.
• BSI TR-03183-2, Software Bill of Materials, version 2.1.0 of 20 August 2025.
• CycloneDX CLI, merge command reference.