Software supply chain · ECZ-ID IoT

SBOM & software-composition evidence

Turn software composition and provenance into evidence a buyer can actually review.

The SBOM solution organises software-component, dependency and provenance evidence around the digital product being supplied, so reviewers can understand what is in scope and what changed.

Open in TrustOps All IoT products

Type: Solution
Price: Not restated on this site; TrustOps publishes the current price and availability
Acquired and paid in: TrustOps
Operated in · proved by: Dashboard · Resolver

The problem

Why it matters.

Buyers, retailers and regulators ask what software a connected product runs and where it came from. An SBOM file on its own is detached from the device it describes and goes stale with the next firmware release.

Built for

Connected-product manufacturers shipping firmware and companion software.
Teams facing enterprise, retailer or regulatory supply-chain questions about a device.
Organisations that want SBOM evidence tied to an enduring device identity rather than an isolated file.

What changes

More reviewable software-composition evidence.
A clearer link between a release, its product identity and its supporting provenance.
Less manual reconstruction of component evidence during customer or regulatory review.

What you receive

Concrete deliverables, not a vague trust score.

Structured software-composition evidence around the relevant ECZ-ID subject.
Release and provenance context where supplied by the customer workflow.
Support for buyer-facing evidence packaging.
Managed and enterprise depth for larger programmes.

Composition evidence, tied to the device

Device: The device's enduring ECZ-ID
Release: The firmware or software release the composition describes
Composition: Component and dependency evidence you supply
Provenance: Build and source context, where supplied
Boundary: Describes composition — does not declare the software secure

Illustrative structure. Contents come from your own build and supply-chain tooling.

How it works

A short path from need to something usable.

Identify the software product or service whose composition must be evidenced.
Collect the relevant composition and provenance inputs.
Organise them against the enduring ECZ-ID identity and release context.
Re-use and update the evidence as dependencies and releases change.

How it relates to your Passport

The Passport gives the connected device one enduring identity across releases. SBOM evidence attaches to that identity and its release context, so reviewers see one product rather than a pile of files.

Use cases

Attaching each firmware release's composition evidence to the same device identity.
Answering an enterprise buyer's supply-chain review for a connected product.
Keeping composition evidence current as components change, and after the device changes hands.
Feeding the Connected Product Cybersecurity Evidence & CRA/PSTI Readiness Kit.

Tiers and price

Price and availability

Prices and what can be bought today come from TrustOps, which owns every purchase, entitlement and renewal. This site does not restate this product's price; TrustOps publishes its current tiers, price and availability, and shows them before anything is bought.

How it is arranged

TrustOps acquires
TrustOps publishes the tiers and holds payment and entitlement whenever it is offered.
Dashboard operates
Once you hold it, it appears in your Dashboard, where you operate it.
Resolver proves
Public facts stay on the Resolver; holding it never changes what a record proves.

Privacy, security and evidence

What is collected, published and kept.

Evidence you supply stays yours; publication requires your consent.
ECZ-ID does not turn missing source evidence into verified facts.
LedgerCore keeps eligible evidence as local records; ledger anchoring is not live yet.

Boundaries

The claims stop here.

An SBOM describes composition and evidence; it is not a declaration that software is secure.
ECZ-ID does not turn missing source evidence into verified facts.

Integrations and questions

Works with what you already run.

The SBOM and provenance outputs your firmware and software builds already produce.
SDK Passports for the packages your firmware is built from.
LedgerCore for evidence entries.

Is a firmware version a new Passport?: No. Firmware versions are never separate Passports. Each release's composition evidence attaches to the device's one ECZ-ID.
Does an SBOM prove my connected device is secure?: No. An SBOM describes composition. It is not a declaration that software is secure.
Do I have to change my build?: No. The solution organises the composition and provenance evidence you already produce.

Keep the identity free. Everything above it is optional.

Your IoT Passport stays free. SBOM & software-composition evidence sits above it; TrustOps shows its current state.

Open in TrustOps