You already have products shipping into the EU, firmware releases queued, and a documentation trail spread across Jira tickets, build logs, shared folders, vendor emails, and whatever someone exported before they left the team. That is the starting point for the CRA conformity documentation retention period. Not a clean legal memo. A messy operational reality.
For product engineering teams, the retention rule matters because it turns documentation from a launch-time deliverable into a long-tail obligation. If an authority asks for evidence years after release, “we used to have that file” is not a compliance position. You need to be able to retrieve the shipped risk assessment, declaration, component inventory, update rationale, and vulnerability records tied to the version that went to market.
The hard part is not understanding that records must be kept. The hard part is building a system that still works when product lines change, suppliers switch, repositories move, and legacy SKUs continue receiving updates long after the original launch team has gone.
Your CRA Documentation in 2036 A Future Audit Scenario
It is 2036. An EU market surveillance authority asks for the technical documentation for a smart thermostat your company first placed on the market in 2026.
The request sounds simple. Send the technical file. In practice, the team now has to answer a chain of awkward questions.
Which firmware build was on the device when it first shipped? Where is the cybersecurity risk assessment for that version? Which third-party components were included? Can anyone still produce the SBOM that matched that release? Where are the records showing how vulnerabilities were triaged and how updates were issued during support?
One engineer points to an old shared drive. Another finds a spreadsheet with release notes, but the file naming convention changed twice. Legal has a declaration of conformity PDF, but nobody can prove it maps to the shipped software version. Security has partial records in a ticketing system that was replaced years ago. Procurement has emails about a component substitution, but not the final approval trail.
That is what retention failure looks like. Not one dramatic mistake. A slow loss of traceability.
The CRA changes the standard for what “keeping records” means. It is not enough to retain fragments. You need a retrievable evidence set that connects product version, security decisions, and conformity artefacts over the life of the product.
Practical takeaway: If your current answer to “where is the complete file for version 1.0?” is “it depends who you ask”, your retention model is already too weak.
Shared drives and spreadsheets fail for one reason. They store files, but they do not preserve context. An audit-ready system has to preserve both. It must show what was approved, when it was approved, which product version it applied to, and what changed later.
The Core Rule What Is the CRA Documentation Retention Period
The core rule is straightforward, though the operational consequences are not. Under Article 13(13), manufacturers must retain the technical documentation and the EU declaration of conformity for at least 10 years after the product is placed on the market, or for the entire support period if that is longer, and the support period itself has a minimum duration of 5 years unless the expected use time is shorter, as summarised by Cyberday’s CRA Article 13(13) requirement note.
Consider financial records for product cybersecurity
A useful way to explain this to engineering teams is to treat the technical file like regulated business records.
You do not keep financial documents only until the quarter closes. You keep them for the legally relevant period because someone may ask to inspect them later. CRA documentation works the same way, except the retention clock follows the product lifecycle rather than the accounting cycle.
That distinction matters. Teams hear “10 years” and stop there. The rule is not only “keep it for 10 years”. It is 10 years or longer if your support period runs longer.
What starts the clock
The reference point is when the product is placed on the market. For internal planning, teams should identify that date at SKU level and preserve it alongside the product record. If you cannot establish when a product entered the EU market, you will struggle to defend your retention timeline later.
This is one reason ad hoc document storage breaks down. The file may exist, but if the market-placement date is not linked to the right version and declaration, the retention schedule becomes guesswork.
A simple product example
Take a connected security camera.
Your product team promises support for 7 years. The instinctive conclusion is often “we keep the file for 7 years”. That is wrong. Because the baseline requirement is longer, you retain the file for 10 years, not 7.
Now take an industrial gateway with a support model that runs beyond a decade. In that case, the support period controls. The file stays available for the entire support period, because the legal retention obligation extends with it.
What works in practice
Teams succeed when they do three things early:
- Define support periods explicitly: Put the support end-date in the product record, not only in marketing copy or release notes.
- Tie retention to versions: Keep evidence by released version or release family, not just by product name.
- Lock the declaration to the file: The EU declaration of conformity should not live as a standalone PDF with no traceable link to the supporting evidence set.
Rule to remember: Treat every launch as the start of a long-lived evidence obligation, not the end of a project.
Key Documents You Must Retain for CRA Compliance
When teams imagine “technical documentation”, they imagine a single folder called compliance. That is not enough. The retained file needs to show how the product was designed, assessed, tested, supported, and updated from a cybersecurity perspective.
The practical way to handle this is to break the file into named artefacts with clear owners.
The core artefacts
The table below is a workable operating checklist.
| Document Artefact | Description | Primary Responsible Party |
|---|---|---|
| EU Declaration of Conformity | Formal statement that the product meets the applicable requirements and can be presented to authorities with the rest of the file | Compliance or regulatory affairs |
| Product description | Identifies the product, intended use, model or SKU scope, relevant software or firmware versions, and configuration assumptions | Product management |
| Cybersecurity risk assessment | Documents identified risks, assumptions, mitigations, residual risk reasoning, and review history | Product security |
| SBOM | Inventory of software components and versions used in the released product build | Engineering or DevSecOps |
| Test evidence | Security testing outputs, validation records, and release approval evidence tied to the shipped version | QA, security engineering |
| Update policy and support records | Shows how security updates are issued, tracked, and maintained through support | Engineering operations |
| Vulnerability handling policy | Describes intake, triage, remediation, disclosure, and internal decision workflow | Security or PSIRT |
| Vulnerability handling records | Case-level evidence showing what was reported, assessed, fixed, deferred, or communicated | PSIRT, security, engineering |
| Third-party component due diligence | Records supplier inputs, dependency review decisions, and component change assessments | Procurement, engineering, security |
| Conformity assessment records | Supporting materials used to demonstrate conformity, including any relevant external assessment output | Compliance, regulatory affairs |
What good looks like for each artefact
EU declaration of conformity
This should be controlled like a release artefact, not stored like a general legal template. It needs an unambiguous link to the product and version scope it covers. If your team is building or reviewing one, this guide to the CRA declaration of conformity is a useful reference point.
A common failure pattern is generating a declaration at launch and then never linking it back to the release package that justified it.
SBOM
For an SBOM, “good” means more than a manually written list in a spreadsheet. The useful version is generated from the build process, stored in a machine-readable format, and preserved with the release package.
A practical example: if your thermostat firmware includes open-source libraries, your retained SBOM should show the component names and versions that were present in the shipped build, not what happens to be in the repository today.
Cybersecurity risk assessment
Teams keep only the latest version in this area. That approach fails historical audits.
If your release from years ago accepted a specific risk because of a hardware limitation, you need to preserve that rationale as it existed then. Rewriting the assessment later may help current engineering, but it does not replace the contemporaneous record.
Vulnerability handling records
Do not retain only the policy. Keep the operating evidence.
For a practical example, if a customer report led to a firmware patch, your file should show the report intake, triage decision, remediation path, approval, and release linkage. Ticket references are helpful only if the underlying records remain available.
What gets lost first
The most fragile records are not the obvious ones.
- Release-specific approvals: Security sign-off captured in chat tools or informal email threads.
- Supplier change evidence: Notes on why a component swap was accepted.
- Historic test outputs: Reports overwritten by later test runs.
- Version mapping records: The bridge between product model, firmware build, and declaration scope.
Tip: If an artefact explains “why this version was considered acceptable at that time”, preserve it. Those judgement records become vital years later.
Retention Timelines Triggers and Durations by Role
Retention duties make more sense when you map them by role instead of treating the supply chain as one unit. Manufacturers, importers, and distributors do not all hold the same documentation set, and they should not build the same workflow.
The timeline also has a transitional shape. The CRA applies in phases; vulnerability and incident reporting begins earlier than the full obligations. This phased approach allows organisations time to align documentation practices, as described in timeline summaries.
Manufacturer obligations
Manufacturers carry the heaviest burden because they create the technical file and must be able to produce it to authorities.
For product teams, this means the retention process has to start at release readiness, not after shipment. The evidence set needs to be assembled while the engineers, security reviewers, and release managers still know what happened.
A practical example helps. A company shipping a connected access-control panel should preserve one release packet per market-relevant version. That packet should contain the approved risk assessment, release SBOM, test evidence, declaration reference, and vulnerability handling links. If a patch changes a dependency later, the updated evidence should be stored as a new retained state, not overwrite the original one.
Importer and distributor realities
Importers and distributors underestimate their own exposure because they are not writing the firmware or producing the technical file.
That is a mistake. Even where they do not create the full documentation set, they still need a disciplined way to obtain, verify, and retain the documents or copies relevant to their role. If the manufacturer’s filing is weak, the importer cannot solve that weakness at the last minute during an investigation.
In practice, importers should maintain a product intake checklist that confirms the declaration is available, the support period is clear, and the manufacturer can provide underlying documentation when requested. Distributors should not rely on verbal assurances that “the CE side is handled”.
The reporting timeline changes priorities
Many teams assume they can postpone operational work until the full applicability date. That does not hold up, because the earlier reporting date forces vulnerability handling to mature sooner. This overview of CRA reporting obligations under Article 14 is useful reading for teams building that process in parallel.
The consequence is practical. You may still be refining your long-term file structure, but your vulnerability intake, triage, and evidence capture flow needs to be functioning earlier.
A role-based handoff example
Consider one product travelling through the chain:
Manufacturer releases a smart sensor
The manufacturer creates the core evidence set, fixes the placed-on-market date, and stores the release-specific artefacts.Importer brings it into the EU
The importer confirms the conformity paperwork is available and that the manufacturer can support requests tied to the product.Distributor supplies it onward
The distributor verifies the product presentation and documentation state are not obviously deficient before supply.
Each party should record its own actions. The biggest failure mode here is assumption. The manufacturer assumes the importer will keep commercial records that explain traceability. The importer assumes the manufacturer will always be able to regenerate the specific declaration package. The distributor assumes any document gap is someone else’s problem.
What works and what does not
What works
- Role-specific checklists: Each actor records only what they must hold and verify.
- SKU-level traceability: Product identity, version, and market-placement data are linked.
- Stable escalation paths: Importers and distributors know who at the manufacturer owns compliance retrieval.
What does not
- One generic supply-chain folder: It obscures ownership.
- Informal assurances from upstream partners: Useful in meetings, useless in audits.
- Reconstructing records after a request arrives: By then the trail is already cold.
Key point: The CRA timeline is staggered, but your evidence discipline cannot be. Teams that wait for the final date discover they have reporting duties before they have retrieval discipline.
Building an Audit-Ready Retention Workflow
The best retention workflow is boring. It should not depend on heroic memory, manual chasing, or one compliance lead who knows where everything lives.
An audit-ready setup has four traits. It is centralised, version-controlled, release-linked, and hard to overwrite accidentally.
Step one Create a release evidence package
For every market-relevant release, create a package that can stand on its own years later.
That package should include the approved product description, the release-specific risk assessment, the SBOM, test outputs, the release decision trail, and the declaration linkage. Store these under a stable identifier such as product family plus version or firmware release tag.
A good rule is simple. If a future reviewer could not tell what shipped from the package alone, the package is incomplete.
Step two Automate collection wherever possible
Manual collection breaks first under release pressure.
The strongest teams generate evidence from delivery workflows. SBOMs come from the build pipeline. Test outputs are exported into the retained release record. Approval gates feed the evidence set instead of sitting only in chat or issue comments.
This is also where teams benefit from a structured CRA compliance evidence pack rather than assembling one from scratch every time.
Practical example for a firmware release
A connected lighting controller receives a firmware update.
- Build pipeline generates the release artefacts.
- SBOM is exported and stored against that build.
- Security testing output is attached.
- Product security reviews whether the existing risk assessment still holds or needs an updated decision record.
- Release management marks the package approved.
- The package is archived in the retention repository with immutable timestamps.
That process is repeatable. A manually assembled ZIP file on someone’s desktop is not.
Step three Preserve history, not just the latest state
Many engineering tools are designed for current-state efficiency. Compliance retention needs historical fidelity.
If your risk register updates in place, preserve snapshots at release points. If your ticketing system allows edits after closure, export the decision state into the release record. If suppliers change a component, retain the old and new assessment trail.
Many teams make a subtle mistake here. They think version control alone solves the problem. It helps, but a repository commit log does not explain the compliance significance of a change.
Step four Test retrieval before anyone asks
A retention workflow is only as good as its retrieval drill.
Pick a released product and ask your own team to produce the complete file from that version. Do not allow people to patch missing pieces from memory. If retrieval depends on asking around, your system is not ready.
A simple internal drill
Ask for these items for one historic release:
| Retrieval item | What you want to confirm |
|---|---|
| Released SBOM | It exists for the shipped version, not a later rebuild |
| Risk assessment | It matches the period and release decision at that time |
| Test evidence | It is stored and readable, not only referenced |
| Vulnerability records | The team can show how issues were handled for that release |
| Declaration linkage | The declaration can be tied to the retained evidence set |
Why this matters financially
Poor record-keeping is not only a paperwork issue. Failure to retain and provide technical documentation can lead to penalties of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher, as stated in the CRA Article 13 summary at European Cyber Resilience Act Article 13.
That should change how teams prioritise retention work. Archiving evidence is not admin overhead. It is risk control.
Practical rule: Build your retention workflow so that a staff change, tool migration, or supplier exit does not erase the reasoning behind a shipped release.
Navigating the CRA Transition and Legacy Products
Many teams still assume the CRA is primarily a rule for products launched after the full application date. For organisations with existing portfolios, that assumption is simplistic.
Products placed on the EU market before the full applicability date are only subject to CRA requirements if, from that date, they are subject to a substantial modification, but public guidance does not yet define that threshold precisely, which creates ambiguity for long-lived products, according to the European Commission summary cited in the verified data at the CRA summary page.
Why legacy portfolios pose a significant challenge
If you maintain industrial controllers, smart building devices, embedded gateways, or long-supported firmware products, post-applicability date changes are likely. Security patches, dependency swaps, hardware substitutions, and feature updates all create questions.
The difficult part is not only legal interpretation. It is operational classification. Teams need a repeatable way to identify which planned changes may pull a legacy product into a new compliance posture.
A product roadmap review should therefore include a modification screen, not only a feature and release review.
A practical decision framework
Use a structured internal review for every legacy product update after the relevant date.
Ask these questions
- Scope: Does the change alter core product behaviour, architecture, or exposure?
- Security relevance: Does it materially affect the product’s cybersecurity posture?
- Component impact: Are you replacing or materially changing a significant software or hardware element?
- Support implications: Does the update change the declared support model or expected use assumptions?
- Documentation effect: Would a reasonable authority expect the technical file to be updated because of this change?
This does not produce a legal verdict on its own. It gives you a defensible internal process.
A legacy product example
Suppose you shipped an industrial PLC before the full applicability date and plan a firmware update in 2028.
If that update is a narrow security fix, your team should still document why it was treated as maintenance rather than a substantial modification. If it changes communications behaviour, introduces major new functionality, or significantly alters component structure, the analysis becomes more serious.
The point is to avoid two bad extremes. One is assuming every legacy patch is harmless. The other is treating every maintenance update as a full re-entry into CRA scope without analysis.
A dated roadmap and obligations tracker such as the one discussed in CRA deadlines 2025 to 2027 can help teams organise that transition work.
Best practice: For every SKU placed on the market before the full applicability date, create a legacy register with market-placement date, support end-date, planned updates, and a modification review note for each significant post-applicability date release.
What does not work
Do not leave the substantial-modification question to release week.
By that point, engineering wants to ship, legal wants certainty, and nobody has enough documented context. Legacy compliance decisions need to happen at roadmap stage, when there is still time to adjust scope, gather evidence, or change the release plan.
Your Path to Confident Long-Term Compliance
The CRA conformity documentation retention period is easy to summarise and hard to operationalise.
The durable approach is to treat retention as part of product delivery. Keep the technical file and declaration as a release-linked evidence set. Preserve historical versions, not just the latest state. Make vulnerability handling records retrievable. Review legacy portfolios before post-applicability date changes create surprises.
The teams that do this well are not always the ones with the biggest compliance function. They are the ones that assign ownership clearly and build retrieval into ordinary engineering work.
If your organisation can identify the version placed on the market, produce the matching documentation set, explain how vulnerabilities were handled, and show how support periods were determined, you are in a far stronger position than teams still relying on scattered folders and institutional memory.
Long-term compliance is not about perfect paperwork. It is about preserving evidence in a form that makes sense years later.
CRA Retention Period FAQ
| Question | Answer |
|---|---|
| Does the retention rule only cover the declaration of conformity? | No. The retained set includes the technical documentation as well as the EU declaration of conformity. In practice, teams should treat the declaration as one artefact within a wider evidence file. |
| If our support promise is shorter than a decade, can we delete earlier? | No. If the support period is shorter, the baseline retention period still applies. |
| What if our support period runs longer than a decade? | Then the file should remain available for the longer support period. The rule follows the longer duration. |
| Can we keep records only in the systems we already use for engineering? | Sometimes, but only if those systems preserve version history, approvals, and retrievable evidence over time. Many teams need a more controlled archive layer. |
| Do security patches for legacy products automatically count as substantial modifications? | Public guidance leaves that point open. Teams should document a structured assessment rather than assuming yes or no. |
| What is the biggest operational mistake? | Keeping documents without preserving context. A file with no version mapping, approval trail, or release linkage is often not enough in practice. |
Regulus helps manufacturers, IoT vendors, and digital product teams organise CRA applicability, classification, documentation, and evidence workflows in one place. If you need a clearer path from scattered release records to a defensible long-term compliance system, explore Regulus.
