The CRA vulnerability trigger concerns an actively exploited vulnerability contained in the manufacturer’s product. When the flaw originates in a third-party component, the final-product manufacturer still has to decide whether its own product contains the vulnerability and whether the active-exploitation condition is met for that product.
Evidence that the same component is being exploited in an unrelated product does not, by itself, establish the final-product conclusion. It is a high-priority signal that requires a product-specific assessment.
Prove the inclusion path
Identify the component name, supplier, version, build source, and every product release that includes it. Confirm whether the relevant vulnerable code is present rather than relying only on a package name. Preserve build records, dependency evidence, and supplier notices used in the decision.
Then assess reachability and configuration. Record whether the vulnerable function is included, enabled, exposed, or constrained in the shipped product. A blanket “not affected” statement needs the same evidentiary discipline as a reportable conclusion.
Build the inclusion path from immutable release evidence where available. A current dependency scan may not prove what an older shipped image contained. Preserve the build manifest, source revision, packaging step, configuration, and product release that support the conclusion.
If the component was forked or patched locally, treat the manufacturer’s variant separately. Upstream version labels may not describe the code actually shipped.
Test the exploitation evidence
Separate a vulnerability identifier, a severity score, and a catalogue listing from evidence of malicious exploitation. Establish what was exploited, in which system, and how that evidence connects to the manufacturer’s product. Record conflicting reports and the confidence assigned to each source.
Apply the severe-incident test separately. A supply-chain compromise or malicious-code event can require incident analysis even when the team has not established the vulnerability-track trigger.
Manage one signal across several products
Open a shared component evidence record, then give each product family its own containment, reachability, exploitation, severe-incident, awareness, and mitigation decisions. Reuse original evidence by reference; do not copy a conclusion from one product to another.
When supplier evidence changes, identify which product decisions depend on it and reopen only those records. Preserve the earlier decision and the new source. A supplier correction should not silently change filed product scope.
Keep each manufacturer accountable
A supplier’s report does not automatically complete the downstream manufacturer’s Article 14 duty. The final-product team needs its own awareness time, product scope, trigger decision, and staged submission evidence.
Use one component case to link all affected products, but give each product family an explicit conclusion. This prevents a single broad supplier advisory from being treated as proof for products with different versions, configurations, or exposure paths.
The handoff to reporting should contain the legal manufacturer, released product versions, component evidence, exploitation assessment, severe-incident assessment, awareness record, open questions, and measure state. The supplier case remains linked evidence, not the manufacturer’s reportability decision.
Continue this workflow with the product-version map and the maintainer handoff.