CRA evidence version control is about product-to-evidence traceability. Each marketed release should have an identifiable compliance baseline containing the risk assessment, architecture, security design, SBOM, vulnerability-handling documentation, security tests and other relevant evidence. Working documents can continue to evolve, but approved baselines and historical evidence should remain recoverable and protected from ambiguous overwriting.
The CRA Requires Traceability, Not a Particular Version-Control Tool
The CRA does not prescribe Git, Subversion, SharePoint, a document-management platform or another particular version-control technology. The legal requirements instead create a need for traceability. Article 31 requires technical documentation to remain updated where appropriate, Annex VII requires versions of software affecting compliance to be identified, and Article 13 requires technical documentation to be retained. Manufacturers can choose the tooling, but they should be able to determine which evidence applied to each marketed product version.
- No CRA-mandated version-control product.
- Identify compliance-relevant software versions.
- Maintain current documentation.
- Retain historical documentation.
- Preserve product-to-evidence traceability.
Separate Product Version From Document Version
A product release number and a document version answer different questions. Product version identifies the software, firmware, hardware or configuration placed on the market. A document version identifies a revision of the risk assessment, architecture diagram, policy or report. One product version can reference several document revisions, and one controlled process document can apply to several product versions. Evidence management should record both rather than assuming a matching number scheme proves traceability.
- Product version.
- Build identifier.
- Hardware revision where relevant.
- Document revision.
- Approval date.
- Applicable product range.
Identify Software Versions Affecting Compliance
Annex VII requires the general product description to include versions of software affecting compliance with essential cybersecurity requirements. Manufacturers should therefore determine which software identifiers materially distinguish conformity-relevant releases. A cosmetic frontend change might not require the same evidence impact as a new authentication system, update client or privileged service. The technical file should make the relevant version boundary explicit.
- Compliance-relevant software version.
- Firmware version.
- Security component version.
- Product edition.
- Relevant deployment profile.
Create an Evidence Baseline for Each Marketed Release
A practical approach is to create an approved evidence baseline for each compliance-relevant marketed release. The baseline can identify the exact risk assessment, architecture, security design, SBOM, vulnerability process version, test reports, standards mappings and declaration associated with the release. Evidence can remain distributed across controlled systems as long as the baseline reliably points to the correct versions.
- Risk assessment baseline.
- Architecture baseline.
- Security design baseline.
- SBOM baseline.
- Test evidence baseline.
- Conformity-document baseline.
Use Stable Evidence Identifiers
Compliance evidence should have stable identifiers that survive ordinary file moves or tool changes. Identifiers can include document numbers, report IDs, release tags, immutable archive references or another controlled scheme. A technical file containing links to temporary CI artefacts or personal folders can become unusable years later. Stable references make it easier to reconstruct the evidence package for an earlier product version.
- Document identifier.
- Report identifier.
- Release identifier.
- Evidence archive reference.
- Product-version reference.
Distinguish Draft Evidence From Approved Evidence
Engineering documents often evolve rapidly during development. The evidence-management system should distinguish working drafts from reviewed or approved records used for conformity. This does not mean every security note requires formal executive approval. Important compliance artefacts should have a clear status so that reviewers do not accidentally rely on an outdated draft or unfinished test report when evaluating the marketed release.
- Draft.
- Under review.
- Approved.
- Superseded.
- Archived.
Record Who Approved Material Evidence
For material risk, architecture, security design and conformity decisions, retain the responsible reviewer or approval role where appropriate. Approval records can show that significant residual risks, non-applicability conclusions and release evidence received the required organisational review. The CRA does not prescribe one approval hierarchy, so the process should reflect the manufacturer's governance model and product risk.
- Evidence owner.
- Reviewer.
- Approval role.
- Approval date.
- Relevant release.
Preserve Revision History
Revision history should explain material changes rather than merely increment a number. Useful records identify what changed, why it changed, who made or approved the change and which product release is affected. This helps distinguish an editorial update from a change that alters cybersecurity reasoning or conformity evidence. Automated repository history can support this goal, but the history still needs meaningful change context.
- Previous revision.
- New revision.
- Change reason.
- Affected product.
- Reviewer or owner.
Do Not Overwrite Historical Risk Assessments
A current risk assessment can contain conclusions that differ significantly from those used for an earlier release. Manufacturers should preserve the earlier baseline or enough history to reconstruct it. If a vulnerability later affects version 2.0, investigators may need to understand why the relevant control was designed as it was when that version was released. Historical risk evidence supports that analysis.
- Preserve prior risk baselines.
- Record reassessment triggers.
- Link changes to product versions.
- Retain superseded risk decisions.
Version Architecture and Security Design Together
Architecture and security design documents are closely related. If the architecture changes without a corresponding security-design review, the documentation can become internally inconsistent. Use change references or release baselines to show which design record belongs to which architecture. This is particularly important when trust boundaries, privileged services, authentication paths or update mechanisms change.
- Architecture revision.
- Security-design revision.
- Shared release identifier.
- Change reference.
- Verification impact.
Version SBOM Evidence Per Release
An SBOM is most useful when the manufacturer can determine which components were present in a particular product release. Continuously replacing one SBOM file with the latest component list destroys historical vulnerability-analysis capability. Preserve release-specific SBOMs or another reliable historical representation and associate them with relevant product versions and builds.
- Release-specific SBOM.
- Component versions.
- Build association.
- Generation date.
- Historical retention.
Version Security Test Reports Against the Tested Build
Security test evidence should identify the product build and configuration tested. If remediation results in another build, the retest should identify that build separately. Avoid replacing the original failed result with the later passing report. The failure, remediation and successful retest form a useful evidence chain showing how the product reached its final conformity state.
- Tested product version.
- Build identifier.
- Configuration.
- Original finding.
- Remediation build.
- Retest result.
Protect Approved Evidence From Uncontrolled Modification
Evidence used for conformity should not be silently modifiable without trace. Access controls, repository permissions, signed releases, immutable archives or another appropriate mechanism can preserve integrity. The CRA does not prescribe one technical method. The manufacturer should select controls proportionate to the value of the evidence and the need to demonstrate what documentation existed for a particular release.
- Access controls.
- Controlled modification.
- Change logging.
- Protected release baselines.
- Backup and recovery.
Retain Technical Documentation for the Required Period
Article 13 requires manufacturers to keep the technical documentation and EU declaration of conformity at the disposal of market surveillance authorities for at least 10 years after the product has been placed on the market or for the support period, whichever is longer. Evidence-management systems should therefore be designed for long-term accessibility rather than only the active development lifecycle.
- At least 10 years after market placement.
- Or the support period where longer.
- Preserve accessible technical documentation.
- Preserve the EU declaration of conformity.
- Plan for repository and platform migration.
Plan for Tool and Repository Migration
A product can remain within the retention period longer than the development tool used to create it. Repositories can be renamed, vendors can change and engineering platforms can be retired. Evidence governance should therefore include migration or export procedures that preserve identifiers, version history and approval records. The compliance evidence should not become inaccessible because the original issue tracker or source repository no longer exists.
- Repository migration.
- Document-system migration.
- Preserve identifiers.
- Preserve revision history.
- Verify migrated evidence.
A Practical CRA Evidence Version Record
A practical evidence register can identify the evidence ID, document type, document revision, applicable product version, build identifier, owner, approval state, approval date, evidence location, superseding record and retention date. The CRA does not prescribe this exact format. Its purpose is to make the technical file reconstructable and demonstrate which evidence supported the manufacturer's conformity conclusion for each marketed product version.
- Evidence identifier.
- Document type.
- Revision.
- Applicable product version.
- Build identifier.
- Owner.
- Approval state.
- Evidence location.
- Superseding record.
- Retention requirement.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.