Cybersecurity records are becoming liability evidence

Cybersecurity regulation and product liability are usually handled by different people. One is treated as a technical compliance problem owned by engineering and security. The other sits with Legal, and mostly stays there until something has already gone wrong.

That separation becomes difficult to sustain on 11 September 2026.

From that date, the Cyber Resilience Act requires manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents affecting the security of those products through the CRA reporting architecture. The main body of CRA obligations, including conformity assessment, CE marking and the full essential cybersecurity requirements, does not apply until 11 December 2027. Reporting arrives 15 months earlier, and it arrives with clocks attached.

The CRA is not a product liability instrument. It does not determine whether a claim succeeds under the revised Product Liability Directive, and the two regimes should not be collapsed into one. But the CRA will change what organisations record about cybersecurity, when they record it, and how precisely. Years from now, in a matter that may have nothing to do with cybersecurity compliance, those records could be the most exact surviving account of what the manufacturer knew and when it knew it.

That is worth understanding before September rather than after it.

Awareness stops being a soft fact

Under Article 14, the reporting sequence for an actively exploited vulnerability runs to three deadlines. An early warning is due within 24 hours of becoming aware. A fuller notification follows within 72 hours, carrying the nature of the vulnerability and of the exploit, the corrective or mitigating measures taken or available, and the measures users can take. A final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, the first two steps follow the same timetable and the final report is due within one month from the 72-hour submission.

The detail that matters is not the number of hours. It is where the clock starts.

Every one of those windows runs from awareness. The practical consequence is that the organisation begins fixing its own knowledge position in a regulatory record while the event is still developing.

Most manufacturers have never had to fix that moment with this level of regulatory precision. Vulnerability handling has historically produced a scattered trail: a scanner alert, a researcher email, a support ticket that looked routine for eleven days, a supplier advisory that reached one business unit and not another, a security review that discussed the issue before anyone formally logged it.

Reconstructing "when did we know?" from that material is an exercise in interpretation. Interpretation is precisely what an organisation does not want to be doing for the first time while a 24-hour clock is already running.

The CRA does not leave documentation entirely to good practice either. Article 13(7) requires manufacturers to systematically document, proportionately to the product and its cybersecurity risks, relevant cybersecurity aspects including vulnerabilities of which they become aware and relevant information provided by third parties, and to update the cybersecurity risk assessment where applicable.

After September, for reportable events, "when did we know?" begins becoming a filed position rather than being left wholly to later reconstruction. It sits in a dated regulatory record against a defined product, making later reinterpretation considerably harder.

The reporting duty reaches further back than most teams expect

Article 69 generally grandfathers products placed on the EU market before 11 December 2027 unless they undergo a substantial modification from that date. The reporting regime is different.

Article 14 reporting obligations apply to products with digital elements already made available on the Union market before 11 December 2027. The Commission's own CRA summary states this expressly.

Read that against a real installed base rather than a product roadmap.

A controller shipped in 2019 and long since superseded can still fall within the reporting duty from September if it remains within CRA scope. So can the discontinued variant that major customers still operate because replacing it means replacing the wider system around it. So can a product line acquired with another business whose vulnerability intelligence still arrives through processes designed by an organisation that no longer exists in the same form.

Anyone who has worked with long-lived technical products will recognise the problem. The commercial lifecycle, the engineering lifecycle and the field lifecycle rarely end on the same date. A product may disappear from the roadmap while substantial populations remain installed and expected by customers to continue doing the job they were bought to do.

For many manufacturers, the September reporting obligation will therefore attach to a population larger than the one currently under active engineering ownership.

That gap, between the portfolio an organisation manages and the portfolio it must still be able to recognise and report on, is where some of the earliest CRA weaknesses are likely to appear.

Support periods record the organisation's own assumptions

Under Article 13(8), the support period must reflect how long the product is reasonably expected to be in use, with a general floor of five years unless expected use is shorter. Article 13(19) requires the end date, at least month and year, to be made clear at the time of purchase. The technical documentation must also contain the information taken into account when determining that support period.

That last requirement carries evidential weight.

The organisation is not merely committing to a support date. It is documenting how long it expected its own product to remain in use and the reasoning behind that judgement.

There is a second feature that matters more than it first appears. "Placing on the market" refers to the first making available of a product on the Union market. Applied operationally across a product family sold over several years, this means lifecycle obligations cannot always be understood through one convenient product-family date.

An organisation that treats the support period as a single line on a datasheet risks describing its commercial product rather than the reality of its installed population.

The latter is what matters when the organisation later has to establish which units remained inside the support commitment and for how long.

Residual populations are a reconstruction problem

When a security update is released, the organisational instinct is to treat release as closure.

Patch developed, patch approved, patch published, issue closed.

Release establishes availability. It does not establish what happened next.

Some units update automatically. Some customers defer to a change-control window that runs to the next shutdown. Some units are air-gapped. Some run on environments the update does not support. Some were modified in the field by integrators whose records the manufacturer may never have received.

The question here is deliberately not whether that fragmentation is acceptable. That belongs to a different discussion.

The question is whether the organisation could accurately reconstruct it eighteen months later.

The information required to do so may sit across a vulnerability database, engineering ticketing, release documentation, CRM communications, field-service history and a decision taken in a meeting whose participants have since moved on.

None of those systems was necessarily designed to be read together.

A future reviewer should not have to assemble the product story from six disconnected systems and an assumption about deployment that nobody ever tested.

The evidence should already tell the story, because by the time it is needed, the people who made the decision may no longer be there to explain it.

Why these records will not stay inside cybersecurity

Evidence rarely remains confined to the regime that first required it.

A CRA record may describe vulnerability awareness, affected product versions, support commitments, corrective measures, user communication and the reasoning around a technical decision.

Those facts may also become relevant to product-safety assessment, contractual disputes, insurance, corrective action, regulatory enforcement under other instruments and, potentially, product liability.

The organisation will produce the record for one purpose.

It may later be read for another.

The CRA also determines how long important parts of that record must survive. Article 13(13) requires the technical documentation and EU declaration of conformity to remain available to market-surveillance authorities for at least ten years after the product is placed on the market, or for the support period where that is longer.

These are not records intended to disappear quietly when a product line leaves the catalogue.

This cuts in both directions. A coherent CRA record can provide strong evidence that the organisation knew promptly, assessed the issue, acted proportionately and communicated appropriately. A weak record exposes the distance between what the organisation says it did and what it can demonstrate.

Either way, September begins creating evidence that may outlive the immediate cybersecurity event.

An evidence reconstruction test

Do not run this as a survey question.

Take one product still in the field, preferably one that has not been a management priority for some time, and establish whether the following can be produced from records rather than from someone's memory.

One. The date and source of first awareness of the last material vulnerability affecting it, evidenced rather than estimated.

Two. The support period applying to the units actually in service rather than simply the date shown against the current product family.

Three. The reasoning recorded when that support period was selected, in a form another person could follow.

Four. The population that received the last significant security update, the population that did not, and the basis on which those figures are stated.

Five. The decision taken about the population that did not update, who took it, and what information that decision rested on.

Six. The elapsed time between first awareness and each required regulatory step.

Where the answer comes from a person rather than a record, the organisation is carrying that knowledge on trust.

Trust is a perfectly reasonable way to run many parts of a business.

It is a poor long-term evidence architecture.

The organisations best prepared for September will not simply be those that can submit a report within 24 hours. They will be those that can still explain, years later, the decision that sat behind it.

Editorial note: The European Commission published non-binding practical guidance on the application of the Cyber Resilience Act on 27 July 2026, C(2026) 5252. Authoritative interpretation of Regulation (EU) 2024/2847 ultimately rests with the Court of Justice of the European Union.

Your cybersecurity records are becoming liability evidence