This week, three different product-security questions exposed the same weakness: relevant evidence can exist without reaching the person responsible for the decision.
ENISA's CRA reporting platform can be operational while manufacturers still have to establish whether an event is reportable and which released products are in scope. An automotive component inventory can be available while vulnerability applicability remains unresolved. Cybersecurity and software-update records can both be valid without demonstrating that they describe the same vehicle configuration. These are related engineering evidence problems, not identical regulatory obligations.
The pattern this week
Evidence has assurance value when it reaches the product decision.
CRA reportingReporting route availableEvent trigger, product scope and decision authority still need to be established.
→
Automotive softwareComponents inventoriedA scanner finding is not a product disposition until the affected build and functionality are assessed.
→
R155 / R156Records individually validVehicle identity, software state and approval evidence must still refer to the same configuration.
Common gap: a working portal, an SBOM or a certificate can be useful without providing enough context to justify the decision it is expected to support.
01
Product Security · CRA · Reporting
CRA: the reporting route is available, but the decision still needs an owner.
ENISA launched the initial capability of its Single Reporting Platform on 11 September 2026, when CRA Article 14 reporting obligations began applying. The early warning must be submitted without undue delay and within 24 hours of awareness of a relevant event. A high CVSS score alone does not establish that a vulnerability is actively exploited or that an incident is severe. A manufacturer must connect the signal to the released product versions, available supplier facts and accountable authority. Missing information should remain explicit, with a next update owner, rather than becoming a reason to delay an applicable notification.
DecisionRehearse the route from awareness to an owned, product-scoped CRA decision, including incomplete supplier input and absent decision-makers, without treating uncertainty as a pause of the reporting clock.
Automotive software: a finding needs the context of the released product.
Basu and colleagues analysed 413 vulnerabilities and scanned 20 selected automotive-related open-source repositories, reporting 827 vulnerable libraries. Their findings show disagreement between scanning tools, with stated selection limitations; they are not an estimate of vulnerability prevalence in production fleets. The product conclusion depends on component identity, the actual released build, the path to affected functionality and the evidence of treatment and verification. An SBOM supports composition analysis but cannot by itself determine applicability. More scans may reveal coverage gaps, but agreement between scanners is not proof of correctness.
DecisionClose a finding only when its applicability and disposition are technically justified against the released product, with verification evidence and a consistent decision across affected branches.
R155 and R156: valid records must describe the same vehicle state.
UN R155 connects cybersecurity management to vehicle-type risk assessment and lifecycle monitoring. UN R156 includes software identification, update compatibility and impact assessment on type-approved systems. The assurance argument therefore needs a traceable relationship between the relevant management-system evidence, vehicle type, software identity and change history. Not every software update requires a new approval; its actual effects must be assessed through the applicable process. GRVA proposals are not treated here as adopted amendments. The CRA has separate product-scope exclusions, including products subject to Regulation (EU) 2019/2144, so similar evidence practices must not be mistaken for the same legal duties.
DecisionPreserve configuration identity so the cybersecurity, software-update and approval owners can independently reconstruct the evidence supporting the same vehicle state.
Can the responsible team reconstruct a product decision when one evidence source is missing?
Take one released configuration and a realistic vulnerability signal. Trace what is known, what depends on an unavailable supplier, who has authority to act, and which interim control and review are justified. A desk-based exercise using existing records is enough; it should not interrupt production. The output is a bounded decision with visible scope, uncertainty, owner and next review, not a manufactured affected or not-affected conclusion.
