CRA SBOM requirements call for a machine-readable software bill of materials covering at least the product’s top-level dependencies. Annex I Part II connects that inventory to a broader vulnerability-handling process; generating a file alone does not establish conformity.
What a useful inventory describes
An SBOM should be tied to the product version actually delivered. Record the build identifier, component identities, versions and relationships using the chosen machine-readable format. Where identifiers are uncertain, preserve the evidence and the limitation instead of silently selecting a convenient package name. A vulnerability matcher can miss issues when the component identity is wrong even if the file passes a schema validator.
The legal minimum and the operational objective are different questions. Top-level dependencies meet the stated minimum coverage requirement, but deeper dependencies may matter to the real attack surface. Decide how to include bundled libraries, vendor blobs, copied source, containers and the operating-system packages that ship in the release. Document omissions and agree how the team will handle them.
CycloneDX and SPDX
| Format | Typical use | Review before accepting |
|---|---|---|
| CycloneDX | Components, relationships and security workflow integration | Schema version, component identities and dependency graph |
| SPDX | Software package and supply-chain information | Schema version, package references and relationships |
| A plain spreadsheet | Human review aid | Not a substitute for the required machine-readable SBOM |
The regulation does not make a scanner’s preferred export the only acceptable format. Select a version and profile that your build tooling and vulnerability workflow support. Run structural validation, then compare content against the produced image or package. A structurally valid inventory can still describe the wrong release. Retain the generation command and tool version so it can be reproduced.
Generate from the customer’s own build
For embedded Linux, begin with the Yocto or Buildroot build artifacts and package metadata, then inspect the resulting filesystem where necessary. For Zephyr or ESP-IDF products, review modules, vendored sources and configuration-dependent inclusion. For Android and installable applications, combine the platform and application inventories according to the product boundary. The correct approach depends on what the manufacturer ships, not on a generic technology checklist.
A container image used only in development may not describe a delivered device. Conversely, necessary remote processing can be part of the CRA product boundary even when it does not ship in the box. Agree the boundary before counting components. Record whether the inventory includes the device, companion app and necessary remote elements or only one of them.
Validate before monitoring
Choose a sample of components and trace each to evidence in the build output. Check version strings, backported patches, architecture-specific packages and generated artifacts. If a vendor reports an upstream version but carries downstream fixes, capture the patch evidence so a later finding can be triaged. Avoid suppressing all findings for a vendor package merely because one finding was not applicable.
Use the validated inventory to match public vulnerability sources and exploited lists such as CISA KEV and ENISA EUVD. Match results are candidates for review, not product-impact conclusions. Engineers should check the affected function, reachability and mitigating controls with the customer, then record the rationale in VEX or an equivalent structured decision record.
Keep every supported release visible
Do not overwrite the only inventory each time a new firmware release ships. Customers may still run an older supported version, which can contain a component removed from the newest release. Keep the product-release mapping, support status and inventory history available to monitoring. Establish how a support end changes monitoring, customer communication and the security-update commitment.
An SBOM is also not automatically a public document. The CRA technical-documentation and authority-access context needs to be distinguished from voluntary customer sharing. Agree disclosure, confidentiality and access controls, especially where package names or build paths reveal sensitive information. Share only what the recipient is authorised to receive while retaining the evidence needed to support the manufacturer’s obligations.
Build evidence that survives a release
Begin with a named product and a reproducible release reference. A marketing model number is not enough when several firmware branches, mobile applications and remote services jointly implement its functions. Record the hardware revision, firmware version, build identifier and necessary remote processing. Decide which older versions remain supported. The CRA work should refer to this boundary consistently, so a reviewer can understand which product a statement describes.
Assign responsibilities before collecting documents. Engineering should own technical facts and remediation. A product owner should agree the intended use, support commitment and customer information. An incident contact should receive vulnerability disclosures and have the authority to escalate them. The manufacturer remains accountable for conformity and reporting even when an external team prepares evidence or drafts. Outsourcing a task does not transfer the underlying obligation.
Retain both the conclusion and the evidence that supports it. An applicability decision without a release reference becomes difficult to defend after a dependency upgrade. A technical file without its underlying test results becomes difficult to update. A useful record links the requirement, the artifact, the reviewer, the decision and its date. Keep open questions visible instead of marking an item complete because a template exists.
Common mistakes to avoid
Do not use a scan score as a compliance decision. Vulnerability matches can be incomplete or inaccurate, and a component version alone does not establish exploitability in the product. Equally, a finding that appears irrelevant needs a documented technical rationale. The evidence should explain whether the affected code is present, reachable and exposed through the supported configuration, and who reviewed that conclusion.
Do not confuse a project completion date with a continuing duty. New releases, new public vulnerabilities and changes to the intended use can change the evidence. Plan how the inventory, risk assessment and customer information will be updated. Check that the incident contact still works and that an on-call substitute can make decisions when the primary owner is unavailable.
Do not assume that company size or a non-EU address removes the obligations. The relevant questions include the product, the economic-operator role and how it reaches the EU market. A distributor, importer, authorised representative and manufacturer can have different responsibilities. Borderline interpretations need qualified review. This guide explains the engineering workflow and does not provide legal advice.
A practical review meeting
Bring the product owner, release engineer and security contact together with the current evidence. Walk through a single supported version rather than discussing a hypothetical future product. Ask which assumptions can be checked immediately, which require a build or test, and which require an external conformity or legal specialist. Finish with a short list of actions, owners and dates. A small, reviewed evidence set is more useful than a large unmaintained folder.
Use the CRA guide to connect this topic to the complete lifecycle. Review the product classes before choosing a conformity route, and connect the release SBOM to the Article 14 reporting workflow. If you need a starting inventory, the free Snapshot is a bounded first step.
Make the next action measurable
Choose one supported release and identify the specific evidence missing for this topic. Write an action that a reviewer can close: an inventory validated against the image, a timestamped reporting drill, a classification rationale or an approved customer statement. “Improve compliance” is too broad to verify. Name the artifact, the responsible person and the date for review.
At the next meeting, check the artifact rather than the percentage complete in a tracker. Record any remaining uncertainty and whether the product boundary or release has changed. This keeps progress grounded in technical facts and prevents a documentation task from becoming disconnected from the product it describes.
Frequently asked questions
Is this a substitute for a product-specific assessment?
No. Use the guide to organise the engineering work. The product boundary, applicable legal interpretation and conformity route need a documented review.
Does a small team still need a process?
Yes. Assign a product owner, incident contact and substitute. The micro and small enterprise fine exception for 24-hour early warnings does not remove the duties.
Can Roja help with the practical work?
Yes. Our engineers validate inventory, triage findings, prepare reporting drafts and help build the technical evidence. The manufacturer reviews and remains accountable.
Where should we check the requirements?
Start with Regulation (EU) 2024/2847 on EUR-Lex and ENISA guidance for the Single Reporting Platform. Check the current text and your product facts before making a decision.
Sources
General engineering information, reviewed on the date above. Product-specific interpretations and current standards should be checked before a conformity decision. Roja helps manufacturers prepare for the Cyber Resilience Act. We do not certify products or provide legal advice.