Know what's inside your IoT products. Keep security evidence connected.
Validate SBOMs, review software risk signals, trace supplier components, and organise CRA preparation evidence by product version.
- Free tools run in your browser — no upload
- No account to see a result
- Product workflow: Early Access
The free checks are live today. Product-version, supplier-traceability and evidence workflows are being built with design partners and are labelled Early Access or Planned wherever they appear. Up to 20 MB per SBOM, processed locally.
Valid is not the same as useful. This file passes the schema and still has components that no advisory feed can match. Read the full report.
What product security teams actually get asked
Not “do we have an SBOM”, but whether the inventory can be trusted, which versions a supplier change reaches, and what evidence exists for a review.
Can I trust the software inventory I received?
A schema-valid SBOM can still be unusable. Components without a package identity or an exact version can never be matched to an advisory, and the file will not say so.
Which product versions may be affected by a supplier update?
A component list describes one build. The harder question is which shipped versions contain the affected supplier module — and that needs the inventory connected to the product version.
How do I organise the information needed for security review and CRA preparation?
Scope, role, inventory quality and change history are the starting evidence. No vendor can certify compliance, but the gaps can be made visible and documented.
From a supplier component to a security record
Each link in the chain is useful on its own. The point of the product is to keep them connected, so the inventory is not a file that stops at the build server.
Illustrative Example. This chain shows the relationship the product is designed around. It is not a live scan of your product, and it does not imply that every step is generally available today.
- 01
Supplier component
A module arrives with a name, a version and often no package identity.
Input - 02
Firmware build
The image that links the module into the device software.
Input - 03
SBOM
The inventory generated from the build, validated for schema and identity quality.
Available now - 04
Product version
The record that ties a build to a version that actually shipped.
Early Access - 05
Security evidence
Review decisions, advisory status and release notes kept with that version.
Early Access
Three checks you can run before you talk to anyone
Validate a file, compare two releases, or work out CRA scope. Every tool runs on your machine, states its limits, and exports a report you can keep.
SBOM Validator
Validate CycloneDX or SPDX, then see which components cannot be matched to advisories.
SBOM Diff
Compare two firmware SBOMs and see exactly what entered or left the build.
CRA Scope Checker
Work out whether the CRA applies to your product, your role, and the likely risk class.
Also available: the X.509 Decoder for inspecting one certificate locally. It decodes fields and dates; it does not verify a chain.
One evidence base, three questions
The free tools are the entry point. The product workflow is where the inventory, product version and review evidence are kept together.
Be ready to show what is in your product, before anyone asks.
Know whether the CRA applies, what your component data can support, and which evidence is still missing.
Know which product versions a supplier change can reach.
Connect supplier components, product versions and software inventories so a supplier update becomes a reviewable impact question.
Make every firmware release traceable, from supplier component to update package.
Validate the build, compare it with the last release, and keep the evidence that a specific device image was authorised to ship.
A validator answers one question. The workflow keeps the answer.
A one-off SBOM check is useful. It does not know which product version the file belongs to, what changed since the last release, or which review decision was made when a supplier update arrived.
| Question | Typical one-off validator | EmbedHarbor today | EmbedHarbor direction |
|---|---|---|---|
| Is this file structurally valid? | Often | Yes — free, in the browser | Gate the release on the checks you choose |
| Can each component be matched to advisories? | Rarely stated | Yes, with a reason per component | Keep the readiness view with the version |
| What changed since the last release? | Sometimes, as a file diff | Yes — identity and exact version | Attach the change set to the release record |
| Which shipped versions contain this supplier module? | No | Not on the public site | Early Access — product-version traceability |
| Where is the review decision and evidence? | No | Not on the public site | Early Access — evidence with the version |
Claims you can check, and limits we state
This is a static marketing site with browser-local tools. The trust position is not a badge; it is the ability to inspect what happens to your data.
- Free tools process files in your browser — there is no upload endpoint.
- The website is static: no database, no application server, no account area.
- Every capability carries a status: Available now, Early Access or Planned.
- Results state what they do not prove. A schema pass is not a security certificate.
- No invented certifications, customer logos, ratings or compliance claims.
Browser-local checks
Available nowThe validator, diff, scope checker and certificate decoder run in the tab. No SBOM, certificate or answer set is transmitted.
Product workflow
Early AccessProduct-version records, supplier traceability and evidence packs are design-partner scope. The website does not simulate them.
Read before you run the tool
Each guide starts from the symptom, gives a procedure, states the limits, and links the sources and the matching tool.
Firmware SBOMs for embedded devices
What a useful firmware SBOM contains, how to generate one from Buildroot or Yocto, and which parts of an embedded build it will still miss.
How to validate CycloneDX and SPDX SBOMs
A practical validation order for CycloneDX JSON and SPDX 2.3: schema first, then component identity, dependency references and query readiness.
Common SBOM validation errors and how to fix them
The schema and quality defects that appear most often in CycloneDX and SPDX files, what causes them, and the fix for each.
How to compare firmware SBOM versions
A repeatable method for diffing a baseline and a new firmware SBOM, reading added, removed and updated components, and knowing what the diff does not prove.
Start with a free check. Talk to us when the workflow matters.
No account is required for the tools. If you are preparing for the CRA, managing supplier inventories or trying to keep release evidence together, write to us with the product and the problem — we will tell you whether Early Access is a fit.
- One public address, answered by a person.
- No purchase order or marketing sequence to talk.
- Clear answer if the workflow is not ready for your case.
Choose the useful next step
Or read why we build it this way and how the tools handle data.
Honesty rules this site runs on
Capabilities carry a status. Results state what they do not prove. Nothing is uploaded, nothing is scored for drama, and no compliance is claimed on your behalf.