Why do legacy products create CRA risk before the main deadline?

Why legacy products stay in CRA scope before the deadline

Legacy products do not get a free pass just because they were placed on the market earlier. The reporting duty still attaches to products with digital elements that remain in circulation, so the practical issue is not only whether the product is grandfathered, but whether the manufacturer can still meet vulnerability detection and reporting expectations while the deadline window is still open.

The risk is amplified by the gap between product age and operational visibility. Older shipped units are often the hardest to inventory, monitor, and correlate with exploitation signals, which is exactly where late discovery turns into compliance exposure.

What makes exploited-vulnerability reporting difficult on older shipments

Legacy fleets usually carry the weakest telemetry, the least consistent ownership records, and the most variation in how they were configured, supported, or resold. That makes it harder to tell whether a vulnerability is merely present or already being actively exploited in the field, and harder to decide quickly which units are affected.

For many manufacturers, the problem is less about identifying a single flaw than about reconstructing exposure across many product generations, customer environments, and support arrangements. If reporting depends on manual triage, the organization may miss the reporting window even when the technical issue is understood early.

That is why the CRA's reporting and vulnerability-handling expectations should be read as an operational control problem, not just a legal one. The EU Cyber Resilience Act Guide is useful here because it ties together support period, vulnerability reporting, conformity, and product lifecycle obligations.

Why this becomes a penalty issue before 2027

The main deadline does not eliminate earlier exposure, because reporting failures can arise long before full enforcement of the broader regime. If a manufacturer cannot detect an exploited vulnerability quickly enough, it can still face consequences tied to shipped units that remain in scope, even where the product itself was placed on the market under older assumptions.

This is especially important for product teams that treat legacy support as a background service rather than a standing compliance obligation. Once exploitation is suspected, the clock starts on evidence collection, scoping, and notification discipline, not on the next product release cycle.

The Commission's EU Cyber Resilience Act page is the authoritative reference for the obligation timeline and the enforcement posture that turns reporting into a concrete risk for manufacturers.

Risk and Threat Considerations

Legacy products create a dual exposure: operational blind spots and regulatory delay. The older the fleet, the more likely it is that vulnerability evidence, asset records, and customer deployment data are incomplete, which can make a real-world exploitation event harder to confirm and report on time.

Failure mechanism: Weak asset visibility and fragmented telemetry delay the link between an exploited vulnerability and the affected shipped units, so the manufacturer cannot complete scoping and reporting fast enough.

Impact: The result is avoidable penalty exposure, weaker customer response coordination, and a greater chance that a known exploited weakness remains uncontained across installed products.

Practitioner Guidance

What to prioritise: Build a current inventory of legacy product models, support states, and customer deployment paths before the next reporting event, not after it. The key judgement is whether you can identify affected shipped units quickly enough to support a report based on evidence rather than guesswork.

What to verify: Confirm that your vulnerability intake, triage, and escalation process can distinguish discovery from exploitation and can preserve the evidence needed to justify reporting decisions. If the process depends on ad hoc analyst judgment, it is usually too slow for legacy fleets.

Practitioner takeaway: For CRA, the real test is not whether a product is old enough to feel exempt, but whether your organisation can still prove which shipped units are exposed and report exploited vulnerabilities before the deadline pressure becomes a penalty problem.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?
• Why do collaboration tools create such a large secrets risk?