Article 14 reports are not just for products launched under the later CRA rules. They cover products in scope that reach the market before 11 December 2027. The report rules start on 11 September 2026. A list of only current code projects can miss old products from that date.
Build a basic proof pack for each old product line. Do not claim that every old build can be rebuilt if the proof is gone.
Find products outside the current roadmap
Search sales lists, access systems, app stores, package lists, and old device files. Check firm purchase records, seller lists, support sites, and past security notes. Include products with new names. Include versions owned by a team that no longer exists.
For each item, record its market name and legal maker. Save the date and proof that it was offered in the EU. List the versions, last support state, sales routes, and current way to reach users. Mark any fact based on an estimate.
“Not sold now” does not mean “out of scope.” Have legal staff check the product’s real market history and record the result.
Build a minimum technical fingerprint
Collect release hashes and package, device, or software IDs. Keep part lists, design notes, update paths, signing IDs, and build source. Add the flaw history and known ways the product was used. Preserve the old file forms. Note systems that cannot be opened.
If the full parts list is gone, record the best proof left and its limits. Name a technical owner who can match a new attack sign or flaw report to this product print.
Do not rebuild old facts from memory. A clear gap with a recovery task is safer than a smooth list with no source.
Restore decision and communication paths
Name an Article 14 choice owner and backup even if the product team is gone. Map the maker’s CSIRT route. Name the filing person, legal approver, and person who may contact users.
Test if user routes still work. Check admin contacts, security pages, update screens, sellers, and old download pages. Record user groups that cannot be reached at once. Raise the gap for review.
Triage with legacy uncertainty visible
When an alert comes in, first link it to a product and version. A matching part name is not proof that the weak code is present or can run. Record each old claim that cannot be tested and why.
Use the same Article 14 trigger and awareness rules as for a new product. Do not delay a report with sound proof just because a full rebuild is not possible. State the limits in each report stage. Keep checking the key gaps.
Retire records deliberately
Name who may remove a product from the live old-product list. State the proof needed. Keep the choice, date, and fact that would reopen it. A firm purchase, new sale, or newly found unit may change the result.
The final view should help a team name the old product, maker, and users. It should let them test an alert against saved proof and choose the right report path. It need not pretend that every past fact can be restored.
Continue this workflow with the application-date workstreams and the manufacturer register.