Be ready to show what is in your product, before anyone asks.

Why readiness, not “compliance”

The Cyber Resilience Act places obligations on manufacturers of products with digital elements. Conformity depends on your risk assessment, your technical documentation, your processes and, for some products, a third-party assessment. A vendor cannot hand you that status.

What a vendor can do is make the evidence easy to produce and hard to fake: a scoped product, an inventory that can be matched to advisories, a record of what changed between releases, and a documented review trail.

What you can do today, without an account

• Check whether the CRA likely applies to a specific product, and which role you have — with citations to the article used.
• Validate a CycloneDX or SPDX inventory against the official schema and see quality defects by component.
• Find the components that cannot be matched to advisories because the identifier or the version is missing.
• Compare two firmware SBOMs and read the added, removed and updated components.
• Decode a release certificate locally to confirm subject, issuer and validity window.

The gap most teams find first

A schema-valid SBOM is not automatically a useful one. In vendor inventories we routinely see components with no package URL, versions such as “unknown” or a build hash, and components whose vendor is only a vendor blob.

Those components still count in the manifest, but they cannot be matched reliably. The validator reports this as query readiness — with the reason per component — rather than as a pass/fail score.