What breaks when CRA obligations reach legacy products with no current SBOM?

Why legacy CRA compliance fails without a current SBOM

The break is not only in engineering, it is in proof. A current SBOM is the artifact that lets a manufacturer answer what is in the product, which components are exposed, and whether a newly relevant issue should trigger a correction, notice, or report. Without that baseline, CRA obligations turn into guesswork, especially for older shipped products with long support tails.

That matters because the CRA is not just asking whether a product can be made safer going forward. It also creates duties to track vulnerability handling and to justify decisions with credible product knowledge. EU Cyber Resilience Act Guide is the clearest internal reference for how those duties connect to product documentation and vulnerability reporting, while the Commission’s EU Cyber Resilience Act page is the canonical external source for the regulatory baseline.

Older products amplify the problem because the evidence may be fragmented across build systems, acquisitions, contractor work, archived repositories, and unsupported third-party components. If the manufacturer cannot reconstruct the component set, it cannot reliably determine whether a vulnerability exists in that exact shipped build, whether it is exploitable in practice, or whether the issue is confined to a library, transitive dependency, or optional feature path. A missing SBOM therefore breaks traceability before it breaks remediation.

What you can and cannot safely conclude from an incomplete product record

An incomplete record does not prove absence of risk, and it does not support confident closure. It usually means the organisation can only make a provisional judgment, such as “we have not yet established exposure,” rather than a defensible statement that the product is unaffected. In CRA terms, that distinction matters because regulators, customers, and internal approvers will expect evidence-based decisions, not optimism.

The same gap affects customer guidance. If support teams cannot map a vulnerability to a specific shipped configuration, they may issue inconsistent advice, over-warn one customer, under-warn another, or miss an obligation to tell downstream users what is actually affected. The result is an evidentiary failure that quickly becomes an operational one.

For teams modernising their documentation, the SBOM Guide is useful because it frames SBOM quality, generation, vulnerability correlation, and sharing as part of the same decision chain. The related Open Source Security Guide adds the dependency-management side of the problem, including how SBOMs support CRA duties when product history is incomplete.

How legacy support and vulnerability handling should change when the SBOM is missing

When the SBOM is missing, the right response is to treat the product as a reconstruction exercise, not a normal patch ticket. Support teams need to rebuild enough product evidence to establish component identity, version lineage, and likely exposure paths before they can decide whether the issue is reportable, whether a mitigation is sufficient, or whether a full correction is required.

That is also where authoritative external references matter. The CISA Known Exploited Vulnerabilities Catalog helps determine whether a known issue is actively exploited and therefore time-sensitive, while the CRA itself sets the reporting and conformity context. For the open-source component of the problem, OpenSSF is a useful authority for supply-chain hygiene and package visibility.

Where legacy products depend on open source or transitive dependencies, the absence of current evidence should push teams toward tighter version pinning, dependency validation, and stronger release provenance for any rebuild effort. The objective is not to create a perfect archive overnight. It is to produce enough trustworthy evidence to support the next compliance decision without pretending the history is complete.

Risk and Threat Considerations

Legacy products without a current SBOM are exposed to both compliance failure and hidden security exposure. The immediate risk is that an organisation cannot prove what is affected, which can lead to late disclosure, inconsistent remediation, and regulator-facing statements that are too weak to defend. The deeper threat is that an attacker can exploit the same uncertainty to keep an older vulnerable component alive longer than anyone realises.

Failure mechanism: Product composition is unknown or only partially reconstructible, so vulnerability triage, exploitability assessment, and reporting decisions rest on assumptions instead of evidence.

Impact: The manufacturer can miss deadlines, misclassify exposure, give conflicting guidance to customers, and fail to justify why a vulnerability was or was not treated as reportable under CRA expectations.

Practitioner Guidance

What to verify: First confirm whether you can reconstruct the shipped build from release artifacts, dependency manifests, archived pipelines, signed releases, and any downstream packaging records. If you cannot, treat the product as evidence-poor and avoid making definitive claims about unaffected status.

Decision rule: If the product may still be in circulation or under support, prioritise component reconstruction and exposure analysis before customer messaging. If the product is truly end-of-life and unsupported, document that boundary clearly, because the compliance posture and the remediation path are not the same as for an actively maintained product.

Common mistake: Teams often try to answer CRA questions with generic “we patched the current version” language, even when the shipped legacy build is different. That shortcut creates false confidence and weakens both internal governance and external justification.

Practitioner takeaway: With legacy products, the SBOM is not just a supply-chain document, it is the evidence base for every CRA decision that follows from vulnerability discovery.

Related resources from NHI Mgmt Group

• Guide: AI Supply Chain Security and AI-BOM Guide
• What breaks when JML does not reach legacy application access?
• What breaks when identity governance cannot reach legacy and core systems?
• What breaks when software teams do not have an SBOM for their products and pipelines?
• What breaks when organisations cannot produce an up-to-date SBOM and fix exploitable vulnerabilities quickly enough for CRA reporting?