The CRA's three ten-year retention duties

This is the least discussed obligation in the regulation and the one most likely to be quietly breached. Nothing fails on the day. A manufacturer with a folder of PDFs on a laptop is compliant in year one, non-compliant by year three, and will not notice either.

The three duties

Three rows, three different start dates. That is the whole difficulty.

Duty one: every security update, from its own issue date

This is the one that surprises people. Each security update must remain available for at least ten years from the issue of that update, or for the remainder of the support period if that is longer.

So every update starts its own clock. Work through what that means for a product with a ten-year life:

• You place the product on the market in 2027. Its documentation clock runs to 2037.
• You ship a security update in 2036, near the end of support. That update's clock runs to 2046.
• You must keep that update retrievable for nine years after the product's own retention period ended.

“Available” means a user can still get it. A discontinued download server, a decommissioned CDN or a migration that quietly dropped old artefacts all break this, and all are completely normal engineering events over a twenty-year horizon.

Duty two: the technical file and the declaration

The technical documentation and the EU declaration of conformity must be kept at the disposal of market surveillance authorities for at least ten years after the product is placed on the market, or for the support period, whichever is longer.

“At the disposal of” is the operative phrase. It does not mean filed with anyone. It means that if an authority asks, you can produce it — which requires knowing where it is and being able to tell which version applied to which product and when.

That last part is the trap. Your product changes. A substantial modification means the documentation has to be updated, and the older version does not stop mattering, because it was the version that governed the units placed on the market at that time.

Duty three: the information you shipped to users

The information and instructions you supply to users — the Annex II content: the vulnerability-reporting contact, the support-period end date, where the declaration of conformity can be found, and the rest — must also remain available for at least ten years.

When the support period beats the ten years

Two of the three duties say “or the support period, whichever is longer”. So your own support decision can extend your retention obligation past ten years.

The support period itself has a floor: it must reflect how long the product is expected to be in use, and must be at least five years unless the product is expected to be in use for less than five years.

Which produces a quiet trade-off worth making deliberately. A generous fifteen-year support period is good for customers and good for marketing — and it silently extends your document-retention obligation to fifteen years too. That is not a reason to promise less. It is a reason to decide the number on purpose rather than by default, because almost everything else in your technical file depends on it.

Why a folder of files fails

The regulation does not prescribe a system. A folder is not illegal. It just does not survive contact with ten years, for four reasons:

1. Nothing records which version was current when. If you overwrite tech-file.pdf each time the product changes, you have destroyed the version that governed earlier units.
2. Nobody tracks per-update clocks. Three duties, and one of them starts a new clock every release.
3. People leave. Ten years is longer than most employees stay, and longer than most laptops last.
4. Files move. Reorganisations, migrations, acquisitions. Nothing in a folder tells the next person which files are load-bearing legal records.

None of these produce an error message. That is what makes this obligation different from the reporting deadlines: there is no moment at which you find out you have failed, until somebody asks.

What compliance actually looks like

Whatever you use — a system, a repository, a vendor — four properties matter:

• Every document is a version, not a file. Dated at creation, never overwritten. An edit creates a new version and the old one survives.
• Nothing is deleted. Not on edit, not on product end-of-life, and not when you stop paying a vendor. If a supplier deletes your records on cancellation, they have made you non-compliant as an exit fee.
• Each document carries its own retention date on its face. “Placed on the market DD/MM/YYYY · retain until DD/MM/YYYY”. Cheap to add, and it is the single clearest demonstration to an inspector that you understand the duty.
• You can export the lot. If you cannot take your archive somewhere else, your compliance depends on a commercial relationship lasting ten years. Ask for the export button before you need it.

If you are building this yourself, the cost is trivial — object storage plus a row per version. The expensive part is deciding on day one that documents are immutable, because that decision cannot be applied retroactively to records you have already overwritten.