Article 14 reporting is not limited to products launched under the CRA’s later conformity regime. It applies to in-scope products placed on the market before 11 December 2027. A reporting programme that inventories only current engineering projects can therefore miss older products after the reporting rules begin on 11 September 2026.
The practical response is a minimum evidence pack for every relevant legacy line, not an unsupported promise that every old build can be reconstructed.
Find products outside the current roadmap
Search sales catalogues, entitlement systems, app and package listings, firmware archives, acquisition records, distributor catalogues, support portals, and security-advisory histories. Include renamed products and versions maintained by a team that no longer exists.
For each candidate, identify the market name, manufacturer entity, date and evidence of Union-market availability, versions, last known support state, distribution channels, and current user-contact route. Mark records that rely on estimates.
Do not equate “not sold now” with “irrelevant.” Route scope questions through a documented legal assessment using the product’s actual market history.
Build a minimum technical fingerprint
Collect release hashes, package or firmware identifiers, component manifests where they exist, architecture notes, update mechanism, signing identity, build provenance, vulnerability history, and known deployment patterns. Preserve original formats and note inaccessible systems.
When a complete dependency inventory is unavailable, document the strongest remaining evidence and its limits. Identify a technical owner who can compare an incoming indicator or vulnerability report with the product fingerprint.
Avoid recreating old facts from memory. An honest gap with a recovery task is safer than a polished but untraceable inventory.
Restore decision and communication paths
Assign an Article 14 decision owner and deputy even when no active product team remains. Map the coordinating-CSIRT route for the manufacturer, submission representative, legal approver, and person authorised to communicate with users.
Test whether user channels still work. Verify administrator contacts, security-advisory pages, update interfaces, distributors, and archived download pages. Record populations that cannot be contacted directly and escalate the coverage problem.
Triage with legacy uncertainty visible
When a signal arrives, first prove the relationship to a product and version. Separate a component name match from evidence that the affected code exists or is reachable. For exploitation or incident evidence, record which historical assumptions could not be tested and why.
Apply the same Article 14 trigger and awareness discipline used for current products. Do not delay a supported report merely because a full rebuild or root-cause analysis is impossible. Carry the limitations into the staged report and continue targeted investigation.
Retire records deliberately
Define who can approve removal from the active legacy inventory and which evidence supports it. Preserve the decision, effective date, and reopen condition. Acquisitions, renewed distribution, and newly discovered units can change the answer.
The useful output is a portfolio view that lets responders identify an older product, find its manufacturer and users, test a signal against preserved evidence, and reach the correct reporting path without pretending the past is fully reconstructable.
Continue this workflow with the application-date workstreams and the manufacturer register.