The Cyber Resilience Act (CRA) reporting regime can apply to products that were already on the EU market before the CRA's main obligations begin to apply in December 2027. The key reason is timing: the vulnerability and incident reporting obligations in Article 14 started earlier, on 11 September 2026.
For manufacturers, the practical question is therefore not only when a product was first placed on the market. It is whether the product is still within the scope of the CRA transitional rules and whether a reportable event concerns that product after the reporting provisions have started to apply.
This matters for established product portfolios, long-lived embedded products, software still used by customers, and versions that remain operational even when newer releases already exist.
Why September 2026 matters
Article 71 sets different application dates for different parts of the CRA.
Most manufacturer obligations apply from 11 December 2027. However, Article 14 reporting obligations apply from 11 September 2026.
That earlier date creates an operational requirement before full CRA application: manufacturers may need to report actively exploited vulnerabilities and severe incidents affecting products with digital elements even while the rest of their CRA implementation programme is still in progress.
Legacy product does not mean automatically out of scope
The CRA does not create a simple rule that every product placed on the market before 11 December 2027 is outside the reporting regime.
Article 69 contains transitional provisions for products placed on the market before the main application date. Those provisions must be read together with the earlier reporting date in Article 71.
For product teams, the safe operational approach is to determine the status of each product and version explicitly rather than assuming that an older release is exempt because of its original market date.
Start with a product and version inventory
A manufacturer cannot make a reliable reporting decision if it does not know which versions are still in circulation.
A useful inventory should identify:
- product name and model;
- hardware variants;
- software and firmware versions;
- release dates;
- first placement-on-market date;
- support status;
- whether customers can still obtain the version;
- whether deployed products can be identified remotely;
- known distribution channels;
- approximate installed-base information where available;
- supported update paths; and
- the responsible internal product owner.
The objective is not to create a perfect historical database before any reporting workflow can function. It is to create enough product context to determine whether a vulnerability or incident affects products for which the manufacturer has a reporting duty.
Separate market date from event date
Two dates should not be confused.
The first is when the product or version was placed on the market. The second is when the manufacturer becomes aware of a reportable event.
For reporting purposes, the second date is operationally critical because Article 14 uses awareness as the starting point for reporting deadlines.
A legacy product may have been shipped years earlier, but a vulnerability can become actively exploited only now. Likewise, a severe incident can occur long after the original release.
Teams should therefore preserve both lifecycle and event timestamps.
Know the two main Article 14 triggers
The CRA reporting framework distinguishes between at least two important event types:
- an actively exploited vulnerability contained in a product with digital elements; and
- a severe incident having an impact on the security of a product with digital elements.
Manufacturers should not merge those categories into one generic security-event label. The supporting facts, internal triage, and report content may differ.
A mature workflow records why an event was classified in one category or the other, which products and versions are affected, and what evidence supported that decision at the time.
Legacy portfolios create identification problems
Older products often have weaker lifecycle data than new products.
Common problems include:
- incomplete records of deployed versions;
- devices that do not report their exact software state;
- customers running unsupported versions;
- discontinued distribution channels;
- missing ownership information for old product lines;
- components no longer used in current development;
- unclear maintenance responsibility;
- archived repositories or build systems; and
- fragmented vulnerability records.
These are operational difficulties, not automatic exemptions from reporting duties.
The manufacturer should understand enough about the affected legacy product to make and support a reporting decision.
Map vulnerabilities to exact affected versions
A vulnerability record should not stop at the component name.
Where possible, the manufacturer should establish:
- affected product;
- affected variant;
- affected software or firmware range;
- vulnerable component version;
- fixed version, if available;
- whether exploitation is known for the affected configuration;
- whether mitigating configuration exists;
- customer exposure assumptions; and
- evidence used to support the assessment.
For legacy products, this mapping may require combining SBOM records, release notes, source history, vulnerability databases, ticket history, and archived build metadata.
Preserve the awareness timestamp
Article 14 reporting deadlines are driven by when the manufacturer becomes aware of the relevant event.
That makes the awareness timestamp an important piece of security evidence.
Teams should record:
- when the initial information arrived;
- the source of that information;
- when it was first reviewed;
- when the event was classified as potentially reportable;
- who participated in the decision;
- which evidence was available at that moment; and
- any later corrections or reassessments.
The record should preserve history rather than silently replacing earlier decisions.
Do not wait for complete certainty before organising the workflow
A reporting process that requires perfect information before it can begin is fragile.
When a potential reportable event affects an old product, some facts may initially be uncertain:
- exact affected version range;
- installed base;
- exploit mechanism;
- affected countries;
- remediation availability; or
- customer impact.
The internal process should therefore distinguish between facts that are known, facts still under investigation, and assumptions that must be validated.
That structure helps teams work within reporting deadlines without presenting preliminary information as final.
Identify owners before an event occurs
Legacy products are often difficult to handle because the original engineering team has moved on.
Before an incident happens, assign at least:
- a product owner;
- a security or PSIRT owner;
- a reporting decision owner;
- a technical contact;
- a customer-communication contact; and
- a legal or compliance escalation path where appropriate.
The purpose is to avoid losing the reporting window while the organisation searches for someone who understands a ten-year-old product.
Include unsupported products in the decision process
Unsupported does not necessarily mean irrelevant.
A manufacturer may still receive vulnerability information about an old release, and customers may still be using it.
The reporting workflow should therefore have a rule for how unsupported products are assessed. That assessment should consider the legal transitional framework, whether the product is still in scope, what support commitments exist, and what facts are needed for an Article 14 decision.
Do not use end-of-support status as a substitute for an actual scope assessment.
Connect vulnerability intake to reporting triage
Legacy products often surface through vulnerability channels rather than through active product monitoring.
A useful intake process connects:
- external or internal vulnerability information;
- component and product identification;
- affected-version analysis;
- exploitation evidence;
- incident evidence;
- Article 14 classification;
- reporting deadlines;
- remediation and communication work; and
- retained evidence.
This prevents reporting from becoming a separate manual process performed only after the technical investigation is complete.
Keep product history available to the reporting team
The reporting team may need to reconstruct facts that are easy to find for current products but difficult for older ones.
Useful retained records include:
- release metadata;
- SBOMs;
- component inventories;
- security advisories;
- vulnerability decisions;
- support dates;
- update history;
- customer-facing release notes;
- risk assessments;
- incident records; and
- archived technical documentation.
The objective is to shorten the distance between "we have a security report" and "we know which product, version, risk, and customer population this concerns."
Review distribution and user-notification paths
Reporting to authorities is only one part of a practical response.
Manufacturers should also know how they would reach users of an affected legacy product.
Depending on the product, available channels might include:
- account contacts;
- security advisories;
- product portals;
- mailing lists;
- distributor networks;
- in-product update mechanisms;
- service partners; or
- public support pages.
The correct communication path depends on the product and incident. The important point is to identify realistic channels before an urgent event occurs.
Test the legacy-product workflow
A tabletop exercise can expose gaps before a real reportable event.
Choose an older product and simulate a scenario such as:
- an actively exploited third-party component vulnerability;
- a compromised update mechanism;
- credential exposure;
- remote-code execution in a network service; or
- a severe incident affecting product availability.
Then test whether the organisation can determine the affected versions, establish the awareness timestamp, classify the event, gather the required facts, identify owners, and prepare the reporting workflow.
The exercise should record missing evidence and unclear ownership as remediation items.
Where AA-sec fits
Legacy-product reporting becomes difficult when vulnerability decisions, release context, evidence and reporting facts live in different systems. AA-sec is designed around traceability between products, releases, vulnerability work, evidence and lifecycle context, while the roadmap includes post-market monitoring and CRA reporting workflows. AA-sec does not make the manufacturer's legal reporting decision or automatically submit regulatory reports.
Practical preparation checklist
For products already on the market, confirm that your organisation can answer:
- Which legacy products and versions are still deployed?
- Which versions are still supported?
- Which products can be mapped to current SBOM or component records?
- Who owns security decisions for each old product line?
- Can a vulnerability be mapped to exact affected versions?
- Can the awareness timestamp be reconstructed and preserved?
- Can actively exploited vulnerabilities and severe incidents be classified separately?
- Are Article 14 deadlines integrated into the process?
- Can reporting evidence be retrieved without relying on one person?
- Are customer and distributor communication channels known?
- Are unsupported products explicitly assessed rather than ignored?
- Has the legacy-product reporting workflow been tested?
Key takeaway
The September 2026 CRA reporting duty is not only a concern for newly released products. Manufacturers with products already on the market need enough lifecycle visibility to determine whether a legacy product is affected by a reportable vulnerability or incident, preserve the awareness timestamp, identify the affected versions, and support the reporting decision with evidence.
Official sources
- Regulation (EU) 2024/2847 - Cyber Resilience Act — EUR-Lex
- Cyber Resilience Act reporting obligations — European Commission
- CRA Single Reporting Platform — ENISA